My problem is (as I think) quite complicated..
I am using JBoss 7 and created a module for Liferay faces. Within my WAR file, I created a jboss-deployment-structure.xml, in which I load the JSF module with Mojarra and the Liferay Faces module. But on startup of my web application, the ManagedBeans of the Liferay Faces implementation are not initialized and because of this, my application crashes. If I include the Liferay Faces JAR in my WAR lib folder, everything works, so this something of a class loading issue..
Liferay Faces modules.xml
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.liferay.faces">
<resources>
<resource-root path="liferay-faces-alloy.jar"/>
<resource-root path="liferay-faces-bridge-api.jar"/>
<resource-root path="liferay-faces-bridge-impl.jar"/>
<resource-root path="liferay-faces-portal.jar"/>
<resource-root path="liferay-faces-util.jar"/>
<resource-root path="util-bridges.jar"/>
<resource-root path="util-java.jar"/>
<resource-root path="util-taglib.jar"/>
<!-- Just for testing --->
<resource-root path="AlexBean.jar"/>
</resources>
<dependencies>
<module name="javax.api" />
<module name="javax.enterprise.api" />
<module name="javax.faces.api" />
<module name="javax.inject.api" />
<module name="com.liferay.portal" />
<module name="com.sun.jsf-impl" />
</dependencies>
</module>
jboss-deployment-structure.xml
[...]
<module name="com.liferay.faces" services="import" export="true" meta-inf="export"/>
<module name="com.sun.jsf-impl" />
[...]
Why do I know Mojarra is not scanning and loading the #ManagedBeans #ApplicationScoped as it should? The JAR file AlexBean.jar contains a single class which is annotated as #ManagedBean and #ApplicationScoped. If the JAR file is placed within the WAR file, it works. If I use the JBoss modules they aren't, so I assume that the Liferay Faces beans aren't loaded either, but they are needed..
Thx in advance!
Best regards - Nuker
Related
Background
Transforming a Wildfly 17 Java EE project (EAR) to Wildfly 26 and Jakarta EE9.1
Updated all dependencies and changed imports. Also some code changes necessary.
Now i am stuck on resteasy-core-spi-6.0.0.Beta1
When deploying i get this error:
Caused by: java.lang.IncompatibleClassChangeError: Expected static method 'java.lang.Object org.jboss.resteasy.spi.ResteasyProviderFactory.getContextData(java.lang.Class)'
The Code that calls this method looks like this.
FooClass foo = ResteasyProviderFactory.getContextData(FooClass .class);
A look at the SPI Class reveals this.
public static <T> T getContextData(Class<T> type) {
return getContextDataMap().get(type);
}
That looks perfectly fine.
Examining the Wildfly system dir and looking in the module for same jar.(resteasy-core-spi-6.0.0.Beta1,jar)
reveals this
<resources>
<resource-root path="resteasy-core-spi-6.0.0.Beta1.jar"/>
</resources>
<dependencies>
<module name="java.desktop"/>
<module name="java.logging"/>
<module name="java.management"/>
<module name="java.naming"/>
<module name="java.xml"/>
<module name="javax.activation.api"/>
<module name="javax.annotation.api"/>
<module name="javax.enterprise.api"/>
<module name="javax.servlet.api"/>
<module name="javax.validation.api"/>
<module name="javax.xml.bind.api"/>
<module name="javax.ws.rs.api"/>
<module name="org.jboss.logging"/>
<module name="org.reactivestreams"/>
</dependencies>
I tried to update that to jakarta namespace but no change.
I am at a loss here, do anyone have some ideas?
I have a jar which can't be copied to ear while generating docker-image. Also, I can't add the jars as modules because of some dependency issue.
So, I have added below resource-root in my jboss-deployment-structure file(To make it same as copying the jar in the EAR's lib directory).
false
<!-- This corresponds to the top level deployment. For a war this is the war's module, for an ear -->
<!-- This is the top level ear module, which contains all the classes in the EAR's lib folder -->
<deployment>
<!-- exclude-subsystem prevents a subsystems deployment unit processors running on a deployment -->
<!-- which gives basically the same effect as removing the subsystem, but it only affects single deployment -->
<exclude-subsystems>
<subsystem name="jpa"/>
</exclude-subsystems>
<dependencies>
<module name="org.abc" services="import"/>
<module name="org.abcde.zye" optional="true"/>
</dependencies>
<resources>
<!-- These add additional classes to the module. In this case it is the same as including the jar in the EAR's lib directory -->
<resource-root path="/../../../standalone/outsideEar/outside-abc.jar"/>
</resources>
</deployment>
<sub-deployment name="abc-abc.war">
<dependencies>
<module name="org.abcde.zye" optional="true"/>
</dependencies>
</sub-deployment>
<sub-deployment name="abc-ejb.jar">
<dependencies>
<module name="org.abcde.zye" optional="true"/>
</dependencies>
</sub-deployment>
My Ear Structure:
my-ear.ear
|- lib
|- abc-abc.war
|- abc-ejb.jar
|- META-INF
|- application.xml
|- jboss-app.xml
|- jboss-deployment-structure.xml
|- maven
|- pom.properties
|- pom.xml
When I deploy this ear to wildfly-15.0.1.Final server outside the docker it works fine.
Path for resource-root is resolved, outside-abc.jar is copied to the below tmp folder (which is generated dynamically on server start) and I am able to perform operation by using classes of outside-abc.jar.
wildfly-15.0.1.Final\standalone\tmp\vfs\deployment\deploymentdc506469ec651715
wildfly-15.0.1.Final structure:
wildfly-15.0.1.Final
|- bin
|- domain
|- modules
|- standalone
|- outsideEar
<!-- This path is resolved with resource-root path="/../../../standalone/outsideEar/outside-abc.jar" -->
|- outside-abc.jar
|- configuration
|- data
|- deployments
|- my-ear.ear
|- lib
|- log
|- tmp
|-jboss-modules.jar
One More case which works fine: If I use below resource-root then my jar should be inside bin folder as wildfly-15.0.1.Final/bin/outsideEar/outside-abc.jar
<resource-root path="../../outsideEar/outside-abc.jar"/>
Docker configuration:
If I use same above structure, build docker image and start container for the image. It is not able to identify the jar file and do not copy it to
wildfly-15.0.1.Final\standalone\tmp\vfs\deployment\deploymentdc506469ec651715 folder which eventually causes ClassNotFoundException while performing operations.
I have verified that outside-abc.jar is properly copied to the mounted docker directory(Already added configuration in docker-compose file).
I have been further inside of this and found that a attribute use-physical-code-source="true" can be set for resource-root to resolve the path using physical source code location.
When use-physical-code-source="true" : It reads from physical location. I am not getting what is the actual physical location inside the docker. I think it is deployments folder or deployments/my-ear.ear/META-INF.
When use-physical-code-source="false"(default is false) : It reads from vfs directory(Inside temp).
I tried many different paths to make it work but, there was no luck.
Possible cases I tried:
<resource-root path="./../../../../../../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../outsideEar/outside-abc.jar"/>
<resource-root path="./../../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./../outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../outsideEar/outside-abc.jar"/>
<resource-root path="./../../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./outsideEar/outside-abc.jar"/>
<resource-root path="./../standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./../standalone/outsideEar/outside-abc.jar"/>
<resource-root path="./standalone/outsideEar/outside-abc.jar" use-physical-code-source="true"/>
<resource-root path="./standalone/outsideEar/outside-abc.jar"/>
For above cases, I have mounted jars inside both bin and standalone folders as bin/outsideEar/outside-abc.jar and standalone/outsideEar/outside-abc.jar. So, I confirm jar is available to the docker wildlfy server.
Requirement summary:
How is resource-root path resolved(inside and outside docker) when
use-physical-code-source="true" and use-physical-code-source="false"?
Is there any way to pass only directory name for resource root so that
all the jars under that directory can be copied to tmp/deployment. If
not possible, then is there any way which can be applied to pass jar
name dynamically to the jboss-deployment-structure.xml using either properties file or environment variable so that at container start-up jar can be copied to the temp/deployment.
Any assistance you can provide would be greatly appreciated.
Thank you.
I have a module in Wildfly to use as my datasource to Firebird. It works great
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="org.firebirdsql">
<resources>
<resource-root path="jaybird-2.2.13.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.resource.api"/>
<module name="javax.xml.bind.api"/> <!-- Jaybird 3.0 onwards doesn't need this -->
<module name="org.antlr4"/>
</dependencies>
</module>
and the jar is put inside the directory of module.xml.
But I want to use the driver both with data source and also to create a pure JDBC connection in connectionfactory like Class.forName("org.firebirdsql.jdbc.FBDriver");, not using data source provided by the server.
If I put jaybird in pom.xml I got errors. I think because this is duplicating the libs. How can I solve this?
I just added the below code under <subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="org.firebirdsql" slot="main"/>
</global-modules>
Thanks, Mark Rotteveel for answer on the Jaybird bug tracker.
I'm migrating my web application to JBOSS 7 and I have problems with the Class.forName method.
I have basically 2 jars, each one in one different module:
CampusComponentsJava-1.4.4.jar
CampusGateway-2.5.3-SNAPSHOT.jar
The code from CampusComponentsJava loads dynamically a class from CampusGateway-2.5.3-SNAPSHOT.jar
in the following way:
Class.forName("edu.uoc.campusgateway.osid.authentication.AuthenticationManager")
I have created 2 modules in the modules folder:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="edu.uoc.oki2">
<resources>
<resource-root path="CampusGateway-2.5.3-SNAPSHOT.jar" />
<resource-root path="CampusLauncherJava-1.1.3-SNAPSHOT-filter.jar"/>
<resource-root path="OkiBusJava-1.2.2-config-uoc.jar"/>
<resource-root path="OkiBusXmlSchemas-1.1.1-SNAPSHOT.jar"/>
<resource-root path="OkiOSID-2.0.jar"/>
<resource-root path="JavaUtils-1.1.2-SNAPSHOT.jar"/>
<resource-root path="LibTecsidel.jar"/>
</resources>
<dependencies>
</dependencies>
</module>
And
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="edu.uoc.okicomps">
<resources>
<resource-root path="CampusComponentsJava-1.4.4.jar"/>
<resource-root path="CampusComponentsJava-1.4.4-config-uoc.jar"/>
</resources>
<dependencies>
<module name="edu.uoc.oki2" export="true"/>
</dependencies>
</module>
I the later one the tag to express the idea that module edu.uoc.okicomps depends on module edu.uoc.oki2 since one jar of the edu.uoc.okicomps module wants to load dynamically a class from one jar of the module edu.uoc.oki2:
Finally, since the webapp needs all the jars I have declared explicitally access to both modules of the webapp in the META-INF/MANIFEST.xml
Manifest-Version: 1.0
Class-Path:
Dependencies: edu.uoc.okicomps,edu.uoc.oki2
However it is not working failing with the exception:
java.lang.NoClassDefFoundError: Could not initialize class edu.uoc.campusgateway.osid.authentication.AuthenticationManager
Any help would be apreciated!
Thank you very much in advance.
I found the problem. The problem was that the Class.forName, due to its own nature, executes static code and the constructor.
In this case, the static code tries to load through the classloader a property file that is included in another jar that I forgot to add. So the fix to my problem is:
1) add the following line to the module.xml
2) add physically the file CampusComponentsJava-1.4.4-config-uoc.jar to the
modules\edu\uoc\oki2\main folder
TL:DR I'm getting the following error and I can see no reason for it, indexing is enabled, and the SearchFactoryIntegrator is on the classpath for everything that needs to see it.
Indexing was not enabled on this cache. interface
org.hibernate.search.spi.SearchFactoryIntegrator not found in registry
Long Version:
JBoss version: 7.1.1 FINAL
Infinispan version: 5.16 (upgraded from 5.1.2 JBoss ships with in attempts to solve issue)
Java Version: 1.7
I am attempting to build a simple test application to run queries against an Infinispan cache.
I am successfully adding objects to the cache. The cache is defined as private org.infinispan.Cache<String, Agent> cache; with Agent being my own object.
When attempting to query the cache I get the following error from the line
SearchManager searchManager = Search.getSearchManager(cache);
17:35:43,873 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/SearchableCacheTest].[Faces Servlet]] (http-localhost-127.0.0.1-8080-1) Servlet.service() for servlet Faces Servlet threw exception: java.lang.IllegalArgumentException: Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchFactoryIntegrator not found in registry
at org.infinispan.query.impl.ComponentRegistryUtils.getComponent(ComponentRegistryUtils.java:40) [infinispan-query-5.1.6.FINAL.jar:5.1.6.FINAL]
at org.infinispan.query.SearchManagerImpl.<init>(SearchManagerImpl.java:56) [infinispan-query-5.1.6.FINAL.jar:5.1.6.FINAL]
at org.infinispan.query.Search.getSearchManager(Search.java:39) [infinispan-query-5.1.6.FINAL.jar:5.1.6.FINAL]
The important part being
Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchFactoryIntegrator not found in registry
Prior to this error cache.getCacheConfiguration().indexing().enabled() resolves to true
The cache is a modified version of the default "cluster" cache already configured in the standalone-ha.xml of JBoss.
<cache-container name="cluster" aliases="ha-partition" default-cache="default" start="EAGER">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC" batching="true" indexing="LOCAL">
<locking isolation="REPEATABLE_READ"/>
<store class="org.infinispan.loaders.file.FileCacheStore" preload="true" passivation="false" fetch-state="true" purge="false">
<property name="location">
/tempCacheIndex
</property>
</store>
</replicated-cache>
</cache-container>
I see the index being created in the configured file location so it seems that enabled boolean resolving to true is a factual representation of the current state.
I have created an org.infinispan.query module in JBoss and it contains the following
avro-1.5.1.jar
hibernate-commons-annotations-4.0.1.Final.jar
hibernate-search-engine-4.1.1.Final.jar
infinispan-query-5.1.6.FINAL.jar
jackson-core-asl-1.9.2.jar
jackson-mapper-asl-1.9.2.jar
lucene-core-3.5.0.jar
paranamer-2.3.jar
slf4j-api-1.6.1.jar
snappy-java-1.0.4.1.jar
All of the above are defined in as resource-roots in the module.xml for that module.
I have modified the module.xml for the module org.infinispan to have a dependency on the module org.infinispan.query
I have declared dependencies on both those modules in my jboss-deployment-structure.xml
Does anyone have any ideas why this might be happening and perhaps have a solution?
Note: There is a very similar question here but he was ultimately unsuccessful and chose a different route.
NOTE: I started with a clean JBoss 7.1.1 instance and hence reverted from Infinispan 5.1.6 to 5.1.2
For my needs I modified the existing cluster cache so it looks like this
<cache-container name="cluster" aliases="ha-partition"
default-cache="default" start="EAGER">
<transport lock-timeout="60000" />
<replicated-cache name="default" mode="SYNC" batching="true"
indexing="LOCAL">
<locking isolation="REPEATABLE_READ" />
<store class="org.infinispan.loaders.file.FileCacheStore"
preload="true" passivation="false" fetch-state="true" purge="false">
<property name="location">
/tempCacheIndex
</property>
</store>
</replicated-cache>
Then to actually be able to query the cache create the org.infinispan.query module containing the jars mentioned in the following module.xml
<module xmlns="urn:jboss:module:1.1" name="org.infinispan.query">
<resources>
<resource-root path="avro-1.5.1.jar"/>
<resource-root path="hibernate-commons-annotations-4.0.1.Final.jar"/>
<resource-root path="hibernate-search-4.1.0.Beta1.jar"/>
<resource-root path="hibernate-search-analyzers-4.1.0.Beta1.jar"/>
<resource-root path="hibernate-search-engine-4.1.0.Beta1.jar"/>
<resource-root path="hibernate-search-orm-4.1.0.Beta1.jar"/>
<resource-root path="infinispan-query.jar"/>
<resource-root path="jackson-core-asl-1.9.2.jar"/>
<resource-root path="jackson-mapper-asl-1.9.2.jar"/>
<resource-root path="lucene-analyzers-3.5.0.jar"/>
<resource-root path="lucene-core-3.5.0.jar"/>
<resource-root path="lucene-grouping-3.5.0.jar"/>
<resource-root path="lucene-highlighter-3.5.0.jar"/>
<resource-root path="lucene-memory-3.5.0.jar"/>
<resource-root path="lucene-misc-3.5.0.jar"/>
<resource-root path="lucene-smartcn-3.5.0.jar"/>
<resource-root path="lucene-spatial-3.5.0.jar"/>
<resource-root path="lucene-spellchecker-3.5.0.jar"/>
<resource-root path="lucene-stempel-3.5.0.jar"/>
<resource-root path="paranamer-2.3.jar"/>
<resource-root path="slf4j-api-1.6.1.jar"/>
<resource-root path="snappy-java-1.0.4.1.jar"/>
<resource-root path="solr-analysis-extras-3.5.0.jar"/>
<resource-root path="solr-commons-csv-3.5.0.jar"/>
<resource-root path="solr-core-3.5.0.jar"/>
<resource-root path="solr-solrj-3.5.0.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="org.hibernate"/>
<module name="org.infinispan" services="import" export="true"/>
<module name="org.apache.commons.codec"/>
<module name="org.apache.commons.io"/>
<module name="org.apache.commons.lang"/>
<module name="com.google.guava"/>
<module name="org.slf4j" export="true"/>
<module name="org.jboss.logging"/>
</dependencies>
Modify the org.jboss.as.clustering.infinspan module xml to include a dependency on the new query module but also the org.hibernate module that already exists. So add the following to that file.
<module name="org.hibernate" services="import"/>
<module name="org.infinispan.query" services="import"/>
The jboss-deployment-structure.xml of your app needs to have the following dependencies added to it
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module export="true" name="org.hibernate" services="import"/>
<module export="true" name="org.infinispan" services="import"/>
<module export="true" name="org.infinispan.query" services="import"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
For annotating your objects so they can be indexed and searched I suggest you look at the samples here
EDIT:
FURTHER NOTE:
To get indexed objects to actually share over the cache I now had to
Create a jar containing all the classes that you plan to put in the cache.
Make sure these entities do not contain anything too complex it terms of imports or you'll run into class loader issues.
Create a module from this jar, and give it a dependency on the Infinispan.query module.
Expose this module as a global module (is this actually needed?) in the standalone.xml or domain.xml whichever is appropriate.
Find the file modules/org/jboss/as/clustering/infinispan/main/module.xml
Add your new module containing your cachable entities to the list of dependencies