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.
Related
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.
If i want to deploy one application on different servers like Open Source Glassfish or TomEE. How can I achieve that without having to include different libraries for each application server? As an example if would like to use Jersey as the rest framework and eclipselink as the persistence framework i have to make sure both support these frameworks. But in case of TomEE it's shipped with other implementations like OpenJPA.
Is it possible to ship the dependencies only with the project and not in combination of server libraries + project libraries?
What is a good way to achieve server compatibility?
Any information or link which describes a solution or help me understand why it's done this way would be great.
Thanks in advance
This is more of a application server classloading issue and usually all application servers have a provision for a configuration file which you can put in your application and instruct the server to load the libraries included in the web application instead of the one present in application server. For e.g., Weblogic has a weblogic.xml file which is put in WEB-INF of war application and where you can instruct server to prefer the application packaged libraries. For JBoss there is similar configuration file jboss-deployment-structure.xml. This way it is easier to have a self contained application which contains all dependencies even if the server has equivalent libraries. Also you can upgrade to higher version of libraries than supported by application server otherwise you have to resort to all sort of hacks.
Easy solution I can think of is using ant task to create war file for each servers. You can have at most 2-3 servers in reality like tomcat ee, jboss and glasfish. So create 3 ant tasks for each like tomcatWar, jbossWar and glassfishWar and each ant task makes sure required jars are shipped as well in the war. This is more easy and extendable solution, also easy to understand and modify for new requirements.
I am having an issue while trying to deploy two different versions of a same shared Library on the same weblogic server.
Here is my goal:
I have multiple applications which reference a shared Library;
those applications should be able to use different implementation version of this shared Library (in a very good world);
So I would like to deploy multiple version of this shared Library (e.g.: AppB use the version 1.0.0 and AppA use the 1.0.1).
I think (know?) that is possible (I've seen on a weblogic exam that multiple version of a same shared lib can be deploy and active in the same time) but untill now I failed...
Weblogic is unhappy with the fact that two sharedlibrary have the same name... But this 'same name' is required by my applications to use those shared libraries...
My META-INF files are :
Extension-Name: app-local-services-ejb
Implementation-Version: 2.0.2-SNAPSHOT
Specification-Version: 2.0
and
Extension-Name: app-local-services-ejb
Implementation-Version: 2.0.1-SNAPSHOT
Specification-Version: 2.0
My weblogic-application files for the applications I only use the Extension Name of the web-inf and the specification version...
I've tried to do the same with two different version of JSF but I've got the same issue.
The Oracle's documentation on shared Library is not really clear and I didn't find something useful on goole/bing.
I don't know if I have to upload those shared libraries in a specific folder (e.g.: weblogic/commom/deployable-libraries) or if I have to specify something in WEB-INF/weblogic-application.xml files ?
Does anyone have an idea to solve this problem?
Can you separate the applications into two .ear/.war files, each with their own version of the library they need to use? This seems to be by far the easiest way around this problem.
You can only have one version of a library with the same spec version in a WLS at the same time.
To put a new implementation-version up, you'd have to update the existing deployment with the new jar, rather than deploying a new version. This will remove the lower-numbered implementation-version, if WLS can work it out.
This is why it's a very good idea to have spec-versions and implementation-versions be floats, since WLS has a much easier time working out which version is higher than the other if it can be cast to a float.
If, however, you have a library with a different spec number, you can happily upload it simultaneously with other spec numbers. Again, if WLS can work out the version numbers, it can transition apps to the new version automatically, provided they don't have exact-version set in their weblogic-application.xml.
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.
Our current process for upgrading the application is to undeploy the current version, and then deploy the newly created EAR process.
I have seen softwares which have an "auto update" functionality (such as Spring Tools Suite). The software downloads the updated files automatically and performs a self upgrade. There is no need to download the complete setup again and uninstall/install the application.
I just wanted to check if anything similar exists for Java EE web applications as well?
Many servers today support hot-deployment, where you deploy the app over the running one.
This of course still needs the functionality to pull the app from somewhere.
In JBoss 4 at least (and I think it is also available in 5), you can tell the deployment scanner to watch multiple directories, so it could monitor e.g. a shared drive and when you put the application there it would see it and pick it up.
The proper way to redeploy code at runtime is to use OSGi. This is a system created to allow automatic dependency resolution. It allows e.g. for you to keep running older code for existing connections, while using the new code for new connections.
It also allows you to link to newer versions of libraries, which are loaded automatically.
See https://docs.jboss.org/author/display/AS7/Helloworld+OSGi+quickstart for a nice quickstart for using OSGi with JBoss 7.