I'm trying to deploy jax-rs client application that use jersey on was 8.5.
I was hoping I won't need to pack jersey jars inside my war, because was will provide them.
But I'm getting this error when trying to invoke my servlet:
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [HelloJAXRSClient]: example.HelloJAXRSClient was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime
Is there something I can do to use was libraries so I won't need to pack them inside my applicaiton?
WebSphere 8.5 includes a JAX-RS implementation, but it's based on Apache Wink, not Jersey. So if you want to use what is already provided, I think you'll need to create a Wink client instead of a Jersey one.
Or, you can disable the WAS JAX-RS implementation which I'd guess will allow you to use Jersey instead, either deployed in your application or as a shared library as zargarf suggests.
You can create a shared library in the was admin console which point to a directory on the server. Then put your jar files in that directory. Associate the deployed application with the shared library. See: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftcws_sharedlib.html
Related
I am facing an issue in my restlet project where I have to code some operations only if the EAR is deployed in Websphere in a restlet server project. Is there any way we can get information through code to find out where is EAR/WAR deployed? (Is the EAR is deployed in Websphere or Tomcat or other servers).
Try to instantiate some WebSphere API class. If you get a NoClassDefFound, it's probably not running on WebSphere. You might have to do class.forName(Websphere class), so your code will compile outside websphere.
If you only need to check that for example in Servlet/Filter class you can look for servlet context attributes related to WebSphere, for example com.ibm.websphere.servlet.application.name = Default Web Application. You can find some attributes looi=king at the /snoop servlet if you have that installed.
Or, as Bruce suggested try to load some WebSphere class and be prepared for errors when they are not there.
I am working on a Server Migration Project from Weblogic to Websphere. The problem is that in Weblogic, we are already using a class specified as Startup-class in Weblogic (and arguments to the class like log4j config file) which is present in a jar which is added to Weblogic classpath by editing the startup script. This jar initializes a global log4j file which is for all the apps deployed on the server and not for any particular app. Each app is distinguished by a category of log4j.
Now I could not find a similar thing in Websphere. So what is the best solution? I can create a new application which would do all initializations like that of the startup classes. I thought of using startup-beans but read in some IBM documentation that they are deprecated due to EJB 3.1 Session Beans. Also how to make sure this app loads first? By giving Websphere xml file startup weight 1 like here?
I am using Weblogic 6.3.2 and Websphere 8.5
The WebSphere migration toolkit suggests to replace the WebLogic T3StartupDef and T3ShutdownDef implementations with either a ServletContextListener implementation, session startup bean (Singleton), or a servlet that is configured to load at startup time. If you haven't used the WebLogic to WebSphere migration toolkit, check it out. It provides a lot of help especially with deployment descriptor extensions.
The #Singleton session bean in EJB 3.1 replaces the proprietary WebSphere startup bean.
The best approach depends on the type of module you need the startup logic.
If you are considering the custom services option, note that the com.ibm.websphere.runtime package is not available in Liberty if you are considering the Liberty server.
It sounds like custom services (or a custom feature on Liberty profile) are the best analog if you need to run logic during server startup. Otherwise, if you just need to add a library to every application, then create a shared library and then either associate it with the server or associate it with specific applications or modules.
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 trying to get Tomcat 7 (comes with OpenEJB) to work with Jersey 1.9. I had my Jersey RestFUL service working with Tomcat 6. But as soon as I deployed the war file to Tomcat 7(OpenEJB) I get the following error.
I created a new dynamic web project in Eclipse and added the following jars to WEB-INF/lib folder without adding any extra code but I still got the same error. It seems like Tomcat 7's OpenEJB is not liking Jersey jars.
asm-3.1.jar
jersey-core-1.9-ea04.jar
jersey-server-1.9-ea04.jar
Caused by: org.apache.openejb.OpenEJBException: Unable to instantiate Application class: com.sun.jersey.api.core.ResourceConfig: null at
org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1685)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1482)
at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:293)
at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:263)
at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:693)
at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:588)
... 23 more
Caused by: java.lang.InstantiationException
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1682)
Check out Apache TomEE Plus it is Tomcat with JAX-RS already integrated. You can skip the part where you hunt down libraries and try to get them integrated and move on to the writing code part.
Here's a video on how to set it up in Eclipse using the Tomcat web adpater and a simple Dynamic Web Project.
On the note of using EJBs as RESTful services, there are plenty of people that do that especially when JPA is involved. Aside from getting transactions for free, you also don't need a JAX-RS Application subclass or to map any REST servlets. A small perk, but nice.
As well you can expose the same class as a #Remote object and invoke it over RMI, as an JAX-WS #WebService and invoke it over HTTP/SOAP, or just annotate it #LocalBean and you can use the same object internally without the HTTP overhead. Nice to have the flexibility.
This stack trace makes me wonder if ResourceConfig has a no-argument default constructor. You'd see this if the OpenEJB deployment expects on and doesn't find it.
Since REST is an HTTP API for web services, why would you be using it with OpenEJB? I would guess that the two would be mutually exclusive. I'd write services using session EJBs or REST services, but not both.
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?