I'm trying to deploy App bundled with Jersey 1.17.1 on WAS 9.0 and getting the CDIRuntimeException
java.lang.RuntimeException: com.ibm.ws.cdi.CDIRuntimeException: com.ibm.ws.cdi.CDIDeploymentRuntimeException: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.RuntimeException: com.ibm.ws.naming.util.CannotBindObjectException: Object is not of any type which can be bound. Object type is com.sun.jersey.server.impl.cdi.CDIExtension.
at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:196)
I tried this already without success from the link below i.e.
com.ibm.websphere.jaxrs.server.DisableIBMJAXRSEngine=true
Applications > WebSphere Enterprise Applications > {your.application} > Manage Modules > {your.module}, Change the Class loader order dropdown to: Classes loaded with local class loader first (parent last).
JAX-RS Jersey 2.10 support in Websphere 8
My goal is to use the war file as is with the bundled Jersey jars without having to create shared libraries. We are able to run this app on WAS 8.5.5 Is this not possible on WAS 9.0?
Thanks.
Related
I am trying to deploy my web application on WAS9 with JDK 1.8 , however it gives a error of CDI
Below is the error
java.lang.RuntimeException: com.ibm.ws.naming.util.CannotBindObjectException: Object is not of any type which can be bound. Object type is com.sun.jersey.server.impl.cdi.CDIExtension.
at com.sun.jersey.server.impl.cdi.CDIExtension.initialize(CDIExtension.java:196)
I removed Jersey 1.X version from war , but still this error.
In my local it work good with tomcat and same other application runs good in WAS 8
WebSphere v9.0.0.2 full profile does not provide anymore JSF v1.2 support it seems
Q: What about "legacy" apps that are written in JSF v1.2 + facelets (facelets was not part of the JSF standard at this time), can they be deployed to WAS v9.0 or are we stuck to WAS v8.5.5?
I didn't find a way in the doc to deploy a JSF v1.2 app on WAS v9.0 and my many tries were unsuccessful (problems with jar jsf-facelets.jar amongst other problems)
Q: Is there a workaround for deploying such apps on WAS v9.0?
We need also to deploy sucha apps on Liberty v16.0.0.4...
The best option will be to migrate your application to support JSF 2.2, which shouldn't be terribly difficult. There is some IBM documentation here for migrating your application from JSF 1.2 to JSF 2.0. Since your application already uses Facelets, however, you should be able to migrate your app via configuration changes; the instructions in this answer will probably be more helpful.
It is also possible to configure WebSphere to use a third party JSF provider - in that case, you could provide your own version of JSF 1.2 for your application. Documentation for that is here
Instructions for providing a custom JSF implementation:
Add the third-party listener to the web.xml file.
Add the third-party JSF implementation Java™ archive (JAR) files and its required dependant JAR files to the application as an isolated shared library and associate it with your application:
Move the JSF JAR files and all third-party libraries referenced by the JSF JAR files and UI component plug-ins (for example, PrimeFaces) to a directory outside of the application.
Create the isolated shared library. See topic Creating shared libraries for information about how to create the shared library.
Ensure that the classloader is set to PARENT_FIRST, the default value. To view the current configuration in the administrative console panel, click Applications > Application Types > WebSphere enterprise applications > application_name > Class loading and update detection.
I have a webapp running JAX-RS web services using the Jersey implementation. The target app server is a WebLogic 12c whose default JAXRS implementation is Jersey v1.9.
1) when run on Jetty (6.1.26) with jersey-server-1.9 dependency, everything is fine.
2) when run on WebLogic 12c with jersey-core.jar + jersey-server.jar (v1.9) jars both embedded in the WEB-INF/lib of my war, it is also working.
2) when run on WebLogic 12c with the same war amputed from these 2 jars (assuming there are not needed as already provided by the weblogic Java EE stack), it does NOT work anymore. I got the following error:
"weblogic.application.ModuleException: [HTTP:101216]Servlet: "jersey-servlet" failed to preload on startup in Web application: "cachede-newgen.war".
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.(RootResourceUriRules.java:99)"
Needless to say the Jersey version is exactly identical in all three cases:
"Apr 24, 2013 4:10:24 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.9 09/02/2011 11:17 AM'"
It sounds again (sight!) like a classpath or classloader issue :-(
Any idea or workaround to solve this issue (taking accound that I do NOT want to repeat jersey jars in every deployed war) ?
Ok I found the reason :-) - and "better_use_mkstemp" put me on the right direction (many thx!).
The solution consists in adding a reference to the deployed Jersey version in the weblogic descriptor file:
<library-ref>
<library-name>jersey-bundle</library-name>
<specification-version>1.1.1</specification-version>
<implementation-version>1.1.5.1</implementation-version>
</library-ref>
The strange thing is that, without such ref, the error message (ie "The ResourceConfig instance does not contain any root resource classes") gives the feeling that Jersey is able to start and scan your annotated classes...
NB: Actually, you also need a reference to the JSR-311 api, as explained here:
http://theblasfrompas.blogspot.be/2011/03/time-to-deploy-restful-web-service-from.html
Have you "deployed" the jersey jar to your server? In the admin console go to Deployables (click Customize the table and uncheck exclude libraries). See if Jersey is listed there. If not, you will need to "deploy" it and target whatever servers you need it on. Then try to redeploy your war file.
Jersey should live in:
wlserver_10.3/common/deployable-libraries
Those shared libraries aren't automatically available to your server until they are targetted to it.
Just remove all Jersey jars and add one Jersey Bundle jar it will work. I have faced the same Issue and resolved after adding Jersey Bundle jar into to class path.
I'm migrating an application that uses Spring security 3.0 to Spring security 3.1.
I have been getting an error about incorrect schema being referenced:
SEVERE: Exception sending context initialized event to listener instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration
problem: You must use a 3.0 schema with Spring Security 3.0.(2.0 or 3.1 versions are not
valid) Please update your schema declarations to the 3.0.3 schema (spring-security-
3.0.3.xsd).
Offending resource: ServletContext resource [/WEB-INF/security-context.xml]
When I look in /lib I see a number of jars that are 3.1 versions are duplicated as 3.0 versions. I suspect this is what is causing the error above.
When I look at the dependency tree of the pom.xml using the Eclipse Maven plugin, I can see where the earlier versions are being referenced (eg spring-security-acl depends on several 3.0 jars) but they are marked as 'omitted for conflict with...'. Does that not mean they should be omitted from the built war file?
I've tried explicitly naming 3.1 versions of those files at the root of my pom but the older versions still get included.
Offending resource: ServletContext resource
[/WEB-INF/security-context.xml]
Actually the message indicates that security-context.xml uses schema/declarations which are incompatible with spring-security-3.1. The message is requesting you to use a 3.0 version of the library instead. You may want to review and update it and retry.
I'm still not sure what was going on, but I tried creating a new project in Eclipse with the same pom and source files and now the project seems to behave itself.
I'm working on a project that delivers web services using Jersey, which has a dependency on JAXB 2.1. I have to add a feature that fetches data from another web service. The way this has been implemented elsewhere uses a Spring JaxWsPortProxyFactoryBean.
When Spring tries to initialize this bean it fails with a : ClassCastException (com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.bind.api.JAXBRIContext).
It appears that this is because JavaSE6 includes JAX-WS 2.0 API.
The only solution I have found suggests putting the 2.1 jars in the JRE endorsed directory. This isn't an option - I'm sharing a server with other application teams so I can't mess with the JRE.
Does anybody know of another way to make Spring use the 2.1 jars?