We Keep Coding

I18nProvider defined in WAR causes other WARs in web server to crash

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?

java.lang.NoClassDefFoundError while deploying the War in websphere which uses Couchbase cache

I am facing the below error while deploying the war file in Websphere-8.5.5
Caused by: java.lang.NoClassDefFoundError: org/apache/http/params/SyncBasicHttpParams
at com.couchbase.client.ViewConnection.createConnections(ViewConnection.java:120)
at com.couchbase.client.ViewConnection.<init>(ViewConnection.java:100)
at com.couchbase.client.CouchbaseConnectionFactory.createViewConnection(CouchbaseConnectionFactory.java:184)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:247)
at com.couchbase.client.CouchbaseClient.<init>(CouchbaseClient.java:179)
at com.infosys.aham.services.utils.cache.CouchbaseCacheManager.instantiateCouchbaseManager(CouchbaseCacheManager.java:145)
at com.infosys.aham.services.utils.cache.CouchbaseCacheManager.<init>(CouchbaseCacheManager.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:56)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:527)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)
... 87 more
I am using Couchbase-Client -1.1.9 and http-core-4.1.3
The http-core jar is bundled in the war file /web-inf/lib folder.
Also while looking in the websphere EnterprizeApplication-->application -->Manage Module --> moduleName--> ClassLoaderViewer --> LoaderView
The http-core-4.1.3 is there in the table (jar is present in the classpath).
(I also tried with the http-core 4.1.1 jar.)
The application is still not able to find the class present in the given jar.
I am new to websphere, please help me out with this.
Thanks in advance.

The http-core classes are already included in WebSphere. To use different implementation create isolated shared library with conflicting libraries and map it to the application.

JBoss Error: Could not load class designated by HandlesTypes

I am getting these weird JBoss errors while deploying the war file.
INFO [org.jboss.web] (MSC service thread 1-3) JBAS018227: Could not load class designated by HandlesTypes [com.companyName.ClassName].: java.lang.ClassNotFoundException: com..companyName.ClassName from [Module "deployment.projectName.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
These look information error but it is causing further issues in the deployment.Using JBoss EAD 6.1

Check if you have your .class (compiled file) into your .war -> classes (directory).
In my case, I had a class implementing WebApplicationInitializer interface (Spring interface) and Wildfly 8.2 couldn't load it... it needs to have .class file into /WEB-INF/classes folder...
I solved my problem moving my file to my web app module (.war) because the bug is solved in Wildfly 9 only at this moment.
see: enter link description here

Migrating to JBoss 6.1, add spring for cxf

I am porting an application from JBoss 4 to JBoss 6.1 EAP. This application uses cxf with spring. Our client's requirement is that we will not change (or add) modules for jboss.
In the jboss cxf module, there is an optional dependency to spring, but by default there is no spring module. I was wondering:
Am I required to add a spring module to JBoss?
Can I just add the spring jars to my application lib directory?
What's the best and/or easiest way to get this to work?
If I don't create a spring module and add the spring jars to the application lib directory, I get the following error:
09:19:44,203 WARN [org.jboss.modules] (MSC service thread 1-1) Failed to define class org.apache.cxf.transport.servlet.CXFServlet in Module "org.apache.cxf.impl:main" from local module loader #1f06dc3 (finder: local module finder #1b64e6a (roots: C:\dev\jboss-eap-6.1\modules,C:\dev\jboss-eap-6.1\modules\system\layers\base)): java.lang.LinkageError: Failed to link org/apache/cxf/transport/servlet/CXFServlet (Module "org.apache.cxf.impl:main" from local module loader #1f06dc3 (finder: local module finder #1b64e6a (roots: C:\dev\jboss-eap-6.1\modules,C:\dev\jboss-eap-6.1\modules\system\layers\base)))
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:427) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.Module.loadModuleClass(Module.java:526) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:399) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:399) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316) [rt.jar:1.6.0_17]
at java.lang.Class.forName0(Native Method) [rt.jar:1.6.0_17]
at java.lang.Class.forName(Class.java:247) [rt.jar:1.6.0_17]
at org.jboss.as.server.deployment.reflect.DeploymentClassIndex.classIndex(DeploymentClassIndex.java:54)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:85) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_17]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_17]
at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_17]
Caused by: java.lang.NoClassDefFoundError: org/springframework/context/ApplicationListener
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.6.0_17]
at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [rt.jar:1.6.0_17]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) [jboss-modules.jar:1.2.0.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) [jboss-modules.jar:1.2.0.Final-redhat-1]
... 22 more

tl;dr
Only if you want Spring to manage the lifecycle of your JAX-WS endpoint beans, which is no longer necessary.
No, not if you're trying to use Spring-based CXF features directly in your app. Refer to #1, but keep reading...
The easiest way is to let JBossWS manage your JAX-WS endpoints but have them extend SpringBeanAutowiringSupport to integrate with your app's ApplicationContext. Further details below.
Details
I faced the same problem - migrating an app with Spring-managed JAX-WS endpoints to JBoss EAP 6 (AS 7).
The problem is that JBossWS in EAP 6 is a double-edged sword. It makes it very easy to setup JAX-WS endpoints, abstracting away all knowledge of the underlying CXF engine from your app, but it requires you to relinquish some control over those endpoints.
Instead of using CXF's Spring namespace and defining your endpoints as Spring beans sitting behind a single servlet, you should now remove those beans from the Spring context and define each one as a servlet in web.xml (even though they are not actually servlets!).
JBossWS will auto-detect those pseudo-servlets at runtime and will build the necessary CXF infrastructure behind them.
This is all well-and-good, but what if you need to inject some Spring-managed dependencies into your endpoints?
SpringBeanAutowiringSupport to the rescue! Apparently this was the main reason for this class - to integrate Spring IoC with container-managed beans.
Have your endpoints extend this class, and then your dependencies can be injected via #Autowired (or the like).
Note that you should still use ContextLoaderListener as a listener-class in your web.xml to bootstrap your Spring ApplicationContext.
Note also that your app can now be totally agnostic of CXF - meaning you should not do any of the following:
extend or use any CXF classes directly
reference any CXF-provided Spring context files (e.g. classpath:META-INF/cxf/cxf.xml)
use any CXF namespace in your app's Spring config (e.g. xmlns:jaxws="http://cxf.apache.org/jaxws")
The downside is that your app can no longer use any advanced CXF-specific features, but hopefully this isn't necessary anyway.

classloading woes with Jboss & RestEasy using a separately deployed jar containing the javax.ws.rs.Application

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.