I im developing a web application, its a servlet which basically acts as a front end for a web service, im using CXF for the web service client, the application is running on a WebLogic 9.10 server, every thing was working ok until the project owner decided to add ssl supprt, no big problem, since im using cxf whitout spring, i managed to configure the TLS parameters in the http conduit of the service client,also configured a keystore whit the server key, ca root certificate and a client certificate, tested under a development tomcat instance and worked fine.
Problems started when redeployed the app to the weblogic server again and started getting weird errors, first one was:
java.lang.ClassCastException: com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy
at org.apache.cxf.frontend.ClientProxy.getClient
then i realized than weblogic was loading its own implementation of JAX-WS, ok no probelm, just added a weblogic.xml whit "prefer-web-inf-classes" set to true, redeployed and now i got this exception:
java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the current class, com/adinfi/imgsvc/cm/service/CMBGenericWebServiceService, and the class loader (instance of <bootloader>) for resolved class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
That one got me, i thought something was wrong whit the class path,so i started removing jars from the application and still got some more linkage errors, last one i got is this:
java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "org/w3c/dom/UserDataHandler"
and this is how the "Web-Inf/lib/" directory of my application looks like now:
classes12.jar
classes12.zip
common.jar
common.resources.jar
commons-beanutils-1.8.0.jar
commons-discovery.jar
commons-logging-1.1.1.jar
commons-logging-api.jar
commons-logging-api-1.1.1.jar
cxf-2.2.5.jar
log4j-1.2.8.jar
ras.jar
runtimefw.jar
wsdl4j-1.6.2.jar
wss4j-1.5.8.jar
xalan-2.7.1.jar
xml-resolver-1.2.jar
XmlSchema-1.4.5.jar
xmlsec-1.4.3.jar
Any idea what im doing wrong? thanks in advance
Rollback the prefer-web-inf-classes stuff and follow the WebLogic specific instructions from the Application Server Specific Configuration Guide of CXF's documentation.
More precisely, provide a weblogic-application.xml as explained in the second option Pack war in an ear, deploy the ear with weblogic-application.xml with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
</weblogic-application>
Follow the additional steps of this post if required.
I am not sure to remember how I solved it.
I think the issue disappeared after removing the import of stax-api in my pom.xml file.
More precisely, in my case I had to exclude it from poi-ooxml.
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>3.9</version>
<exclusions>
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>
</exclusions>
</dependency>
Related
I have a Webservice implemented with jwsc for Weblogic 12c. It's a WAR file. The classes for the various beans used for the parameters and returns are added with the standard maven plugin, and everything looks OK.
It compiles and packages OK. But any attempt to deploy it gets "Unable to invoke Annotation processoror" (yes, spelt wrong) from the Admin console.
The stacktrace is below, but really doesn't provide much of a hint. I've searched for other questions/answers but have come up blank.
The supporting classes were originally generated with xjc and so had many annotations. I removed those in case that was the issue, but no change. So the only annotations are in the WS implementation class:
#WebService(name = "MyServicePortType", serviceName = "MyService", targetNamespace = "http://test/wsdl/getInfo/v1")
#WLHttpTransport(contextPath = "my-nbi", serviceUri = "/MyService")
#SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
public class MyServiceImpl implements OPLService {
There's just a single dependency in the POM:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>wls-api</artifactId>
<version>12.2.1</version>
<type>jar</type>
</dependency>
Possibly connected is that if I try to generate as a JAXWS web service (type="JAXWS" rather than type="JAXRPC" in the args to jwsc) that fails with:
error: Annotation processor 'com.sun.tools.ws.processor.modeler.annotation.WebServiceAp' not found
I've tried adding jars with that class (there are several supplied with weblogic) to the JWSC classpath but with no success (nothing seemed to change at all).
Any ideas on what to try next?
EDIT: One thing I missed was that WL seems to like its SOAP web services as an EAR (containing the WAR). I tried that but still got the error.
I then did what should have done earlier and started with the sample from the documentation (which uses ANT rather than maven, but builds an EAR). That worked, and I've slowly modified that towards the web service I actually need. When I've done, I'll try to work out what the differences are.
<Mar 20, 2022 11:55:57,636 AM UTC> <Error> <J2EE> <BEA-160228> <AppMerge failed to merge your application. If you are running AppMerge on the command-line, merge again with the -verbose option for more details. See the error message(s) below.>
weblogic.utils.compiler.ToolFailureException: Unable to invoke Annotation processoror
at weblogic.application.compiler.FlowDriver.handleStateChangeException(FlowDriver.java:55)
at weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:38)
at weblogic.application.compiler.AppMerge.runBody(AppMerge.java:168)
at weblogic.utils.compiler.Tool.run(Tool.java:159)
at weblogic.utils.compiler.Tool.run(Tool.java:116)
at weblogic.application.compiler.AppMerge.merge(AppMerge.java:198)
at weblogic.deploy.api.internal.utils.AppMerger.merge(AppMerger.java:94)
at weblogic.deploy.api.internal.utils.AppMerger.getMergedApp(AppMerger.java:58)
at weblogic.deploy.api.model.internal.WebLogicDeployableObjectFactoryImpl.createDeployableObject(WebLogicDeployableObjectFactoryImpl.java:186)
at weblogic.deploy.api.model.internal.WebLogicDeployableObjectFactoryImpl.createLazyDeployableObject(WebLogicDeployableObjectFactoryImpl.java:160)
at weblogic.deploy.api.tools.SessionHelper.inspect(SessionHelper.java:781)
at com.bea.console.actions.app.install.Flow$2.execute(Flow.java:541)
at com.bea.console.utils.DeploymentUtils.runDeploymentAction(DeploymentUtils.java:5787)
[Lots of console related entries removed]
Caused by: java.lang.AssertionError: Unable to invoke Annotation processoror
at weblogic.j2ee.wsee.compiler.WSEEModuleHelper.processAnnotations(WSEEModuleHelper.java:287)
at weblogic.j2ee.wsee.compiler.WSEEModuleHelper.processAnnotationsWithServiceLinks(WSEEModuleHelper.java:245)
at weblogic.j2ee.wsee.compiler.WSEEModuleHelper.processAnnotations(WSEEModuleHelper.java:178)
at weblogic.wsee.tools.WSEEWebAppToolsModuleExtension.processAnnotations(WSEEWebAppToolsModuleExtension.java:216)
at weblogic.wsee.tools.WSEEWebAppToolsModuleExtension.merge(WSEEWebAppToolsModuleExtension.java:109)
at weblogic.application.compiler.flow.SingleModuleMergeFlow.proecessModule(SingleModuleMergeFlow.java:33)
at weblogic.application.compiler.flow.SingleModuleFlow.compile(SingleModuleFlow.java:64)
at weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver.java:70)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:37)
at weblogic.application.compiler.BaseMerger.merge(BaseMerger.java:20)
at weblogic.application.compiler.flow.AppMergerFlow.mergeInput(AppMergerFlow.java:75)
at weblogic.application.compiler.flow.AppMergerFlow.compile(AppMergerFlow.java:40)
at weblogic.application.compiler.FlowDriver$FlowStateChange.next(FlowDriver.java:70)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.compiler.FlowDriver.nextState(FlowDriver.java:37)
... 116 more
After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?
I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)
I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.
I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)
I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.
I have installed Weblogic 12.1.3 as part of upgrade from Weblogic 10.3.6 to Weblogic 12.1.3
My application uses Jersey version 1.17 jars
However, after we install Weblogic 12.1.3, we get Jersey 1.18 Jars inside folder ORACLE_HOME/oracle_common/modules
The Jersey 1.18 Jars override the Jersey 1.17 jars which are bundled in our application and causes error in deploying our application.
We get error/warning messages as give below
WARNING: Return type javax.xml.bind.JAXBElement of method public javax.xml.bind.JAXBElement com.ipc.dms.dsfs.service.rs.DSFSResource.getEnterpriseContacts(java.lang.String,java.lang.Integer,java.lang.Integer,java.lang.String) is not resolvable to a concrete type
WARNING: Return type javax.xml.bind.JAXBElement of method public javax.xml.bind.JAXBElement com.ipc.dms.dsfs.service.rs.DSFSResource.getMediaServiceConfigList(java.lang.String) is not resolvable to a concrete type
The application is using ServletContainerInitializer class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer that is loaded from:file:/opt/oracle/oracle_common/modules/jersey-servlet-1.18.jar. This initializer overrides the one available in the system.
**********>
java.lang.NoClassDefFoundError: Could not initialize class org.jgroups.conf.XmlConfigurator
at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:216)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:93)
at org.jgroups.JChannel.(JChannel.java:142)
If we remove the Jersey 1.18 Jars from ORACLE_HOME/oracle_common/modules we DO NOT get these error messages.
However, removing jars from installation folder causes other issues.To be specific I get the issue mentioned below if I remove the Jersey 1.18 jars from from ORACLE_HOME/oracle_common/modules
weblogic.kernel.Default (self-tuning)'> <> <> <> <1467281457661> < BEA-149231 > < Unable to set the activation state to true for the application "dunkin".
weblogic.application.ModuleException: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
So, I need to know if we can configure our EAR to use older version of Jersey i.e Jersey 1.17 while deploying the application on Weblogic 12.1.3.
If yes, please provide configuration details.
You have got 2 options:
To include the <prefer-application-packages> tag in the weblogic-application.xml of your ear as below:
<weblogic-application>
<prefer-application-packages>
<package-name>com.sun.jersey.*</package-name>
</prefer-application-packages>
</weblogic-application>
To inlcude the <wls:prefer-web-inf-classes> tag in the weblogic.xml of your war file as below:
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
If you decide to use option 2 then all the common libs of weblogic will be overidden by the libs of your application. So I would suggest to go with option 1.
I'm trying to develop an application which uses a library with a stax-api as a dependency. Build as stand-alone application it works fine, but when I'm trying to load JAR with dependencies assembled in my application using JCL, I get the following error:
javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at org.codehaus.xfire.util.STAXUtils.<clinit>(STAXUtils.java:48)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:54)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:422)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:360)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at eu.unicore.security.xfireutil.client.ReliableProxy.handleRequest(ReliableProxy.java:122)
at eu.unicore.security.xfireutil.client.ReliableProxy.doInvoke(ReliableProxy.java:102)
at eu.unicore.security.xfireutil.client.ReliableProxy.invoke(ReliableProxy.java:69)
at com.sun.proxy.$Proxy71.QueryResourceProperties(Unknown Source)
at de.fzj.unicore.wsrflite.xmlbeans.client.BaseWSRFClient.queryResourceProperties(BaseWSRFClient.java:372)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listServices(RegistryClient.java:199)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listAccessibleServices(RegistryClient.java:214)
at org.caebeans.wsrf.UNICOREModule.initialize(UNICOREModule.java:53)
... 9 more
It's rather strange, this class is assembled into the JAR, I can find it in archive.
I've seen this kind of message when application server libraries are loaded before application ones. Usually there's a setting that lets you specify the inverse order. If, as it seems, you're using Weblogic this may be achieved by inserting the following definition in your weblogic.xml file:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Try adding this Maven dependency:
<dependency>
<groupId>stax</groupId>
<artifactId>stax</artifactId>
<version>1.2.0</version>
</dependency>
I've got several Web apps running on a Tomcat 5.5 server, and I'm working on improving/updating the overall logging system used throughout the system. I already had some success with logback-classic. However, when I try to use logback-access (i.e. access the lbAccessStatus servlet), I get this exception:
exception
javax.servlet.ServletException:
Wrapper cannot find servlet class
ch.qos.logback.access.ViewStatusMessagesServlet
or a class it depends on
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
...
root cause
java.lang.ClassNotFoundException:
ch.qos.logback.access.ViewStatusMessagesServlet
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
...
I have everything set up according to the docs:
common/lib:
logback-classic-0.9.15.jar
logback-core-0.9.15.jar
server/lib:
logback-access-0.9.15.jar
Moving around the libraries doesn't seem to help. logback-classic seems to work fine, it's just logback-access that causes problems.
I've got it working. With maven and logback-classic the jars end in WEB-INF/lib and it works well.
I've seen the same error only when deploying old version of my WAR.
excerpt of dependencies section of my pom.xml
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.21</version>
</dependency>
... and relevant part of my web.xml:
<servlet>
<servlet-name>LogbackViewStatusMessages</servlet-name>
<servlet-class>ch.qos.logback.classic.ViewStatusMessagesServlet</servlet-class>
</servlet>
<!-- see http://localhost:8080/oam-portal-portlets/logs -->
<servlet-mapping>
<servlet-name>LogbackViewStatusMessages</servlet-name>
<url-pattern>/logback</url-pattern>
</servlet-mapping>
I haven't used logback-access with tomcat, yet. I only used it with jetty...
I'd suggest to try the following setup, though:
common/lib:
logback-access-0.9.15.jar
logback-classic-0.9.15.jar
logback-core-0.9.15.jar
server/lib:
logback-access-0.9.15.jar
logback-core-0.9.15.jar
logback-access has logback-core as a dependency. Since you use it both in the server (the Valve) and in your webapp (the ViewStatusMessagesServlet) you should add it to both classpaths.
You could (and should?) also add logback-access, logback-classic and logback-core to your webapp classpath instead of adding it to common/lib, making it available to all webapps.
Hope that helps.
If you put logback-access in common/lib too, so all the jars are there, it should be available everywhere. Have you tried that?
Also logging has been reworked in Tomcat 6. Is upgrading a possibility?