we have to use a third party system which exposes SOAP Services. We developed and tested locally using JAXWS and Jetty. All is working fine. when the same is deployed with in WAS 7.0, it seems, it is using Axis2 library the same is throwing few errors.
Any help\idea on what configuration needs change to make our EAR to use JAXWS instead of Axis2?
Regards,
Axis2 is the JAX-WS implementation used by WAS 7, and it'll be picked up for any JAX-WS operations run on the server by default.
If your application is dependent on your own JAX-WS provider, as it sounds like you are, the procedure for using third-party web services engines is documented at https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_thirdparty.html
I happened to find the 8.5.5 document first, but the procedure is applicable to version 7 as well.
Related
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
Anyone knows the steps to run JAX-WS on Websphere 6.1? JAX-WS website doesn't lists any step. Though other frameworks like Apache cxf do list the steps to configure on Websphere 6.1
The ideal way is to use the free, supported WebSphere Feature Pack for Web Services. Although regrettably, this requires you to create a new Profile in WebSphere. But it provides integrated, supported JAX-WS capability without needing additional libraries.
Are you asking about using a specific JAX-WS implementation? Like the Reference Implementation? If so, is there a particular reason you need to use that one?
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?
I would really like to use SpringSource dm Server, but our customer requires us to run our apps on their application server (Websphere). Is there a way to integrate SpringSource dm Server with other application servers? At least dm Server is build on OSGi, and many other application servers (including Websphere) are based on OSGi as well. Is it possible to run a SpringSource dm Server as a websphere component?
SpringSource dm Server is based on the Eclipse Equinox OSGi framework (and should not be confused with the Spring DM technology, included in dm Server, which can run on Equinox, Apache Felix, and Knopflerfish).
However, embedding dm Server in another application server, such as WebSphere Application Server, based on Equinox would be a non-trivial piece of work. It would be necessary to get both products to use the same version of Equinox, which they currently do not, then modify dm Server to support embedding in the server (e.g. to integrate with the host server's application invocation mechanism, thread pools, and class loading scheme).
If you think this support is important, please raise a requirement (which requires a simple registration) against dm Server.
Spring DM is deployed on a Knoplerfish OSGi implementation.
Websphere is deployed on an Equinox OSGi implmentation.
So the question becomes - are the two interchangeable? They both support R4, so I would say, yes, they are.
The next question would be to check dependencies, particularly with respect to things like HttpServices.
I would say this would be ok, but I think the final proof would be try deploying it. Easiest would be to drop the bundles into a Websphere deployment. You'll need your bundles and whatever spring bundles you're using.
I'm also interested in this topic. Another way of looking at this problem is that you want an application depoyable in both Spring dm server and a traditional app server (Websphere, weblogic, JBoss, ...).
The OSGi containers are embeddable inside non-OSGi applications, so it is theoretically possible to deploy an app to both Spring dm server and the same app + OSGi container to a traditional app server.
Now, as usual, the devil's in the details, including such topics of web development and bridging servlets between the outer app server and the OSGi container.
I do not think that this is really the case ...
see the following link for this: http://apsblog.burtongroup.com/2008/11/websphere-7-osgi.html
But it seems on the other side, that the trend is clear ... there will be a time when OSGI based application can be deployed on Java EE application servers