Glassfish Classloading - java

I have one enterprise application with multiple Web apps. I'm working on upgrading these apps one by one (mainly the UI part), and in the process I have to use different lib versions.
What is the best way to do that?
Does placing the needed libs in WEBINF/lib will solve the issue, or do I have to upgrade all the apps at once.
Appreciate any help.

Placing those libs under WEB-INF/lib should solve the issue as long as they don't appear in other places.
You may want to look at how to deal with shared-libraries for many web applications using the same libraries
When you mean "upgrading these apps" I assume you want to move to latest version of the library unless there is a platform/framework issue.
In general moving to same version of the library (where-ever possible) for the application and then upgrading all libraries one by one will help.

Related

Can I keep same jars with two different versions in java?

In my web application, there is already a lucene-core jar of version 3.6.2, now to add different functionality within the same project I need latest version of lucene-core jar i.e 4.4.0.
When I replace the latest jar with previous one it throws compilation errors as backward compatibility is not maintained by Lucene.
My newly added functionality doen't work on 3.6.2 version. I know it is not possible to keep both jars version in lib. Please suggest a solution.
Oh, yes the Jar hell!
If possible move your Lucene functionalities to a separate layer such as a webservice and access this service from your web application as a webservice client. Of course, this means some sort of overhead (network etc.).
Another possibility would be to use a OSGI solution such as JBoss Fuse that allows to serve web applications. Move your Lucene functionalities to separate modules (each one using a different Lucene version) and import the services to your web application. The advantage is that with this solution you may access the services directly without network overhead.

ClickOnce redeploys unmodified libraries

Suppose I have a Java code which depends on lots of libraries.
I use ClickOnce to deploy the application on the clients machine.
When something changes in the code I don't want the dependant libraries to be redeployed.
Current organization is the following:
when the code is changed, it is being compiled, version number increased and lots of jar files within one folder are copied to the distribution folder with the appropriate version. Later the application manifest chooses the latest version and deploys the application COPIYNG all the libraries.
Main question: Is it possible to separate the libs which never change with the custom code?
I'm quite new to ClickOnce, searched for MSDN and Googled a little, but failed. So links to the ClickOnce dependency management tutorials will be highly appreciated, thanks!
P.S. ClickOnce for Java code sounds ugly but it was strict political desicision, sorry.

Jboss shared libraries in web applications

We have got 3 webapplications running in the jboss 4.2.3.I have found that all these 3 webapps have 95% of common libraries.
I am planning to move common ones to Jboss/server/[profile]/lib so that I don have to bundle up all the necessary ones in the webapps.
I feel it would be good and would also reduce the perm gen space that is being currently used.
I just wanted to ask the community here whether what I am doing is the standard approach or is there anything wrong in doing that?
We use to do that as well by placing common libraries in the lib dir. Turned out to be a nightmare for sysadmiins to update individual apps. We eventually decided to make the war contaiin all required jars to minimize extra steps for the SAs. Made it easier for the QA department as well. It will work just depends on how your QA and SA groups feel about it.
Seems reasonable to me as long as all web applications use the same version of these common libraries and you accept the fact that if you need to upgrade a library for any reason then all web applications are affected.
You should also make sure that the libraries moved to the shared location do not have dependencies in libraries that are part of your web application (avoid classloading issues)

Where do I keep the relevant jars so that I am able to use them when I have deployed the application?

How do I use external library while developing applications on google app engine ? Suppose I have to use javax.mail library. Where do I keep the llibrary so that when I deploy the application on the server,I am able to use the relevant jars ?
WEB-INF/lib
This applies to servlets in general, not just Google App Engine. The one caveat you have to keep in mind is Google App Engine controls which version of JDK they use. This means if the library you're using has any dependencies on 1.7 or relies on code deprecated in 1.5 or 1.6 then it won't work.
There is a list of libraries tested on App Engine, as koma pointed out. It can be found here:
https://developers.google.com/appengine/docs/java/jrewhitelist
Since you're using a library not on that list, you have no guarantee it will work on app engine. You'll just have to give it a shot and see.
If you are using Maven, you could look into creating a super jar (a jar that contains all your binary files and any referenced jars).
Sorry I can't provide specific instructions, I have not done this with Maven directly but only through leiningen.

How to maintain a group of apps with shared libraries that change often?

I have a lot of small-ish Java command-line apps that have to use a vendor set of jars to make their connection to the servers, and while writing these apps has been pretty easy, maintaining them is turning out not to be.
I built them using Maven and some templates that gave me a pretty quick turnaround on development time, but these are all standalone command-line apps so far.
The pain comes from the updates to the vendor servers. Whenever it happens, it forces me to recompile all of these applications with the new jars in play, otherwise I'd get SerialVersionUID Exceptions and borked apps.
What I'm considering
I was thinking that it would be possible to use Maven to generate the app and then throw it in an app server with the server providing a set of shared vendor .jars in whatever /shared classpath it provides. That way I could just update the .jars, restart the server, and everything will likely continue without error.
However, I'm not sure what is required to get that working. They aren't .war's, and most of these apps use other .jars besides my code that isn't usually shared.
Questions
What kinds of deployments work like this?
Are there other ways to do this that I'm missing?
Any tutorials, frameworks, etc., that would make this simpler?
I could just share from my experience. We have 3 ways of overcoming this at the moment. The first way, was our old way, which we still use.
Create a base project which we link to with all our external JARs. The user project when compiled/deployed checks for a newer tag of the base project than it is currently using, and if there's a newer tag, it will fail and force the user to check for the updates and recompile. The benefit of this is that at compile time you can check for new jars, and we get a list of what changed, and reload the jars. In our IDE we can quickly see if anything changed from the API - it has been known to happen, then we can fix and recompile. Also because we're aware of the changes, we can read the changelogs and see if any of the changes affect us, and we then retest parts of the application that depend on these libraries.
We use Maven, but instead of the public repositories, we maintain our own repository, where we only move a library into our local repo after it has been tested - so no surprises for us.
This method is unique to a Tomcat deployment, but we also load libraries via the Context using a classloader. It's not my favorite way to load external jars, but this one works without a deploy. Of course since the compiler isn't there to help you, the new jar can not be 100% compatible with your code, and you can end up with some runtime NoSuchMethodError or ClassNotFoundException expections.
I might be misunderstanding your situation, but if the interface you use in the vendor libraries does not change between versions, couldn't you just keep the jar-files in the classpath of your command-line applications and thereby just overwrite the vendor files when necessary? In that way you would only need to recompile when the interfaces change in a way to break your code?

Categories

Resources