I am trying to write a JAX WS client for a service exposed using Axis2, WebSphere8, Java 1.6.
Standalone client(i.e. client running in my local machine) works fine but when I deploy the client in a application running in same websphere server I get
java.lang.ClassCastException: Cannot cast class org.apache.axis2.jaxws.spi.Provider to class javax.xml.ws.spi.Provider
at line OpenPortType service = OpenService
.create(wsdlFile.toURL(),
new QName( "http://www.test.com/schemas/public/open-api/Open/","OpenService")).getPort(
OpenPortType.class);
When I tried to google I found similar problem existed in weblogic : https://wso2.org/jira/browse/CARBON-4835
When we see source of axis2.jaxws.spi.Provider class we come to know that it's a subclass of javax.xml.ws.spi.Provider !!
I'm wondering what could be wrong ? Any idea ?
Unless you are calling Axis2 capabilities directly, rather than simply using JAX-WS APIs, you do not want to package Axis into your EAR. WebSphere does provide its own JAX-WS implementation which I'm not surprised conflicts with another JAX-WS implementation you've deployed in your app. (In particular, note that WebSphere's own implementation is based on Axis2.)
If you do need to deploy a different implementation, you'll probably have to at least adjust your WebSphere classloader policy to parent_last. There might be more to do as well; it's been a while since we did this ourselves. But it's much easier and cleaner to use the built-in JAX-WS implementation, which means not deploying any of those jars at all.
Related
I have managed to get weld CDI to work with jetty embedded for both servlets and rest. My question is: Is it possible to get CDI to work with WebSockets (JSR-356)?
CDI with javax.websocket is not well defined in the official JSR-356 spec, and wiring it up has proven sufficiently odd that each implementation is doing it differently, with different levels of support.
(This is likely because the JSR-356 spec was written to be intentionally unconnected to Java EE and Servlet in general, allowing it to exist in non Java EE environments)
There are a few open issues with it at the Jetty side.
423647 - New Extensions should be created via ServletContextHandler.createInstance(Class)
423645 - New ClientEndpointConfig.Configurators should be created via ServletContextHandler.createInstance(Class)
423367 - New ServerApplicationConfig objects should be created via ServletContextHandler.createInstance(Class)
423365 - New ServerEndpointConfig.Configurators should be created via ServletContextHandler.createInstance(Class)
423364 - New Encoders should be created via ServletContextHandler.createInstance(Class)
423363 - New Decoders should be created via ServletContextHandler.createInstance(Class)
423336 - New Endpoints should be created via ServletContextHandler.createInstance(Class)
I'm one of the maintainers of the websocket impl at Jetty, and would love to have someone help test the CDI integration (none of the Jetty developers themselves use CDI so its hard to get good, real-world, test cases to work against)
I have to develop a JAX-WS client which has to be deployed to WebSpehere 7.
WebSphere 7 uses a custom Axis2 implementation.
I've read on this guide (http://axis.apache.org/axis2/java/core/docs/jaxws-guide.html) to use wsimport to generate classes necessary for client.
But generated classes reference to com.sun.xml.ws.spi.ProviderImpl in jaxws-rt.jar (present in JRE6), while when client runs on Websphere they reference org.apache.axis2.jaxws.spi.Provider.
Is it correct? Using Oracle JDK wsimport is the correct way to follow also if clients will be use Axis2 implementation?
There should be a wsimport tool as part of your WAS installation. I found mine under /IBM/WebSphere/AppServer/bin
Try using that tool to generate your classes, instead of the one from Oracle. It should generate classes that are more compatible with WebSphere.
You could also go get Axis2 from Apache. I imagine that Apache's wsimport (or equivalent) will produce classes that are most server independent.
http://axis.apache.org/axis2/java/core/download.cgi
Use WebSphere's own wsimport. There's a script you can run, a WSDL2Java Ant task you can use, or if you have RAD, you can do it within that.
Artifacts generated by wsimport are portable, i.e. they don't contain references to implementation specific classes. The actual JAX-WS implementation is selected at runtime. Therefore, it doesn't matter whether you use Oracle's or IBM's wsimport.
I have an existing project that I am in need of configuring different. This needs to happen without major code changes. I am actually hoping I could somehow do this only with configuration. I have spent the past 2 to 3 days reading everything I can find on this issue. I understand the glassfish classloaders, and what is available to me.
I have a current sample project that has an EJB which defines a #Local interface.
The ejb is deployed inside an ejb-module as an ejb-module into the glassfish domain.
Now I am trying to find a way for another application which was deployed as an ear into the same domain, to be able to access that EJB via it's local interface.
I have read documentation that says this is not possible.
Then I have seen posts on here at StackOverflow, and other's on the web saying it is possible. But, I cannot find the actual solution.
With investigation, I have realised that the #Local EJB does not register itself onto jndi (atleast according to the logs), if I use the glassfish JNDI browser, I also do not see it visible. So it makes sense to me, that either it's not possible, or the deployment of the EJB project is at fault, and somehow I need to expose it.
#Remote is a possibility, if it can be by reference, and no performance overhead. But the preferred method allowing #Local EJB access is really the ultimate need.
Does anyone know what I would need to do to expose the #Local EJB to another application?
Or is this plainly not possible?
I am using Glassfish 2.1 With EJB 3.0
If Glassfish 2.1 can handle EJB 3.1 I would be willing to move to it if it provided this capability, but I doubt it's that easy.
Please assist.
Thank you.
I am adding a bounty. To complete the bounty, it would be required to run 2 ear applications in the same domain, where A.ear contains an #Local EJB that is used as well by the application in a B.ear.
The link #Peter gave you almost solves your problem. (link)
One trick which needs to be done to solve #Xavier's problem is to provide common.jar to both ears in the same version (loaded by the same class loader). If you do it, the class cast exception will not be thrown and you will be able to use the ejb with local interface.
To do it you need to put common.jar into glassfish/domains/domain1/lib folder (substitute domain1 with you domain name). This way this jar will be loaded by a Glassfish's shared class loader.
I made a quick test with Eclipse and Glassfish 3 with following structure:
package com.example;
JarShared
- #Local class Server
EarServer
- EjbServer
- #Stateless class ServerBean implements Server
EarClient
- EjbClient
- #Stateless #LocalBean class ClientBean
Lookup from ClientBean:
InitialContext ic = new InitialContext();
Server server = (Server) ic.
lookup("java:global/EarServer/EjbServer/ServerBean!com.example.Server");
I did not get ClassCastException and I could call sample method from ServerBean.
Important notes:
both EarServer and EarClient should not contain JarShared in lib folder, they should reuse the one which is in domains lib folder
remember to restart Glassfish after adding JarShared to it.
to make both ejb projects compile you must add JarShared to their build paths, but nothing more
If you have questions, post a comment.
I’m using Jboss 5, and invoking hundreds of EJBs with complex parameters.
There are some performance issues that I think are related to Java Serialization
As Jboss using JbossRemoting for remote invocations, I would like to use JbossSerialization to optimize serialization performance.
Like explained here, I'm using
-DSERIALIZATION="org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager"
at server side and in invocation code.
But JavaSerializationManager is still used by Jboss.
Can someone explain or exemplify how to configure JBOSS for using JBossSerializationManager.
In other words, what is the easiest way to make already deployed EJB application using Jboss Serialization instead of java Serialization?
This is confusing because JBoss remoting is a component that is used by JBoss Server. If you were using JBoss Remoting standalone that works (sort of). JBoss Server has its own set of config files.
For EJB3 calls you will need to update the InvokerLocator connection string in the location defined here. It looks something like below...
socket://myhost:6500/?datatype=test&loaderport=6501&marshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestMarshaller&unmarshaller=org.jboss.test.remoting.marshall.dynamic.remote.http.TestUnMarshaller
The parameter you want to add is here under 5.11.1
SERIALIZATIONTYPE (actual value is 'serializationtype') - indicates the serialization implementation to use. Currently, the only possible values are 'java' and 'jboss'. Java serialization is the default. Setting to 'jboss' will cause JBoss Serialization to be used. In implementation, this equates to the parameter that will be passed to the SerializationStreamFactory.getManagerInstance() method. This configuration can be set as an invoker locator url parameter (e.g. socket://myhost:5400/?serializationtype=jboss) or as an entry to the configuration Map passed when constructing a remoting client or server.
So you would append
&serializationtype=jboss
Note that there is no way to use JBoss Serialization for JMS that I could find.
I am trying to understand what is the correct way of usage JNI from Servlet.
As I understand there are several problems:
If native DLL crashes, it will bring down whole app server
If DLL is loaded by one class loaded, than another class loader won't be able to load and use it.
I searched internet and found couple of possible solution
Create standalone JMS enabled application and use JMS in Servlet to communicate with it.
Run standalone server, load in it JNI and talk to it through RMI
Use Java Connector architecture
I would appreciate any information on this subject, what is best practice in this case?
P.S. I am not sure whether it's important, but the application which needs to use native DLL runs on JBoss.
I would absolutely not run a JNI-based tool in a Java EE app server. Your suggestion for using JMS is a good one. You could create a service around message based Beans to respond to messages dispatched by your external service:
http://oreilly.com/catalog/entjbeans3/chapter/ch13.html
Here is the link to the Oracle Java EE documentation on Message-driven beans:
http://download.oracle.com/javaee/5/tutorial/doc/bnbpk.html
I would suggest getting two JBoss servers to talk to one another over JMS is easier than writing a JCA adapter, and that JMS message-driven beans are a cleaner interface. JCA doesn't seem to be evolving at all - there doesn't seem to be any great implementation tutorials (that's just my perception).