I'm setting up an example project for testing purposes which uses Weld SE and JUnit5 and for some reason, in my test classes, after initializing weld I observ that, for some reason, it's bean discovery is disabled, which in the end, it lead me to this error:
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Person with qualifiers #Default;
This is my test class :
#EnableWeld
public class SimpleTestA {
#Inject
Person p;
#Test
public void testThatItWorks() {
System.out.println("Hey");
}
}
located in :
projectName\core\model\src\test\java\com\aCompany\projectName\core\model\testmodel\SimpleTestA.java
This is my beans.xml :
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" version="1.1" bean-discovery-mode="all" />
located in :
projectName\core\model\src\main\resources\META-INF\beans.xml
The project structure is fairly simple, I just have a main module named "projectName" which is the parent of the sub-module named "core" which contains all that i pasted earlier. My dependencies list is this :
<dependencies>
<!-- https://mvnrepository.com/artifact/org.junit.jupiter/junit-jupiter -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<version>${junit-jupiter.aggregator.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>${weld.se.core.version}</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.jboss.weld/weld-junit5 -->
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-junit5</artifactId>
<version>${weld.junit5.version}</version>
<scope>test</scope>
</dependency>
and those are my properties :
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<weld.se.core.version>3.0.1.Final</weld.se.core.version>
<weld.junit5.version>1.3.1.Final</weld.junit5.version>
<junit-jupiter.aggregator.version>5.4.0</junit-jupiter.aggregator.version>
If I modify the test adding the weld initialization attribute with explicit bean discovery activation, everything works very well:
#WeldSetup
WeldInitiator weldInitiator = WeldInitiator.of(WeldInitiator.createWeld().enableDiscovery());
What I'm missing ? If the beans.xml is present, shouldn't the bean discovery activated automatically? Thank you in advance.
So the thing here is that you are using Weld SE (well, weld-junit is), not Weld EE which you might know from servers such as WildFly.
In SE, the discovery is by default off and so called synthetic archive is used.
Synthetic archive only contains whatever you yourself feed it - classes as beans, packages to scan through etc. It doesn't scan whole classpath.
So to make your example work, you can either have the discovery on, or you can add the classes and packages you need via Weld.addPackages(), Weld.addClasses() and so on.
In context of Weld-junit this translates into WeldInitiator.createWeld().addPackages().
The reason why Weld SE (and weld-junit) doesn't perform the whole discovery is because you would effectively scan whole classpath including JDK packages and all. That takes time and on top of that you also discover tons of beans you don't need. Or you can pick up interceptors/alternatives that you didn't mean to. Last but not least, these are meant to be unit tests, so minimal deployments that test your beans.
Related
I use an embedded Jetty (11.0.13) server with Jersey (3.1.0) that provides a simple REST interface which returns JSON objects. The JSON objects are serialized using Jackson.
The setup works fine as long as I don´t use Java´s module system.
But when I add the module-info.java file (see below), I get the following error as soon as I call the service.
WARNING: The following warnings have been detected: WARNING: Unknown HK2 failure detected:
MultiException stack 1 of 2
java.lang.NoClassDefFoundError: jakarta/xml/bind/annotation/XmlElement
at com.fasterxml.jackson.module.jakarta.xmlbind.JakartaXmlBindAnnotationIntrospector.<init>(JakartaXmlBindAnnotationIntrospector.java:137)
...
Caused by: java.lang.ClassNotFoundException: jakarta.xml.bind.annotation.XmlElement
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 83 more
MultiException stack 2 of 2
java.lang.IllegalStateException: Unable to perform operation: post construct on org.glassfish.jersey.jackson.internal.DefaultJacksonJaxbJsonProvider
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:429)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:466)
...
To make it work, I have to add the JAX-B-API to the pom.xml and to the module-info.java.
The error only occurs when using Java modules. When I simply delete the module-info.java file, everythink works fine even without the JAX-B dependency.
This is the point where I am really confused. Why do I need the JAX-B dependency when I use the module system, but not when I don´t use it? And why does the ClassNotFoundException even occur? Shouldn´t warn the module system about missing dependencies on startup?
I hope someone can explain that. It took me days to make it work.
This is the setup that produces the issue:
pom.xml
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<maven.compiler.target>17</maven.compiler.target>
<maven.compiler.source>17</maven.compiler.source>
</properties>
<dependencies>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>11.0.13</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>11.0.13</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>3.1.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>3.1.0</version>
</dependency>
</dependencies>
</project>
Main.java
public class Main {
public static void main(String[] args) throws Exception {
Server server = new Server(8080);
server.setStopAtShutdown(true);
ServletContextHandler context = new ServletContextHandler(server, "/");
ServletHolder servletHolder = context.addServlet(ServletContainer.class, "/*");
servletHolder.setInitParameter("jersey.config.server.provider.packages", "com.example.demo");
servletHolder.setInitParameter("jersey.config.server.wadl.disableWadl", "true");
server.start();
}
}
DemoResource.java
#Path("/hello")
public class DemoResource {
#GET
#Produces("application/json")
public HelloDto hello() {
return new HelloDto("Hello, World!");
}
public record HelloDto(String value) {
#JsonGetter("value")
public String value() {
return this.value;
}
}
}
module-info.java
module demo {
requires org.eclipse.jetty.server;
requires org.eclipse.jetty.servlet;
requires jersey.container.servlet.core;
requires jakarta.ws.rs;
requires com.fasterxml.jackson.annotation;
}
This is the standard JVM behavior of classpath (old school Java) and modulepath (new school Java Platform Module System, aka JPMS).
Once you have a module-info.class you have a modulepath active, and all of the access rules it has.
Your runtime can have both at the same time, and this is quite normal.
Don't rely on old school classpath to get around bad code and bad behavior, use JPMS and module-info.class and you'll know what the developers of those projects jars intend for you to use (you won't be allowed to use internal classes for example, as those are highly volatile and can change at a moments notice).
jakarta.xml.bind is required by HK2 to operate, so you have to declare it in your build dependencies to just compile, and then your module-info.java to be able to access it.
Check the other answers here on Stackoverflow for advice on how to use module-info.java properly (there's far more to it than just requires <module>).
I am just starting to use JPA. I am trying to create database based on schema using Persistence.generateSchema("DataLayer", null) method, but i get an exception. As JPA implementation i am using OpenJPA.
My solution is divided into two Eclipse projects. Both use Maven and module-info.java.
1st project is clearly just main method where i call the method above.
2nd one is JPA entities and data access objects.
In 1st project i included dependency to 2nd project. In 2nd project i included dependencies to jpa implementor (openjpa) and database driver (derby). See dependencies part from pom.xml's bellow:
1st project dependency (there is just my 2nd project):
<dependency>
<groupId>registry</groupId>
<artifactId>datalayer</artifactId>
<version>0.0.1</version>
</dependency>
1st project module-info:
module justtestingTEMP
{
exports justtestingTEMP;
requires registry.datalayer;
requires javax.persistence;
}
2nd project dependencies:
<dependencies>
<dependency>
<groupId>org.apache.openjpa</groupId>
<artifactId>openjpa</artifactId>
<version>3.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derbyclient</artifactId>
<version>10.15.2.0</version>
</dependency>
</dependencies>
2nd project module-info:
module registry.datalayer
{
exports datalayer.other;
exports datalayer.dto;
exports datalayer.dao;
requires javax.persistence;
}
This is persistence.xml (it is in 2nd project):
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.2"
xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">
<persistence-unit name="DataLayer"
transaction-type="RESOURCE_LOCAL">
<non-jta-data-source>myNonJtaDataSource</non-jta-data-source>
<properties>
<property
name="javax.persistence.schema-generation.database.action"
value="create" />
</properties>
</persistence-unit>
This is the exception:
Exception in thread "main" java.lang.NoClassDefFoundError: javax/sql/DataSource
at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newInstance(JDBCBrokerFacto
ry.java:72)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Metho
d)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodA
ccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin
gMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.apache.openjpa.kernel.Bootstrap.invokeFactory(Bootstrap.java:131)
at org.apache.openjpa.kernel.Bootstrap.newBrokerFactory(Bootstrap.java:66)
at org.apache.openjpa.persistence.PersistenceProviderImpl.getBrokerFactory(Pers
istenceProviderImpl.java:152)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFa
ctory(PersistenceProviderImpl.java:95)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFa
ctory(PersistenceProviderImpl.java:159)
at org.apache.openjpa.persistence.PersistenceProviderImpl.generateSchema(Persis
tenceProviderImpl.java:244)
at javax.persistence#1.1/javax.persistence.Persistence.generateSchema(Persisten
ce.java:188)
at justtestingTEMP/justtestingTEMP.Main.main(Main.java:15)
Caused by: java.lang.ClassNotFoundException: javax.sql.DataSource
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoade
r.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoa
ders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 13 more
Where can i get that javax.sql.DataSource class from? I guess i am missing some dependency or i have configured something wrong.
What i tried: Switch JPA implementation (other exceptions were raised - but about missing classes), add requires java.sql; to module-info.
After adding requires java.sql; to module-info:
Exception in thread "main" java.lang.NoClassDefFoundError: java/lang /instrument/
ClassFileTransformer
at org.apache.openjpa.persistence.PersistenceProviderImpl.loadAgent(Persistence
ProviderImpl.java:365)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFa
ctory(PersistenceProviderImpl.java:102)
at org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFa
ctory(PersistenceProviderImpl.java:159)
at org.apache.openjpa.persistence.PersistenceProviderImpl.generateSchema(Persis
tenceProviderImpl.java:244)
at javax.persistence#1.1/javax.persistence.Persistence.generateSchema(Persisten
ce.java:188)
at justtestingTEMP/justtestingTEMP.Main.main(Main.java:14)
Caused by: java.lang.ClassNotFoundException: java.lang.instrument.ClassFileTrans
former
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoade
r.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoa
ders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 6 more
Found out that required classes were in java.sql and and java.instrument module, so adding these to module-info solve my issue. module-info.java should look like this:
module justtestingTEMP
{
exports justtestingTEMP;
requires java.instrument;
requires java.sql;
requires javax.persistence;
requires registry.datalayer;
}
Also it is possible to remove module-info.java from 1st project. That resulted in a "correct" error saying that i have not defined jdbc driver and connection properties - that is good. No class not found errors. I can create and connect to database now. That is probably because all required modules are available implicitly. With module-info.java i have to define all required modules.
Migrating an existing project to maven and wildfly and had to move some files around creating the following situation.
core.jar
ejb1.jar
ejb2.jar
With the ejb-jar.xml for ejb1.jar having the following:
<ejb-jar>
<enterprise-beans>
<session id="Value">
..
<home>path.to.ejb1Home</home>
<remote>path.to.ejb1</remote>
...
The classes referenced in the home and remote tags have moved to be inside core.jar
Meanwhile ejb2.jar has dependencies on other parts of core.jar.
What looked like the easiest resolution was to create a global module and place core.jar in it, creating the appropriate module.xml and entry in standalone.sh to make it accessible to all deployments.
module.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="path.to">
<resources>
<resource-root path="core-1.0.jar"/>
</resources>
<dependencies>
</dependencies>
</module>
With this setup, ejb2.jar deploys as expected but ejb1.jar throws the following error:
Caused by: java.lang.NoClassDefFoundError: Failed to link path.to.ejb1
(Module "path.to" from local module loader #4c40b76e (finder: local
module finder #2ea6137 (roots: /opt/wildfly/modules,
/opt/wildfly/modules/system/layers/base))): javax/ejb/EJBObject
You should carefully think about your requirement. Usually, you don't need to provide common resources, especially application interfaces, as module, especially as global module. Choose the right solution for your requirements, not a solutions that looks easy at first sight without knowing the implications.
I would recommend these possibilities in the order given (see the Class Loading in Wildfly Documentation for more information):
Reconsider your requirement for different EARs. Provide the core jar as library with your EAR.
Even with more than one EAR: provide the core.jar as library. This is no redundancy, this is just separation.
Consider not using a global module. Just install your custom module. Provide a jboss-deployment-structure.xml file, adding this module as additional dependency. If the module contains annotated classes or interfaces, which should be considered upon deployment, set the attribute annotations=true with the module dependency configuration.
Add a global module to your configuration file. Probably you can even use the `annotations' property, but this is something I don't know and I didn't check.
An example for the jboss-deployment-structure.xml file:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="my.custom.module" export="true" annotations="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
EDIT:
When installing modules, don't forget to provide transitive module dependencies to other modules your own module depends on. User your module.xml file to do so. In your case, you probably need at least a dependency to the javax.ejb.api module.
We want to exclude the modules\system\layers\base\javax\servlet\jstl\api\main\jboss-jstl-api_1.2_spec-1.1.2.Final.jar from our web application deployment (WAR file).
Hence we have the following configuration in src\main\webapp\WEB-INF\jboss-deployment-structure.xml:
<?xml version='1.0' encoding='UTF-8'?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="javax.servlet.jstl.api"/>
</exclusions>
<dependencies>
<module name="deployment.my-dependencies.jar"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
In the Wildfly log I see that my-dependencies.jar is added as a ModuleDependency. But when searching for javax.servlet.jstl.api I only see this:
2015-04-03 15:22:11,971 DEBUG [org.jboss.modules] (ServerService
Thread Pool -- 12) Module javax.servlet.jstl.api:main defined by local
module loader #1f7c9157 (finder: local module finder #2b29f6e7 (roots:
C:\Users\me\Documents\wildfly-8.2.0.Final\modules,C:\Users\me\Documents\wildfly-8.2.0.Final\modules\system\layers\base))
Why isn't the module excluded?
Update: It seems that modules that are part of a user dependency can not be excluded.
It seems like the mechanism doesn't work as described in the Wildfly documentation. I was not able to exclude that module.
Yep. I was trying to upgrade to Spring Framework to v4.3. It has upped some minimum dependency requirements. One such example is Jackson min version required is 2.6+
Wildfly loads jackson that comes packaged (v2.4.1 in Wildfly 8.2.1), and it won't be excluded using jboss-deployment-structure.xml.
I was trying to see if the upgrade did not involve making changes to the installed server which takes this upgrade out of source control.
I've just developed a sample Java EE 7 application.
The code is as follows:
#Stateless
#LocalBean
public class Foo {
#Inject
private Boo boo; // Internal resource
#Asynchronous
public void doFoo(Collection<Object> c) {
boo.doSomething(c);
}
}
With the aim to deploy the project as jar file, I'm using the following Maven configuration:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>sample</groupId>
<artifactId>ejb-foo</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>ejb-foo</finalName>
</build>
<properties>
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
</properties>
</project>
Unfortunately, Maven returns me this warning:
Classpath entry org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER will not be exported or published. Runtime ClassNotFoundExceptions may result. ejb-foo P/ejb-foo Classpath Dependency Validator Message
How can I fix this error?
Note:
The idea is to import that jar into another Java project and then to instance the Foo class as EJB:
import myjavaeeproject.Foo;
public OtherClass {
#EJB
private Foo foo;
public void doMagic(List<String> list) {
foo.doFoo(list);
}
}
Update:
I've fixed the error as shown here.
When I deploy (as war) the target project (that implements OtherClass, annotated as WebServlet) on JBoss, I've an error:
POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment
It depends on the EJB injection.
What am I doing wrong?
As per my examples in comment, it is because eclise think "the library exists at the server and it is not right to export this with your projects"
I don't have much idea about your code, but seems to be ok.
If this is a J2EE application, I would expect the target to be a war or ear. I don't think that a J2EE container will understand a jar deployment.