Develop Reference

Can we combine lib jars in EAR with shared lib reference in Websphere?

I dont seem to find a solution to that, I have the following problem :
I have a bunch of jar dependencies that are put in lib folder under my ear.
Besides, I put other jars in shared lib references.
When I reference the shared lib, I seem to have ClassNotFound from classes in the lib jar under ear, I do not know if we can actually have access to both anyhow?
Thanks a lot!

Assuming WebSphere traditional, shared libraries associated with the application will share a class loader with jars in the EAR/lib directory, unless you select the "use an isolated class loader" setting for the shared libraries - that gives them their own class loader that is not able to "see" classes in EAR/lib.
If your EAR/lib libraries aren't being found at all (from any scope), I'd suggest checking application.xml to ensure that your application is not declared as a Java EE <5 application - if the application.xml specifies J2EE 1.2-1.4, that predates the addition of library-directory to the specification, and the server will not add that directory to the class path.

JAR not loading in Grails web app when running on Linux JBOSS server [duplicate]

I am trying to add some dependencies jar files. But these files when put in lib/endorsed or in WEB_INF/lib.jar results in startup error for jboss instances. I suppose this is happening because flat classloader structure of JBoss. If somebody has implemented the classloader settings in jboss-web.xml
<class-loading>
<loader-repository>com.example:archive=unique-archive-name</loader-repository>
</class-loading>
Can somebody give me a real life example ?
Also where should I place these jar files - lib/endorsed of jboss, or lib folder in deploy folder or in WEB_INF/lib

Duffymo's directive on not putting jars in endorsed is ignored at your peril.
In some additional detail:
Placing libraries in your WEB-INF/lib is a best practice for portability and consistency as it adheres to a standard provision for creating self-sufficient and distributable web archives, but you need to pay close attention to the class-loading declaration you're putting in your jboss-web.xml.
Assume a simple scenario without the class-loading declaration and a fictional example.jar:
If you place example.jar in WEB-INF/lib and it does not also exist in jboss//lib, then example.jar will only be visible to that specific WAR.
If you place example.jar in WEB-INF/lib and it does also exist in jboss//lib, the instance in WEB-INF/lib will essentially be ignored and the WAR will use the JBoss server instance's unified class loader to load the example classes from jboss//lib/example.jar. (The same would apply to any other WARs or EARs in the same server instance, assuming no class-loading overrides.)
The class-loading declaration is necessary in cases (such as) where you have two different versions of example.jar:
- jboss//lib: example1.0.jar
- WEB-INF/lib: example2.0.jar
In this case, JBoss will create a unique and isolated classloader for your WAR which will avoid jboss//lib/example1.0.jar in favour of WEB-INF/lib/example2.0.jar in the context of your WAR.
In summary, if you're only running one WAR in the jboss server instance and/or you have no conflicting JAR issues, ditch the class-loading declaration and put your JARs in jboss//lib. It makes the WAR file more lightweight, overall deployment may be simpler and you will not consume additional memory with extra class versions during hot-deploys.

They belong in the WEB-INF/lib directory of your WAR file. Don't put things in the endorsed folder.

Difference between JARs and EJB JARs from a usage perspective

When I use Tomcat,
the common utilities are packaged as JARs in tomcat/lib
because every WAR has its own class loader,
and classes and libs under the WEB-INF/lib directoy of the WAR is not visible to other ones.
When I use Jboss,
the common utilities can packaged not only as JARs in jboss/lib but also as EJB JARs (invoked as services)
When I have some classes as common services, I can put them in JARs as well as EJB JARs.
I have no idea about the difference between JARs and EJB JARs from a usage perspective.
Can anyone guide me to the right path?

The difference is clear when you see the difference between the contents of a JAR vs a EJB JAR. Apart from the source files (compiled) and the manifest that a JAR file has, you'd also need the following (back in the pre-annotation days):
The XML deployment descriptor
The beans
The remote and home interfaces
Dependencies
This tells the container which are the EJBs and their home/remote interfaces so when a request asks for a bean, the container will know which one to invoke. Without these files, there is no way of you telling the containers (except annotations wherever applicable), that this the bean implementing an interface.
More information can be found at this url

ant: Need help packaging an EJB and its dependencies into an EAR

My goal is pretty simple: to use ant to build an EAR which contains 1 EJB and 1 jar containing all of the dependencies. This jar, called common.jar for the sake of example has vendor jar files in it as well as other xml files that the EJB depends on and will need to be able to see during runtime....
So far I have everything packaged correctly as an EAR like this:
EARFILE.ear
-EJBFILE.jar
/META-INF
-MANIFEST.MF
-common.jar
/META-INF
-MANIFEST.MF
/lib
-(all vendor jars inside here)
-(All the xml config files are inside the root of the common.jar)
Inside the MANIFEST.MF for the EJBFILE.jar is...
Class-path: ../../common.jar
Inside the MANIFEST.MF for the common.jar is...
Class-path: ../lib/some_common.jar
When I deploy this the appserver (websphere) cannot find the JAR file when I try to start the server. I am getting the ClassDefNotFoundError because the classes inside the EJB cant find the vendor JAR files when I try to start the instance. However I know that common.jar is setup correctly though, else the EJB wouldn't have compiled since it needed to have those vendor jars on the classpath for javac.
So what I want to know is this:
How can I get the runtime to correctly see the Vendor jar files.
Will the EJB be able to see the xml files at run-time? I am concerned about this because these xml files are located outside of the EJB inside of a jar that is just in the EAR, it isn't even a module its just a jar inside the EAR.
Does it even matter when using websphere? From what I gather some containers don't even care what is in the Class-path of MANIFEST.MF.

There are several improvements I can suggest, based on running into similar problems.
First and most importantly, use the appxml attribute of the Ant ear task to specify your deployment descriptor (usually named application.xml); also include references to the vendor JAR files bundled as defined below
I would recommend you not put your vendor JAR files into another JAR - instead, just copy them into the EAR at the same level as EJBFILE.jar
The configuration XML files can go in a sub-directory of the EJBFILE.jar (such as config), and then you can reference them as /config/filename.xml.
The application.xml file will tell WebSphere where to find your JAR files. Classpath traversal in an application server is not the same as that of a compiler, which JBoss has taught me the hard way.
I am using all of the above patterns, and my in-container code (deployed in the EAR) can see all my XML files, as well as find all my dependencies.

what does "class libraries on the classpath" mean?

could anyone please clarify the meaning of class libraries on the classpath in the case of Tomcat in the following line:
Actually all classes used by the web-app(unless they're part of the class libraries on the classpath) must follow the same rules as servlet classes-inside WEB-INF/classes, in a directory structure matching the package (or in the appropriate package directories within a JAR inside WEB-INF/lib).
What do they mean with class libraries and classpath in the above paragraph?

The classpath is a list of locations where the JVM should look to find classes. By default, this has things like rt.jar and vm.jar on it which contain the classes like java.lang.String. You can append directories and jars to the classpath to allow the VM to find classes beyond those installed by default.
A class library is a collection of classes packaged to be used by applications. For all practical purposes, it is a jar with useful classes in it like junit.jar.
What the message is saying is: If you want to use a library class (like something from log4j), it needs to be on the classpath, in WEB-INF/classes or WEB-INF/lib.

Sounds like they're distinguishing between the .class files in your web app, packaged in a WAR file using the standard WEB-INF idiom, and those on the app server itself (e.g., in server/lib and common/lib for Tomcat 5.x and lib for Tomcat 6.x).
The important thing for you to know is that Tomcat has a hierarchy of class loaders. You need to understand how they work to use Tomcat effectively.
UPDATE: If understanding CLASSPATH is your issue, you need to know that anything WEB-INF/classes and in JARs under WEB-INF/lib in your deployment are in the CLASSPATH, along with JARs that are installed on your app server that all deployed applications share. That's what I meant when I said common/lib and server/lib for Tomcat 5.x and lib for Tomcat 6.
I don't think I understand what your question is. Do you not understand CLASSPATH? The CLASSPATH is all the places that the JVM knows to look when it needs a .class file that hasn't been loaded yet. That includes the JARs available to all applications deployed on Tomcat and WEB-INF/classes and WEB-INF/lib directories for your particular deployment.