Necessity for declaring RestEasy dependencies although bundled with WildFly? - wildfly

According to the RESTEasy modules in WildFly documentation:
In WildFly, RESTEasy and the JAX-RS API are automatically loaded into
your deployment's classpath if and only if you are deploying a JAX-RS
application (as determined by the presence of JAX-RS annotations).
However I don't really understand this paragraph. What does it exactly mean? As an exmaple, let's say I want to use ResteasyClient in a class. My IDE tells me that I must add this dependency in the corresponding pom.xml. But then how does that go with the above quote?
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
</dependency>
My pom.xml already includes this:
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-jakartaee8-with-tools</artifactId>
<version>20.0.1.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
When looking at this BOM it looks as if the resteasy-client is already included?

My IDE tells me that I must add this dependency in the corresponding pom.xml
Yes, you must declare this dependency in your pom.xml if you use the API of it, but you only need provided-scope, because as the documentation said, it is already included in your deployment's classpath. If you use only the standard api defined in wildfly-jakartaee8, you do not need this dependency.

Related

Maven jar dependency not found at runtime by OSGi environment

I'm building an Eclipse product that requires some external dependencies, which are not bundled as Eclipse plugins.
For example javax.json-1.1.4.jar.
I'm usign a target platform file, with Maven dependency added. This is the relevant part of the .target file:
<location includeDependencyScope="compile" includeSource="true" missingManifest="generate" type="Maven">
<dependencies>
......
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.1.4</version>
<type>jar</type>
</dependency>
</dependencies>
</location>
The resulting bundle is included from the plugin that uses this Json implementation: this is the MANIFEST of the plugin
Require-Bundle: org.glassfish.javax.json;bundle-version="1.1.4"
The plugin compiles and run normally. The problem happens at runtime, when the Json implementation is loaded:
2022-03-11 09:44:18,166 ERROR [main]: Provider org.glassfish.json.JsonProviderImpl not found
2022-03-11 09:44:18,168 ERROR [main]:
javax.json.JsonException: Provider org.glassfish.json.JsonProviderImpl not found
at javax.json.spi.JsonProvider.provider(JsonProvider.java:99)
at javax.json.Json.createReader(Json.java:225)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.MotorDataHandler.parseMotorJsonFile(MotorDataHandler.java:64)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.DBHandler.initMotorsDB(DBHandler.java:209)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.DBHandler.getMotors(DBHandler.java:116)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.FieldBusDevice.getMotors(FieldBusDevice.java:1323)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.FieldBusDevice.createFromSiriusString(FieldBusDevice.java:1257)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.HwConfiguratorFactoryImpl.createFieldBusDeviceFromString(HwConfiguratorFactoryImpl.java:252)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.HwConfiguratorFactoryImpl.createFromString(HwConfiguratorFactoryImpl.java:93)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.createFromString(XMLHelperImpl.java:1615)
at org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(XMLHelperImpl.java:1156)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2710)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.setAttribValue(XMLHandler.java:2769)
at org.eclipse.emf.ecore.xmi.impl.SAXXMIHandler.handleObjectAttribs(SAXXMIHandler.java:79)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromFactory(XMLHandler.java:2247)
Caused by: java.lang.ClassNotFoundException: org.glassfish.json.JsonProviderImpl cannot be found by javax.json-api_1.1.4
at org.eclipse.osgi.internal.loader.BundleLoader.generateException(BundleLoader.java:516)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass0(BundleLoader.java:511)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:403)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:168)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at javax.json.spi.JsonProvider.provider(JsonProvider.java:96)
at javax.json.Json.createReader(Json.java:225)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.MotorDataHandler.parseMotorJsonFile(MotorDataHandler.java:64)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.DBHandler.initMotorsDB(DBHandler.java:209)
at com.test.mas.rcp.hwconfigurator.sirius.core.utils.DBHandler.getMotors(DBHandler.java:116)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.FieldBusDevice.getMotors(FieldBusDevice.java:1323)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.FieldBusDevice.createFromSiriusString(FieldBusDevice.java:1257)
at com.test.mas.rcp.hwconfigurator.sirius.core.impl.HwConfiguratorFactoryImpl.createFieldBusDeviceFromString(HwConfiguratorFactoryImpl.java:252)
The javax.json-1.1.4.jar is not found at runtime by the api jar javax.json-api_1.1.4.
The only way I found to make it work is to add the implementation jar to the runtime classpath settings of the plugin, in the Bundle-Classpath:
Bundle-ClassPath: .,
lib/javax.json-1.1.4.jar,
This requires the jar in the lib folder of the plugin, while it is already included from the tartget platform. It should be enough..
Is there a configuration or something to be done to make the OSGi environment recognise the jar as a Maven dependency at runtime?
I have read about Eclipse-BuddyPolicy and DynamicImport-Package but I don't know how to used them in my case, and if they are usefull.
This https://github.com/eclipse-ee4j/jsonp/issues/96 says that it "Should be fixed with javax.json:1.1.4 and jakarta.json:1.1.5" but I don't
get how...
I managed to fix this problem, thanks to the comments in this thread:
https://github.com/eclipse-ee4j/jax-ws-api/issues/90
in particular the last one:
https://github.com/eclipse-ee4j/jax-ws-api/issues/90#issuecomment-952793454
This is related to a veri similar problem I had with the implementation of the
com.sun.xml.ws.spi.ProviderImpl web service provider.
Including the OSGi Resource Locator in the bundle manifest, and the plugin with the actual implementations, make them discoverable at runtime.
This is the dependency in the target platform file:
<dependency>
<groupId>org.glassfish.hk2</groupId>
<artifactId>osgi-resource-locator</artifactId>
<version>2.5.0-b42</version>
<type>jar</type>
</dependency>
In the end, for the Json problem, I switched to the Eclipse Parsson implementation which works at runtime without problems.
These are the needed dependencies in the target platform:
<dependency>
<groupId>org.eclipse.parsson</groupId>
<artifactId>jakarta.json</artifactId>
<version>1.0.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>org.eclipse.parsson</groupId>
<artifactId>parsson</artifactId>
<version>1.0.0</version>
<type>jar</type>
</dependency>

REST with JAX-RS tomcat server returning "requested resource is not available"

I was following short tutorial on creating REST api using JAX-RS. I am using Tomcat server v7.0. When I run the application on the server I get error 404-requested resource is not available.
The project is Maven based, and my pom.xml file includes the following line
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
I do not have web.xml file as a result. That was how the tutorial was achieved. I do not have index.html/jsp file. I have created two classes RESTconfig.java and BookResources.java
...import statements
#ApplicationPath("api")
public class RESTconfig extends Application {
}
...import statements
#Path("books")
public class BookResources {
#GET
#Produces(MediaType.TEXT_PLAIN)
public String books() {
return "Hello world";
}
}
My pom.xml file looks like this
<groupId>com.dere</groupId>
<artifactId>myrest</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<failOnMissingWebXml>false</failOnMissingWebXml>
</properties>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
Once I run the application on the server and go to http://localhost:9090 I am able to see Tomcat home page, but if try to get data http://localhost:9090/myrest/api/books I get the 404 error, i.e requested resource is not available, I mentioned above.
Most of the examples or usage I saw online involve using web.xml and providing root of the application and using a servlet. This is my first exposure to building REST api. I may have misunderstood the whole thing or I skipped some step. I look forward for your help.
I am using Eclipse Photon for Java EE
Look at this
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
This is nothing more than basically a bunch of interfaces for the EE spec. There is no implementation. Java EE servers will have the implementation. Tomcat is not an EE server. The only part of the EE spec it will definitely have the implementation for is Servlets and JSP (the web profile). If you want an EE server, checkout Glassfish or Wildfly.
You are trying to work with the JAX-RS spec, where Tomcat for sure by default does not have an implementation for. So you need to add that implementation. The easiest implementation, IMO to get started with, is Jersey. You can simply add this dependency
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.25.1</version>
</dependency>
and it will get you up and running. Keep the Jersey User Guide handy. It will come in use.

GWT 2.8 websocket support

Does jetty server in gwt 2.8 support websocket now? As I know it did not support before. If there is a positive answer, then how to make it work? Stripping out jetty-8 and replaceing it with jetty-9 is not a good idea I think.
then how to make it work?
I want to elaborate a bit on this after the GWT 2.8.0 release. The only thing required for using javax.websocket is the knowledge of the Jetty version packaged with GWT and the following set of Maven dependencies (see also the Jetty WebSocket examples on GitHub):
<project>
<properties>
<sdm.jetty.version>9.2.14.v20151106</sdm.jetty.version>
</properties>
<dependencies>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>websocket-server</artifactId>
<version>${sdm.jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>javax-websocket-server-impl</artifactId>
<version>${sdm.jetty.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.websocket</groupId>
<artifactId>javax.websocket-api</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
</depencies>
</project>
Make doubly sure that the scope is provided - for the former two this will mean they are not packaged into the final app - you will be requiring those only when running the SuperDev-Mode (SDM). Ifjava.websocket-apiwas on your classpath probably the annotation-based configuration will not work at all (at least in embedded Tomcat and Jetty) due to the annotations being picked up by the wrong class loader (see also related question WebSocket 404 error for more info on this topic).
GWT 2.8 has switched to Jetty 9.2, and now supports Servlets 3.1 servlets container initializers, which I think are being used to setup WebSockets.
I haven't tried it but I suppose that you can now have WebSockets in DevMode, provided you add the required dependencies to the classpath.
You can also simply use a separate server rather than the one embedded into DevMode.

Arquillian and jboss-4.2.3.GA

i am workign on a jboss-4.2.3.GA project. Its a old project but we cant upgrade to new server.
I am trying to use Arquillian for JPA..
We are using folliwng entry in pom for JPA
<dependency>
<groupId>com.jboss</groupId>
<artifactId>ejb3-persistence.jar</artifactId>
<version>4.2.3</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>hibernate</groupId>
<artifactId>hibernate3</artifactId>
<version>3.2.4.SP1</version>
<scope>provided</scope>
</dependency>
I am trying to configure Arquillian but i am getting some issue like nosuchmethod found or some time no default container set.
Anyone help me what container i need to set and any dependency settings ?
Add the arquillian-bom to the dependencyManagement section of your pom, see the Getting Started Guide: http://arquillian.org/guides/getting_started/#add_the_arquillian_apis
That will update the version of the dependencies the jbossas adapter has on arquillian core. Without it you will be running a mix of Core 1.0.1.Final and Core X (what ever the adapter happens to be compiled against currently which may or may not be compatible with the 1.0.1.Final Core artifacts).

Using Drools on Jetty

I am trying to start up a webapp that uses Drools 5.2.0.M1. I get the following stacktrace on startup:
java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.CompilationResult.getProblems()[Lorg/eclipse/jdt/core/compiler/CategorizedProblem;
at org.drools.commons.jci.compilers.EclipseJavaCompiler$3.acceptResult(EclipseJavaCompiler.java:336)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:335)
at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:366)
at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51)
at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:366)
at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:55)
I have the jars in my pom:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>5.2.0.M1</version>
</dependency>
<dependency>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
<version>3.5.1</version>
</dependency>
Why Can't it find CompilationResult.getProblems()?
JDT isn't backwards compatible.
Check the drools-compiler pom (of exactly the version you're using) on which version of ecj it depends and use that version. Or don't declare ecj at all, it's a transitive dependency for drools-compiler anyway.
PS: upgrade to drools 5.2.0.CR1 (or final once it's out)
I had a similar problem. I was having a web-app using Jetty 6. Jetty 6 which apparently bringing in a non-compatible version of JDT. After switching to Jetty 7 the problem was solved.