In application where it requires Spring 2.0 jar and wants to interface with webservice but client.jar provided by webservice host require spring3.0 jar.. so is there any way to implement both versions of Spring?
Related
I have to get some information from an external SOAP web service using a web application deployed on Tomcat 7. This external web service requires TLS with mutual authentication.
As a starting point, I have installed Tomcat 7.0.96 in my desktop computer and, using the external web service wsdl file, I have put a dummy web service up, that mimmicks the real one, returning some hardcoded objects when queried. I have used Apache CXF 3.3.8 .
I also have a web application that acts as a proxy for another web app, and as a client for the external (test and production), and dummy (local) web services.
Proxy web app requests objects from dummy web service. Mutual TLS authentication is assured using keystores present in CXF 3.3.8 samples.
In my desktop computer, everything works fine, my dummy web service serves the objects as expected.
Problem arises when I ask to deploy the proxy web app on a test server that I do not control. This server runs Tomcat 7.0.76 over CentOS 7. When the proxy web app tries to create the external web service client, an exception throws:
java.lang.ClassCastException: com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy
I have searched for documentation about Java proxies and service loaders. Test server has three jaxws-xxx.jars in /tomcat/lib folder. AFAIK these jars are Metro web services API and implementation. I have a copy of these at my local tomcat/lib folder, and I can reproduce the problem.
I have included a Context.xml file in my proxy web app. Depending upon I include an Loader element in Context.xml, setting Loader attribute delegate to true or false, I am able to reproduce or solve the problem.
But when I deploy the proxy web app in test server, including Context.xml as explained, the aforementioned exception always arises.
I have included some lines in proxy web app printing to log implementation classes showed in ServiceLoader Java class iterator. At my local PC, com.sun.xml.ws.spi.Providerimpl appears before of after org.apache.cxf.jaxws.spi.ProviderImpl depending upon Loader "delegate" attribute value, as expected.
But using the same Context.xml webapp file, at the test server, sun's spi appears always before cxf's.
Has anybody faced this problem? Any suggestions? Thanks in advance
You should ask the external Tomcat admin, why did he include JAX-WS RI libraries in the common classloader. IMHO opinion they shouldn't be there, but in the applications that use it.
Nevertheless your application classloader should pick the CXF implementation of JAX-WS unless:
the <Host> container has deployXML="false" and it ignores the META-INF/context.xml file in your application. If this is the case you can copy it manually to $CATALINA_BASE/conf/<enginename>/<hostname>/<contextname>.xml
the $CATALINA_BASE/conf/context.xml has a <Loader> component with delegate="true".
I am developing a web application using JSF 2.3. I need to create a Servlet which makes an HTTP connection to an URL and get a JSON object and process it. There are many third party APIs available for this sake, but I am more interested in using HttpClient which comes default in JDK11 onwards.
But the problem I face here is, I cannot use HttpClient without modularizing i.e. defining it as a requirement in module-info.java for my application. And, if I define module-info.java I can't get servlet classes reference resolved in my code. javax.* dependencies and other third party dependencies are not resolved. All the required libraries are present. So my question is
Q1. How can I use HttPClient in a Java web application with servlets, and JSF framework?
Q2. How do I resolve third party dependencies in a moduler java application?
I am using Payara server 5, JDK-11, RHEL 7.9
I had an application running in Webphere 6 and JDK 1.6. Now I'm trying to migrate it to Whephere Application Server 8.5. I get a problem related to libraries used to consume SOAP Services (Im using CXF). The problem is that Webphere in this version, has its own libraries to do this (AXIS2). I followed IBM recomendations
'Using a third-party JAX-WS web services engine'
-https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_thirdparty.html-
IT DOESN'T WORK FOR ME
However, I found that someone solved it removing a file from the META-INF AXIS2 library in Websphere. (javax.xml.ws.spi.Provider) =====IT WORKED===== But now I'm having other derived problems
org.springframework.web.util.NestedServletException: Handler processing failed;
nested exception is java.lang.NoSuchMethodError
org/apache/ws/commons/schema/XmlSchemaCollection.read(Lorg/w3c/dom/Document;Ljava/lang/String;)Lorg/apache/ws/commons/schema/XmlSchema;
(loaded from file:/usr/IBM/WebSphere/AppServer/plugins/org.apache.axis2.jar by org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader#41aaaf6e)
called from class org.apache.cxf.common.xmlschema.SchemaCollection (
loaded
from file:/usr/IBM/WebSphere/AppServer/profiles/AppServer01/installedApps/CLDC462Cell01/MyApp.ear/myapp.war/WEB-INF/lib/cxf-core-3.1.5.jar
by
com.ibm.ws.classloader.CompoundClassLoader#5344aede
Your app is picking up some Apache classes from the WebSphere libraries rather than from your application, and the version in WebSphere is incompatible with the app's version of CXF. This means that you're going to need to add a jar containing an appropriate version of org.apache.ws.commons.schema.XmlSchemaCollection to your application. I presume that you're running with PARENT_LAST delegation in your web module already, given that you're using your own web services implementation, but if not, that will be necessary as well.
I need to access information about all bundles and services of a remote AEM application (Apache Felix).
Information needed for bundles:
Exported packages and version
Imported packages and version
Bundle status
Information needed for service:
Implemented interface
Ranking
path, resourceTypes, selectors for Servlets
How could we possibly gather all the above information via a Java program?
I cannot deploy any custom remote Service on the OSGi container. Have to gather all the details, only via a Remote Java program executed externally.
Chapter 137 of the OSGi Compendium defines the OSGi REST Management Service. This provides all of the information that you're asking for using standard DTOs in a simple REST model.
The URI framework/bundles will list bundles which can be introspected using framework/bundle/{bundleid}, and framework/services will list services which can be introspected using framework/service/{serviceid}
As requested, this solution does not make use of remote services, but as mentioned in one of the comments there is no way to introspect a remote OSGi framework without installing something. In this case you must add a REST Management Service implementation to the remote framework.
Is it possible to create a client that accesses an EJB3 bean, with the client having no dependence on a vendor JAR or configuration? We currently need to support scenarios where our service is deployed on a WebSphere or JBoss server, and the client is deployed as an application either on a WAS or JBoss, or is running as a standalone app.
I used to be able to do to this with EJB2.x beans, I just needed to create stubs using RMIC.
But with EJB3, If I'm connecting to WebSphere I have to include thinclient JARs, plus I have to pre-generate the stubs using WAS tools. For JBoss I have to use jboss-client.jar.
No, this is not possible. This has been made explicit in section 10 of the EJB 3.2 specification:
This chapter describes the interoperability support for accessing an
enterprise bean through the EJB 2.1 remote client view from clients
distributed over a network, and the distributed interoperability
requirements for invocations on enterprise beans from remote clients
that are Java Platform, Enterprise Edition (Java EE) components.
Distributed Interoperability is not defined for the EJB 3.x remote client view.
Also note section 10.5.5:
System value classes are serializable value classes implementing the
javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData,
java.util.Enumeration,java.util.Collection, and java.util.Iterator
interfaces. These value classes are provided by the EJB container
vendor. They must be provided in the form of a JAR file by the
container hosting the referenced bean. For interoperability scenarios,
if a referencing component would use such system value classes at
runtime, the Deployer must ensure that these system value classes
provided by the container hosting the referenced bean are available to
the referencing component. This may be done, for example, by including
these system value classes in the classpath of the referencing
container, or by deploying the system value classes with the
referencing component’s application by providing them to the
deployment tool.
For WebSphere Application Server, the EJB thinclient contains these system value classes as well as the IBM JNDI implementation that uses CosNaming. In theory, this thinclient is not needed if you don't need the system value classes and your client JVM has its own ORB with an implementation of CosNaming.
Short answer: No, it's not possible, as a client needs three things:
The interface classes.
The client libraries of the server AS (yes, sadly)
A configuration telling the client the server address/jndi lookup path (qa, prod etc.)
If your client is running on the same product (let's say JBoss to JBoss communication), you will not be in need of client libraries and just be able to do a remote lookup. If you have a mix of client/server application servers this will make things complicated, as you will have to run client libraries of one product in another server product.
Speaking of standalone applications running as clients, I'd just build and provide 1 heavy client jar/lib containing not only the interface classes, but also the client libs of both servers. Then providing a small helper class that returns the correct InitialContext created and based either on JBoss or Websphere depending on a flag in the client configuration.
I know this last idea ain't a clean solution, though might even work in a different AS product running as "client".