I'm using Vaadin 14.5.1 and Wildfly 17. I have several applications deployed in Wildfly. Now I'm implementing internationalization using Vaadin's I18nProvider interface.
So I created a TranslationProvider class which implements the interface in module A, and as per this guide I activate it using:
setProperty("vaadin.i18n.provider", TranslationProvider.class.getName());
After deployment, if I try to go to module B, it gives an error like:
Caused by: java.lang.ClassNotFoundException: my.module.A.TranslationProvider from [Module "deployment.B.war" from Service Module Loader]
The error is clear, my TranslationProvider is in module A, so of course module B can't find it. But the translation provider should be only for module A and nothing else. How should I go about this? Can I "disable" the system property once I exit from my module? Is there a way for other modules just to ignore it?
Related
When I am running my code the Console shows the following error
"Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for
C:\Users\Ankit
Singh\Downloads\spring-framework-5.1.9.RELEASE\libs\spring-context-indexer-5.1.9.RELEASE-sources.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider
class
org.springframework.context.index.processor.CandidateComponentsIndexer
not in module
Default Package delete.
Reinstalled Spring library
Two different way to call beans
Can someone suggested whats wrong in my system??
You might use a default package, right? I have had the same error as you...
Listen, dude, you can try to click: your project name-properties-java build path, move your external jar(s) from module-path to classpath. Then, you can run the code again.
I use GlassFish 4 web profile and I have the following interface and class.
#Local
public interface SomeService {
...
}
#Singleton
public class SomeServiceBean implements SomeService {
...
}
When I put interface and class in .war archive (that is in domain1/autodeplay) everything works fine. However, when I put interface and class in separate .jar archive (that is in domain1/lib) then deploying war application I get:
java.lang.RuntimeException: Cannot resolve reference Local ejb-ref name=com.temp.MyServlet/someService,Local 3.x interface =com.temp.SomeService,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:374) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.DefaultDOLVisitor.accept(DefaultDOLVisitor.java:78) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.ComponentValidator.accept(ComponentValidator.java:123) ~[dol.jar:na]
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:152) ~[dol.jar:n
...
I don't use any xml descriptors. So, is it possible to have EJBs in domain1/lib and if yes, how to make EJB container find them? P.S. I tried in GF 4 full - result is the same.
EJBs cannot be added as a library to GlassFish, libraries are just added to the classpath and any annotations on them are ignored and they do not go through the EJB container. If you do want your EJBs as a seperate JAR, they can be deployed just like a WAR or EAR file.
In the Glassfish reference manual for the add-library command it says that it "adds the library to the class loader directory", while for the deploy command it says that "Applications can be...EJB modules".
Also by looking at the source code for Glassfish it can be worked out that all libraries are simply added to the Classloader either at launch (See here and here) or if in applibs then when the application is deployed (See here).
I am deploying an EAR with the below structure to Wildfly 9.0.2
my.ear
|-my.sar (it is a SAR archive)
|-lib
|-myPreferencesImpl.jar
I am able to load the classes in lib/myPreferencesImpl.jar from my.sar (like class.forname(com.my.PreferencesFactory) directly. However, java.util.prefs.Preferences.factory is not able to load com.my.PreferencesFactory. I am passing Djava.util.prefs.PreferencesFactory=com.my.PreferencesFactory as command line parameter during WildFly startup.
Below is the exception thrown.
Caused by: java.lang.ClassNotFoundException: com.my.PreferencesFactory from [Module "org.jboss.as.jmx:main" from local module loader #76a3e297 (finder: local module finder #4d3167f4 (roots: /CSA_wildfly/wildfly/modules,/CSA_wildfly/wildfly/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at java.util.prefs.Preferences.factory(Preferences.java:254)
Please help me fix this.
UPDATE:
I finally fixed by migrating the startup service using JMX Service to a #Singleton + #Startup EJB. No other changes were required.
When you pass the arg Djava.util.prefs.PreferencesFactory=com.my.PreferencesFactory in command line, Wildfly is going to look for the class in the classes available to it, which is provided by way of modules . During the Wildfly bootup, it's not even going to know that there is a application with that class present, neither can it provide the same class to other deployments on the same container. So if you want the command line arg to work, make sure the deploy the Factory implementation as a Wildfly module.
I have a simple setup with a war file containing only a web.xml that specifies the javax.ws.rs.Application class to use in the servlet.
The jar that contains the implementation for javax.ws.rs.Application is also completely trivial. Both the web.xml and the implementation are based off the examples in jboss documentation
However, I get different behavior when I deploy the war + jar combination in jboss AS 7.1.1 Final versus jboss 4.0.4. Upon accessing the rest api I get the following exception in the jboss logs (snippet only):
06:33:59,540 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/wrapper]] (MSC service thread 1-2) StandardWrapper.Throwable: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.projectgoth.provider.restapi.RestApiProvider from [Module "deployment.wrapper.war:main" from Service Module Loader]
at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:271) [resteasy-jaxrs-2.3.2.Final.jar:]
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:259) [resteasy-jaxrs-2.3.2.Final.jar:]
If however, I change the scope of the jar from provided to runtime in the war's pom.xml - the error does indeed go away from jboss as 7.1.1.
For reference, I've uploaded the code use for both the war and jar to bitbucket (where provider = implementation for the javax.ws.rs.Application, and wrapper is the war deployable)
I think this is normal. Per class loader policy, a child class can always see the parent class not the vice verse. When you put the jar scope as runtime, the JAR is loaded in the classpath up in the stream than the WAR application and hence it's visible to the WAR classes.
I have a project with the following configuration:
WebSphere Application Server 6.1.0.19
wsdl4j-1.6.2.jar at the $WAS_ROOT/java/jre/lib/ext directory, (to overwrite wsdl4j-1.6.1 included in WAS 6.1).
cxf-2.4.0.jar (and others dependencies) at the $WAS_ROOT/lib/ext directory.
An EAR 'X' with a Web Module 'Y'.
The Web Module 'Y' has a JAR Module 'Z' (at the WEB-INF/lib directory).
'Z' has a set of classes that implement a SOAP Web Service generated using CXF's wsdl2java.
'Y' has a business class (at the WEB-INF/classes directory) that calls the SOAP Web Service Client at 'Z'.
This configuration works well at my development enviroment (Rational Application Developer with a WebSphere AS 6.1 runtime). But at the QA enviroment, I had the following exception, (please pay attention at bolds in the stack trace):
org.apache.cxf.bus.extension.ExtensionException
at org.apache.cxf.bus.extension.Extension.loadInterface(Extension.java:134)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:160)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.getBeansOfType(ExtensionManagerImpl.java:256)
at org.apache.cxf.bus.CXFBusImpl.getExtension(CXFBusImpl.java:99)
at org.apache.cxf.endpoint.ClientImpl.notifyLifecycleManager(ClientImpl.java:186)
at org.apache.cxf.endpoint.ClientImpl.(ClientImpl.java:117)
at org.apache.cxf.frontend.ClientFactoryBean.createClient(ClientFactoryBean.java:104)
at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:92)
at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:152)
at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142)
at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:464)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:331)
at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:318)
at javax.xml.ws.Service.getPort(Service.java:46)
at web.service.client.implementation.at.z.module.method(Unknown Source)
at business.class.at.y.web.module.method(AvisoCobroDAO.java:86)
... 32 more
Caused by: java.lang.ClassNotFoundException: org.apache.cxf.endpoint.ClientLifeCycleManager
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:472)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:373)
at java.lang.ClassLoader.loadClass(ClassLoader.java:561)
at org.apache.cxf.bus.extension.Extension.loadInterface(Extension.java:132)
... 51 more
Seems like the CompoundClassLoader (which works at application level) is trying to load a CXF's class which exists at the server runtime level.
I hope somebody help me with this issue. I'll be very very grateful.
Placing Jars in the WAS_HOME/lib/ext should be your last resort.
Always try the PARENT_LAST classloader mode and have your classes/jars picked up first.
This would avoid a number of problems for you.
The App Server start up would use this directory extensively and if there are clashes it might not even start up.
THe best way to troubleshoot is to turn on classloading and look at the native_stdout/stderr file and see who is loading the class(es) that is in question.
Bkail,
Did you mean to say things differently? This path is high up the class loader chain so it would be checked earlier (with the default PARENT_FIRST) class loading policy.
This would be in the second rung (after the BOOT CLassloader of the JDK) and it's extensions.
HTH
Manglu