I am using aws sdk package to access aws api from web application deployed in a websphere application. During build the application doesn't throws any compile time issue. After deployment it throws java.lang.NoSuchFieldError: org/apache/http/conn/ssl/AllowAllHostnameVerifier.INSTANCE
I read some post, it says about jar conflict. Its taking the default httpclient jars from IBM. I want to point my code to take my version of httpclient which I have given in lib folder. Can someone help me to point my code to pick my version of jars added manually.
In order to make your app use its own version of something that's included in the server, you'll need to use parent-last class loader delegation. Assuming the Apache HTTP client is in your web module's WEB-INF/lib directory, you'll want to make that change to the web module's class loader setting (this doc is specifically from 8.5.5 but should work on any version from the last decade or so): https://www.ibm.com/docs/en/was-nd/8.5.5?topic=loading-configuring-web-module-class-loaders
Note that parent-last delegation comes with its own set of risks, as there are some things that don't play well with the server if you try and use a version in your app (the Servlet API is one of the more notable ones). If you try this but run into things like ClassCastExceptions or LinkageErrors, you may instead want to put the HTTP client into an isolated shared library (selecting the "use an isolated class loader for this shared library" option) and associate the shared library with your web module or application: https://www.ibm.com/docs/en/was-nd/8.5.5?topic=servers-managing-shared-libraries
All that said, the simplest solution might just be to update your server. An APAR several years ago (PI50993, included in fixpack 8.5.5.9) removed the application visibility to the server's version of the Apache HTTP client. Moving to a recent fixpack would probably resolve the issue as well.
Related
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 just started developing with Java EE and JSF 2.x. Till now I'm very proud of my small applications with Connection to databases and ldap.
Now I need to connect to our Application API via some exteral jar libraries(C:\Program\A\lib1.jar, C:\Program\A\lib2.jar) so that I can add / change things / settings via JSF Webpages over Application API.
I have no idea how to solve this.
Any idea or helpful explanation or tutorial how to do that? (I'm using Wildfly 10.1) and I'm not using Maven.
Putting the jar files as dependency leads to a ClassNotFound exception.
It would be very helpful to get an example on how to add and accesses external jar libraries.
TL;DR
Is it necessary to have an HTTP router module when deploying an EJB module containing web service implementations to WebSphere 7?
If so, is there a way to create/manage it without relying on IBM-specific files?
I have an application that is being restructured so that it can be built Maven. Currently, I am using was6-maven-plugin's endptEnabler goal to build an HTTP router module for an EJB module that contains some web services. This works well, but I just found out that the build machine we'll get to use won't actually have WebSphere installed on it. In the past this wouldn't have been a problem, since the router module had been developed manually by someone clicking a "Generate Router Module" button in RAD and then actually checking in the generated code into source control. With the Maven-centric build process, we thought it would be better to generate the module during the build process.
So now I am stuck: generating the router module via Maven seems a much cleaner approach but won't work on the build machine. I have a few options:
Extract the generated WAR and add it to our enterprise repository and then create a dependency from my EJB to the WAR. I really don't like this, but it would probably work.
Go back to having a realized HttpRouterModule project in the workspace. The problem with this is that the IBM-specific binding files have valid module IDs for my server, but I don't know if they'd cause problems on someone else's which is why I'd rather generate these files from Maven.
Keep generating the router module with Maven, but find a way to generate it in a way such that there is no WebSphere dependency.
I'd prefer to go with the third option, but I'm not sure how I can generate the module and the binding files in generic way such that it will still be recognized by WebSphere.
I'm open to hearing about other options too...
As far as I know you need http router module. From my experience I was also unable to create the module manually. Is there no way you could install was7 dev server on your build machine? I believe it is free download from IBM.
All my research so far indicates that this is necessary in WebSphere 7, and in earlier versions. It looks like WebSphere 8 does not require HTTP router modules. We're going with the second option, as the build server won't be able to generate the router modules on its own.
Not ideal, but once we move to WAS8 this won't be necessary.
I am generating web service client in Eclipse Helios by Axis 1.4 version. The client stubs are working fine as per the expectation by using local main programs, but when I deploy the stub and application on GlassFish server, I am getting the following exception:
Edited : Now it gives exception like this ..
java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [META-INF/services/org.apache.axis.EngineConfigurationFactory], because it has not yet been started, or was already stopped
at org.glassfish.web.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2074)
at org.glassfish.web.loader.WebappClassLoader.findResource(WebappClassLoader.java:1034)
at org.glassfish.web.loader.WebappClassLoader.getResource(WebappClassLoader.java:1169)
Can anyone tell me why it is happening?
Its happening only when I deploy the application on GlassFish server.
Thanks,
Gunjan.
This refers to the similar problem you have. So as I mention in my comment, remove all Axis related stuff from global glassfish classpath, add them into your application and it should all be fine.
It is not a very good practice to keep framework specific libraries in the server global libraries. In the global classpath should go libs like JDBC, logging frameworks, but not WS stack specific libraries.
When deploying an application to JBoss server, for a JAR like ojdbc14.jar (Oracle JDBC), is it better to include this jar in the ear file of the deployment, or should it be deployed to JBoss's server/default/lib folder?
The argument I've been given is that the application needs to support global transactions, hence the datasource must be defined at the application server level (e.g. copied to server/default/lib folder) so it can talk to other app servers, and for that to happen you need the drivers at the app server level.
I'd like to hear what is the correct approach here. Thanks.
I believe this is the correct approach.
You will typically define your datasource outside of your application (outside of your EAR/WAR) using the appropriate configuration files depending upon the application server you are using. Whereas on JBoss, you usually add your configuration to XML files, with WebLogic, you can create a datasource directly using the Admin console.
Given that this datasource will be created on server startup, the necessary libraries (in your case, ojdbc14.jar) must be available on the classpath of the application server.
I have also come across licensing issues where the use of a 3rd party library prevents you from bundling it within your application.
Also, defining your datasource outside of your application means you do not have to perform a rebuild when the datasource configuration needs to change.
So many time I have done that...
I will always put the jar inside the server/default/lib folder if it has something to have about JDBC.
Because your database driver is loaded one time as soon as the server is started, and not each time you deploy/undeploy the webapplication your are working on.
Your datasources will be availiable for any others sub-projects too, and it will be a great advantage when you have a specific project for integration testing purpose.