When I developed any web application I added many jars which my code depended on them.
I want to know when I deployed the war on the server how server or containers using these jars,
And if I but them on server's modules directly is it will be an advantage for publishing or deploying ?!
When your code is executed the container will look within your war to see if the dependent jar is available. If it cannot find the dependent jar within your war then the container will traverse it's tree to see if it can find the dependency somewhere within the container itself. Through configuration, it is possible to reverse so the war is checked last.
The war should be self-contained, with the dependent jars in the war's WEB-INF/lib folder. Configure the container (likely default) to check the war first. This maintains isolation which helps keep the app stable over time. For example, the container might be updated but your app should not need to be updated.
Deploying those dependent jars outside the war, to somewhere within the container to a shared folder, will likely make those dependent jars visible to all deployed apps and/or the container itself. This eventually leads to jar version conflicts and class loader issues. Don't do it!
There is no advantage using jar dependencies on the server classpath. This will force you to depend on the server itself which is not a good idea when dealing with continuous delivery.
BTW you shall know that every war file has it own classpath when deployed, so if you deploy some war, let's suppose on a Tomcat Server, it will use it's own classpath which contains the necessary jars. The container (Tomcat in this case) will know nothing about these jars but your application will.
Related
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.
How does WebLogic 11g load libraries in an EAR file? I have this problem with a web application, that when deployed as a WAR (with libraries it depends on in WEB-INF/lib), it works just fine. However, when it's inside an EAR file, WebLogic does not find those libraries unless I put them in APP-INF/lib. Does that mean that if I'm deploying as an EAR I'd have to pull out all JAR files from the WEB-INF/lib directory and place them in APP-INF/lib ? or is there a configuration that can be done in WebLogic to avoid this?
Thanks!
If you have JAR files that you need to share between multiple WAR files or between WAR files and EAR files then you will need to package them in the EAR.
If WAR#1 has a JAR in its WEB-INF/lib and is packaged in an EAR with WAR#2, then WAR#2 will not be able to see the JAR files in WAR#1/WEB-INF/lib.
Solving your problem will take some understanding of how Java EE classloading works in a container. You should look at this link to get an understanding, but the basic problem is that when you package your application as an EAR, you've introduced another classloader (the application classloader) into the class loading hierarchy. You can configure WebLogic to load from your webapp by using the prefer-web-inf-classes element.
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.
I plan to deploy an EAR packaged application into JBoss v4.2 as a folder containing the content of the EAR. Until now the EAR is deployed as a single file. I hope to be able to replace single JARs without the need to restart the application.
Is there any kind of event listener or annotation that can be used to register those JAR files upon deployment? The idea is a plugin like deployment of some features implementing a known interface. The plugins shall be used in a Seam webapp environment and may be exchanged with updated versions on the fly.
Any ideas? Thanks.
AFAIK, this is not possible/supported. When using an exploded EAR, touching an individual module would trigger the hot deployment of the whole EAR.
From Lightweight Java Web Application Development: Leveraging EJB3, JSF, POJO, and Seam:
3.4.2. Hot Deployment
Another JBoss feature that helps agile
development is exploded archives. The
EAR, EJB3 JAR and WAR files are not
necessarily JAR files in the JBoss
container. They can be directories
containing the contents of the JAR
file. For instance, instead of
deploying the dvdcatalog.ear file as a
single file, you can deploy it as
directory.
With the exploded directories, you can
make changes to any single JSP page or
Java class file in the application
while the server is running. Then you
can touch the META-INF/application.xml
file in the exploded directory (i.e.,
update the file's timestamp to
current) to re-deploy the entire EAR
application. This further saves
significant amount of time for rapid
turn-around agile developers.
What you're looking for doesn't sound simple. It would require detecting the change, unloading loaded class definitions coming from that JAR (assuming this information is known), reloading classes (something like that but I'm pretty sure I'm oversimplifying). Maybe more a job for an OSGI server.
See also
JBossClassLoadingUseCases
ClassLoadingConfiguration
I'm using JBoss AS 4.2.3.GA and I want to make it to hot reload changed classes.
Now, I have a running JBoss AS with deployed exploded war, after changing (recompiling) some classes, it starts to redeploy all war:
14:14:03,732 INFO [StandardContext] Reloading this Context has started
and redeployment takes a very long time. I want to avoid such time wasting, and maybe there is a way to tell JBoss, just to replace changed class files w/o redeploying all the war?
I've also tried reloadable="true" in
jboss-4.2.3.GA\server\default\deploy\jboss-web.deployer\server.xml
But, perhaps, that's not what i seek. I don't know if it matters, but the exploded war's directory is external to server's /default/deploy/ dir. All my classes are in WEB-INF/classes dir.
You probably need to research framework-specific solutions. Look for OSGi, Spring Dynamic Modules, JEE6 dependency injection.
Also, there may be an Eclipse plugin that will facilitate this for you. I know there is one for Glassfish and JEE6.
What technology are you developing this with?