We are right now on WAS 8.5 and are trying to move to Liberty. Our applications are using a lot of SOAP calls and among them, there is a one that is using a relative namespace that is raising an exception. I know that using a relative namespace is not recommended but we are the client not the producer. There is a way to handle that in WAS 8.5 by adding the parameter "com.ibm.wsspi.wssecurity.dsig.relativeNamespaceAllowed=true".
Is there such a parameter in Liberty ? Otherwise, we are stuck.
Liberty changed it's JAX-WS implementation from what was used with WAS 8.5, and it doesn't support the same behavior that this property allows. That being said it might be possible implement it, if it's a requirement for your application I suggest opening a support ticket with IBM. There have been other JAX-WS behavioral differences that have been brought into Liberty for users that have requested it through support, and this might be such a case.
Related
So I'm developing an application on top of Dropwizard and in one component I have to call an external rest service. I want to do it using JerseyClient.
Now there are 2 implementations available, the one from dropwizard and one from jersey. Using the Builder I have to choose between
io.dropwizard.client.JerseyClientBuilder.JerseyClientBuilder
and
org.glassfish.jersey.client.JerseyClientBuilder
Now the former requires Environment as well as JerseyClientConfiguration being passed to it.
Is there a good reason for using the dropwizard implementation over the vanilla one? What's the difference (except the timeout)?
Thank you
After some more digging and asking around, got an answer (below). It seems that it is better to use the JerseyClientBuilder that comes with Dropwizard as it is better integrated:
One can use JerseyClientConfiguration in order to configure the JerseyClientBuilder via the application configuration (service.yml file).
Passing the Environment information enables use of the managed thread pool that is integrated within Dropwizard's lifecycle, so when Dropwizard gets shut down, so does the client.
Dropwizard's Metrics get integrated into each client so you can see the latency and rate of calls for each one, as well as metrics around the thread pool sizes.
I am just wondering, if the below is possible with Websphere or not?
I have an Enterprise application using Websphere 7 and with PARENT_LAST classloading mode. I am now trying to use a third party feature namely, gemfire in the application. My application with gemfire runs perfectly in PARENT_FIRST classloading mode. But, I can see some linkage errors occuring because of PARENT_LAST setting. Temperarly, I could solve them by removing the classes that are conflicting from gemfire jar(By this, I am actually asking those removed classes to be loaded from web app server). But, I am not sure if this will create some bigger issues as my appliaction grow to its fullest.
My question is : Suppose we have abc.jar in both web app server and also in gemfire.jar, with PARENT_LAST loading mode.Is it possible to solve the above class conflicts by not removing any class files from jars, instead tell the classloading mechanism to use the class loaded from web app server at a particular case and use the same class loaded from gemfire jar(meaning load from application) at another case?
Thanks
Yes, it is possible. We are using a similar setup. You should be very careful though and only use the exact same jars (or at least the same classes) in all the places you need to have them.
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.
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).
Is there a way to call an EJB that is served through WebSphere (iiop://host:port/ejbName) from a vanilla JRE (like Sun). A lot of people have been telling me that this type of architecture relies in a homogenous environment. Thoughts?
Yes, this is possible. You have to create something called a thin client. It has limitations on JNDI lookups due to not being part of the container environment, so fully qualified names have to be used.
Just search for "thin client ibm ejb" on google. Unfortunately, I don't have the link to the appropriate libraries (for WAS 6) here, they are at work.
Although it’s possible, I wouldn’t recommend it because you’re asking for troubles using RMI-IIOP in a heterogeneous environment.
My approach would be to expose the EJB as a web service and consume at the client.