I recently started learning more about JBoss Application sever. After installation I was looking inside all directories created by JBoss installation. (I'm using JBoss AS version - jboss-5.0.1.GA)
I referred documentation available at this link
It says 'client' directory contains Jar files needed by remote clients.
client: The JARs that are required for clients that run outside of JBoss are located in the client directory.
When I looked inside 'client' directory after installation, it contains 90 jar files overall. Does that mean If I create a remote ejb client I would need to include all the 90 jars in my remote application classpath?
With JBoss AS 5.x things got complicated.
Placing all of the client jar files on classpath will certainly work.
In JBoss 4.x there was an option to use jbossall-client.jar which integrated other numerous client libs into single file. If you'll look into same named jar in JBoss 5.x you'll find out that it's reduced to manifest referencing other jars. Placing this single jar in your classpath will work as long as all of the jars referenced by manifest are present in the same directory.
If accessing remote EJB is all you need then only a subset of jars is required, unfortunatelly it's hard to tell which ones is it.
Following this coderanch link (I've found it here on SO) you'll find such subset prepared for JBoss 5.1.0.GA.
Be warned though, list of jars published on coderanch has abbreviated names, some misquotations and at least two jars are not present in server version 5.0.1. If reducing number of dependencies is your priority, use this list wisely and enhance/extend it by trials and errors.
Related
I'm doing some clean-ups in a GWT (no maven) project. It has a lot of jars added in WEB-INF/lib. I know the purpose of those jars (for example for REST service - luckily it's documented) so I wanted to put them in appropriate subfolders for nicer look.
After re-adding them to build path (as now they are in subfolders) I tried to run SuperDevMode and got multiple warnings:
Server class 'X' could not be found in the web app, but was found on the system classpath
and some errors like:
Cannot find a default implementation of the HK2 ServiceLocatorGenerator
When I put those jars back in WEB-INF/lib (without subfolders) and re-add to build path everything runs just fine.
My question is: can't/should't I use subfolders in WEB-INF/lib? If so, why?
Server class loader is programmed to look only into WEB-INF/lib, not other folder nor subfolders.
I strongly suggest to get into the maven world, it has a steep learning curve but it will assure to your project a solid foundation to grow on. Another big plus of Maven is that it can automatically pick up the latest security patch of your libraries (Equifax, anyone?).
Extract from the Apache Tomcat 7 Docs:
WebappX — A class loader is created for each web application that is deployed in a single Tomcat instance. All unpacked classes and resources in the /WEB-INF/classes directory of your web application, plus classes and resources in JAR files under the /WEB-INF/lib directory of your web application, are made visible to this web application, but not to other ones.
I am developing a Java EE 6 bottom-up JAX-WS to expose an EJB3.1 stateless session bean. The web service in a WAR is failing to install on deployment because it references an external jar (or shared library) which one can assume is not loaded yet.
The common suggestion is to include the jars in the /lib folder, which does fix the issue, however the jars need to remain in this external shared library location and NOT in the ear file, because they amount to 30MB.
What are some techniques to get around this issue in a Websphere (WAS v.8) environment or any server environment.
Some suggestions I have found include:
1. define classpath in META-INF file.
2. define the resources in deployment.xml
3. alter class loading order
4. (from ibm) In the case where the jars are part of a Shared Library configured on WebSphere Application Server, then a User Library must be used to configure the project for development before generating the WebService.
However, I have been unsuccessful to find any help online in these areas. Is there another technique or does anyone know anything about accomplishing this? Thanks in advance.
EDIT: If I specify the libraries in the META-INF using class-path, they are loaded before extensions, shared libraries..etc, but they are still loaded after the WAR which is not good. Again, this isn't a runtime issue because the web services are created at deployment on the fly.
I submitted a ticket to IBM. The libraries referenced by the web service are needed during deployment and must be bundled into the Ear in some fashion. I threw them in the web-inf/lib folder. However, if the referenced libraries then depend on additional libraries, these can be placed in the Shared Libraries. Seems odd to me too, but let's all just admit "shared libraries" are a hack anyways.
If you still have issues, just make sure your class loading is set to parent_last.
We want to simplify the deployment process of an app by including the MySql connector/j jar as part of the EAR. (so we won't need to manually copy it in the /lib folder of our Glassfish servers)
Is it possible?
UPDATE: We have read this is possible using the SAR files in JBoss, but we don't think it's available in Glassfish.
Because of the classloader hierarchy in Glassfish I don't think this is possible. The mysql driver jar needs to be available outside of your application's classloader because the connection pool is globally available.
http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesfp/index.html#indexterm-28
From what I can find, Glassfish doesn't support anything like .sar files:
http://old.nabble.com/Migrating-From-jboss-4.2.1-to-GlassFish-td18629992.html
Maybe vote for this issue, or create your own for a .sar-like deployment option:
http://java.net/jira/browse/GLASSFISH-16915
I'm trying to deploy an application to Tomcat 7 on a Windows server. I have a local copy set up and have tested with Eclipse without any trouble, but on the production server I get IncompatibleClassChangeError messages.
This had been a problem on the local server when there were problems with the classpath, but I configured the correct classpath in the server properties inside Eclipse and everything ran fine.
I'm new to Tomcat and from what I understand it should be reading jar files from my my WEB_INFO/classes directory, but when my jars are there the app doesn't want to load at all. When I move them to the $CATALINA_HOME/lib (I realize that's not where they should go) the app loads fine but reports the IncompatibleClassChangeError.
Why aren't my jars being read from WEB-INF/classes? Is there some configuration I should look at to fix this?
Webapp-specific JAR files should go in Webapp/WEB-INF/lib, not in Webapp/WEB-INF/classes. The Tomcat/lib should only be used for appserver specific libraries and optionally also JAR files which should be shared among the deployed webapplications.
There might be more into the IncompatibleClassChangeError, this can have an entirely different cause. But first try getting the JAR's in the right place. If in vain, then please update your question to include the detail message. This at least smells that you're putting JAR files of a different appserver make/version in the classpath.
i am wondering what is use of jbossall-client.jar ?
Up to JBoss version 4.2.3 these file contains client code for application.
But since JBoss 5.0 these file contains only dependences against other libraries from server client directory. If you want use it you must put also other jar file on in the same directory as jbossall-client.jar. These is excerpt from readme.txt file from jbossall file:
This jar file contains a classpath reference to various client jar files used by jboss client applications.
Each of the jar files in the following list must available in the same directory as the jbossall-client.jar, Otherwise they will not be found by the classloader.
In readme.txt you can also find the list jar files against which jbossall-client has dependencies.
It's a bundling of all JBoss client code into a single JAR, for those who don't want to bother with selecting the individual smaller JARs.