what are .jar.index files under Jboss modules folder? - jboss

What are .jar.index files under Jboss modules folder? What is their purpose?

Those are indexes built by Jandex to allow for a quicker usage and avoid loading classes when they are not required (for annotation parsing purpose for example)

Related

Best practice to dependency resolve in Jboss EAP

In case of war file deployment, there are two possible ways to resolve dependency in Jboss EAP:
we could keep all the dependent jar files in Jboss modules and get access of them using jboss-deployment-structure.xml file.
we could keep all the jar files in WEB-INF/lib folder inside war file.
Which one is the best practice to follow and why?
It depends on what you prefer.
#1 means you need to configure server and application(s), and this is more effective when you have more applications on server using these modules as dependencies. So you save space from duplicating libraries in more applications.
#2 means you have almost all dependencies in your deployment application => bigger file/directory (but don't forget some dependencies are automatically enabled by container based on what you use Servlets, JPA etc.).

What is the recommended way to modify the order of classpath entities when using Mule?

What is the recommended way to have jars from my $MULE_HOME/apps/app-name/lib/ directory take precedence over jars in $MULE_HOME/lib/opt directory?
MES 3.2.1's opt directory has mail-1.4.3.jar and I need mail-1.4.4.jar, the latter of which is in my application's lib directory. It appears, however, that the order in which these are loaded is inconsistent or fixed with Mule's libraries coming first.
I have hacked a solution by replacing mail-1.4.3 with mail-1.4.4 in $MULE_HOME/lib/opt, but would like a more robust way of doing this so I don't have to make the same change in all my Mule instances.
Thank you for your time!
You can embed your own JARs in your application's lib directory and use the loader.override property of the mule-deploy.properties deployment descriptor, documented here.
If you want to learn more about classloading in Mule 3, turn to this page.
In your case, your deployment descriptor should look like:
loader.override=-javax.mail

how can i use a shared lib in glassfish to avoid deployment of the huge libs?

I have to upload about 30M for my app since it uses a lot of libraries, log, web engine and so on.
I think there should be a way to share these libs on glassfish, but I failed to figure it out. I tried to put them in domain/lib/ext but does not work.
So where should I store these libs and how should I refer to them? thank you.
Why domaindir/lib/ext does not work?
from glassfish manual:
Optional packages are packages of Java classes and associated native code that application
developers can use to extend the functionality of the core platform.
To use the Java optional package mechanism, copy the JAR files into the domain-dir/lib/ext
directory, then restart the server.
Why domaindir/lib work?
To use the Common class loader, copy the JAR files into the domain-dir/lib or as-install/lib
directory or copy the .class files (and other needed files, such as .properties files) into the
domain-dir/lib/classes directory, then restart the server.
Using the Common class loader makes an application or module accessible to all applications
or modules deployed on servers that share the same configuration.However, this accessibility
does not extend to application clients.
If I remember well, you can also specify additional libraries in the classpath via the admin console (in Application Server > JVM settings or something like this). Then you can put them wherever you want.
(I had a quick look at Pascal's link, but I don't know if that's what they describe, if yes, my apologies for the duplicate answer.)
One option would be to put them in domains/domain1/lib. But actually, I suggest to read GlassFish equivalent to WebSphere's "shared libraries", including the comments.

JBoss Custom lib directory

I have this third party framework which comes with a huge set of dependent libraries, which by the way, have not yet been indexed in any Maven repository. I want to use this framework with some Web Apps, but for obvious reasons I don't want to put all those libraries under WEB-INF/lib, neither do I want just to place them all under server/default/lib to avoid mixing them with other local and third party libraries.
Is there some way under JBoss 4.2.2 or higher to specify a custom lib directory for certain Web Apps? It's possible and/or advisable to have something like server/default/lib/myAppLib?
Any suggestion on this regard?
You can add the following entry in your server/default/conf/jboss-service.xml for putting your jars in server/default/myLibDir:
<classpath codebase="myLibDir" archives="*"/>
To my knowledge, you have three options:
Package you WARs in an EAR and move the library JARs out of WEB-INF/lib and
place them in a lib folder at the root of the EAR. No extra configuration required. This (non portable) solution is described in Configuring JBoss shared libs.
Move the library JARs out of WEB-INF/lib and place them into server/xxx/lib.
Deploy the JARs in the deploy/ folder and disable WAR file class loader isolation.
I don't recommend option #3. Option #2 is what you don't want. This leaves us with option #1 (which is IMO the cleanest).
Related questions
Jboss shared library
In JBoss can I configure a “shared library” location?

Are there reasons to place a dependency in a web server's lib directory instead of including it in the War file?

If I have an dependency Jar for my application is it better to place it in the war files lib directory or to place it in the global application server (like Tomcat) lib directory? What do I gain by using one approach over another?
Diskspace springs to mind, but we live in a time when diskspace is cheap. Is there a memory usage difference? Can someone with more experience then me list the pros and cons of both options?
Generally speaking, it's much better to have WAR self-contained so you don't have to rely on the container configuration. It makes deployment much easier also. So try to put library in the WAR if you can.
However, I ran into cases when installing libraries to container makes sense. For example,
We have some internal libraries used by every webapp and they are huge. We install them to container so all the webapps use the same version and it saves on memory and diskspace too.
Libraries installed in WEB-INF/lib is not available to container. If you need to reference these in context.xml (like JDBC driver defined in Resources), you have to put them in server/lib.
If you want send log4j logs from all the webapps to the same file, you have to put log4j jar in the server/lib. Otherwise, each webapp uses its own logger.
If you want to use the container's resource management capabilities -- e.g. connecting to a SQL database and providing a JNDI lookup and connection pool for it -- then the container software itself will need access to the libraries and drivers to manage the resources.
Otherwise you probably don't want to install them in the server /lib directory and assume they are there and will work, as different web applications might have subtly different version requirements.
For a in-depth description of the class loader hierarchy implemented by Catalina, you should check Tomcat's Class Loaders HOW-TO. This will help you to understand when to make jars available to the container, to all webapps, to a single webapp only... and where to put them.