I am currently compiling a list of third-party libraries used in a web application. The application is deployed in tomcat. I am wondering which of the third-party jars actually must or should be included in the distribution. In particular, I am currently wondering how to best use javax-libraries.
For instance, I would assume the javax.annotation-3.1.1.jar can be used in some standardized way, e.g., downloading it as an extension, without me including it into the distribution of my own piece of software. However, I have it included as a transitive dependency from jaxws-api which I need for web services and therefore it is included in the application's lib directory.
I understand I could use the Extension-List manifest entry to cause the target machine to download and install such jars. However, then they are visible for other applications on the same machine as well which may require other versions of the same libraries.
So, I have some questions about 3rd party libs and I would be very glad if someone could give me some hints:
What is the best practice to use third-party libraries?
Is there some best practice for the javax-libraries?
Can and should I avoid redistribution without imposing a large burden on the person installing the application?
I have to admit, I haven't understood the notion of "redistribution" here, maybe you're using some concrete application server terminology, so I'll try to provide a common answer here, assuming you have a war.
WAR (stands for Web Archive) should include all third-parties used by the application.
These reside in WEB-INF/lib folder.
Now, each Java EE server should "understand" javax libraries, because it contains the relevant interfaces. "javax" libraries usually provide interfaces and the implementation/code that works with these interfaces are provided by the application server developers.
For example for servlets technology, Tomcat (or name any web server) will contain HttpServlet abstract class inside its internal libs, it will scan your war and find where do you implement/extend it, this is how it recognizes your servlets actually.
Now, you shouldn't include servlet-api jar into your war, because its already exists in the application server.
If you're using build tools like maven, they allow to build your war so that some thirdparties will be used for compilation but won't be packed up into war.
I didn't understand why is it so difficult to install the application - in the easiest case - you throw the war into the web server and that's it.
Hope this helps
Related
I am developing a WebSphere portlet in IDEA 11. The portlet is using some methods defined on portal. I don't have the production environment compiled classes or jars on my PC but I have the source code.
Can I somehow "attach" the .java files to my projects in order to build a war file that will be deployed into the production environment? Or do I have to build the production sources first (this seems to be harder since there are lots of dependencies)?
If this is just to test something while you await the JARs/compiled classes, you can likely do this by only bringing over the API (e.g., referenced interfaces that hopefully don't have external dependencies). Then, open up the compiled WAR and remove those .class files manually to avoid collisions with the real code on the server.
The biggest problem is that you will definitely run into issues trying to limit the exposure to the real code, unless the rest of the code was setup nicely to expose an API that has very limited dependencies.
I wonder whether it's possible somehow to inform Servlet Container to download required JAR archives from Maven Central during deployment, instead of packaging them into WAR (in WEB-INF/lib). As far as I understand Java is designed with such an approach in mind. Is it technically possible?
I'm not aware of any servlet container that does this. The servlet spec says that a WAR file will contain all the dependencies for the app. Of course, anything is "technically possible", and it's an interesting idea, but I think you'd be doing a lot of custom coding. The only thing I think of that's even remotely close is Virgo Web Server. It's an OSGi/Spring DM container, and it has a concept of a "repository" where artifacts can be found and loaded on demand. It can be configured to use a local Maven repo. It should be a relatively short step to make it use a remote repo, if that isn't already an option. Virgo allows WARs to be deployed to it as well as OSGi bundles, but it isn't a typical servlet container.
The servlet spec comes before maven. That's why the war files should contain the jars.
If you are asking why they don't change that: two reasons:
it will break existing habits and existing servlet containers
maven is not a standard - a standard can't rely on non-standard (even though it is a de-facto standard)
If you are asking if it is possible and a good idea. It is possible, but it may not be a good idea. You should deploy something that is already tested (on a staged and/or QA environment). You can't confirm that the dependency in the repo won't be replaced, as you can't be sure that the connectivity to the repository will be OK during deployment, which will break your deployment.
Is it possible to use the Guava libraries on a project done with both GWT and Google AppEngine?
I see that the individual jars (the standard Java one and the GWT compatible one) have the same package naming hierarchy. How do these integrate in a GWT+AppEngine projecT?
Yes it is possible. A few Guava classes won't be usable on AppEngine because of the restricted sandbox your app will run in, especially those in the .io package like Files (you will be able to read stuff but not write it).
Are you worried about deploying both jar files and having a conflict? If so, I think it will be fine - when you compile your GWT application, it turns into javascript, so you wouldn't necessarily be deploying the GWT compatible jar, just the normal one.
There won't be any conflict as the gwt one will be used by true DevMode client-side and the GWT compiler, the "normal " one will live in your WEB-INF/lib and be loaded (in DevMode) in a different classloader. It thus depends entirely on your project and build setup.
That being said I never tried it within the same Eclipse project. I always use distinct client and server projects, and -noserver in DevMode.
Can we never refer any external 3rd party jar in independent ejb module (except copying the jar file in our appserver/lib)? This seems so illogical doesn't it? I don't want to create a Enterprise application. Why am i being forced to create an Enterprise application if i have to use any jar files?
Are there no alternatives available?
Well, I think I gave you a pretty good explanation in my previous answer:
EJBs don't have an equivalent of WEB-INF/lib and while packaging libraries inside an EJB-JAR might work with some application server, this is not part of the JAR specification1 and does not comply with Sun's standards regarding J2EE packaging.
I don't know what to add, if you want to write portable applications, you have to follow the rules. Whether they are due to technical limitations (see footnote), that's not the question, rules are rules.
The alternative would be to unpack the library in your EJB-JAR and that's incredibly ugly (copying your library in the application server classpath is IMO not an alternative for portable applications).
That being said, if you are using Java EE 6, you can now use a WAR instead of an EAR.
1 As explained in this thread, the jar spec does not support jar files within jar files (technically Java's URL support only goes one level deep: eg jar:url/to/file!path/ in/jar is allowed, but jar:jar:url/to/file!path/in/jar!path/in/jar is not) so while you could copy the jar files inside your ejb jar, nothing will be loaded from it.
You've already selected an answer, but I'll mention that "installed optional packages" might offer a solution, depending on the features available in your server.
At our shop, we are maintaining roughly 20 Java EE web applications. Most of these applications are fairly CRUD-like in their architecture, with a few of them being pretty processor intensive calculation applications.
For the deployment of these applications we have been using Hudson set up to monitor our CVS repository. When we have a check-in, the projects are set to be compiled and deployed to our Tomcat 6.0 server (Solaris 10, sparc Dual-core 1.6 GHz processor, 2 GB RAM...not the beefiest machine by any stretch of the imagination...) and, if any unit-tests exist for the project, those are executed and the project is only deployed if the unit-tests pass. This works great.
Now, over time, I've noticed myself that a lot of the projects I create utilize the same .jar files over and over again (Hibernate, POI (Excel output), SQL Server JDBC driver, JSF, ICEFaces, business logic .jar files, etc.). Our practice has been to just keep a folder on our network drive stocked with all the default .jar files we have been using, and when a new project is started we copy this set of .jar files into the new project and go from there...and I feel so dirty every time this happens it has started to keep me up at night. I have been told by my co-workers that it is "extremely difficult" to set up a .jar repository on the tomcat server, which I don't buy for a second...I attribute it to pure laziness and, probably, no desire to learn the best practice. I could be wrong, however, I am just stating my feelings on the matter. This seems to bloat the size of our .war files that get deployed to the server as well.
From my understanding, Tomcat itself has a set of .jar files that are accessible to all applications deployed to it, so I would think we would be able to consolidate all of these duplicate .jar files in all our projects and move them onto the tomcat server. This would involve only updating one .jar file on the server if, for example, we need to update the ICEFaces .jar files to a new version.
Another part of me says that by including only one copy of the .jar files on the server, I might need to keep a copy of the server's lib directory in my development environment as well (i.e. include those .jar files in eclipse dependency).
My gut instinct tells me that I want to move those duplicated .jar files onto the server...will this work?
I think Maven and Ivy were born to help manage JAR dependencies. Maybe you'll find that those are helpful.
As far as the debate about duplicating the JARs in every project versus putting them in the server/lib, I think it hinges on one point: How likely is it that you'll want to upgrade every single application deployed on Tomcat at the same time? Can you ever envision a time where you might have N apps running on that server, and the (N+1)th app could want or require a newer version of a particular JAR?
If you don't mind keeping all the apps in synch, by all means have them use a common library base.
Personally, I think that disk space is cheap. My preference is to duplicate JARs for each app and put them in the WAR file. I like the partitioning. I'd like to see more of it when OSGi becomes more mainstream.
It works most of the time, but you can get into annoying situations where the jar that you have moved into tomcat is trying to make an instance of a class in one of your web application jars, leading to ClassNotFoundException s being thrown. I used to do this, but stopped because of these problems.
I really don't think putting libraries in common/lib is a good idea. The idea behind the use of war files as applications into a servlet container, is to have a real idea of isolation between your webapps. You could face errors like deploy some third party WAR (with it own libraries inside WEB-INF/lib) and it behave unexpectedly because it loaded other version of one of it libraries from the common one (remember that the regular behavior for load classes is first look at the common classloader and if you don't find the class look into the one for your webapp). Don't even mention how painful could be to move some application to other servlet container or an Application Server.
As mentioned before, you could use maven to deal with jar dependencies, and if you like the homogeneous use of libraries, define a POM parent (maven jargon) across all your applications.
In my experience you should be very careful with sharing libraries between web applications by moving them into the web container itself.
Let them live in WEB-INF/lib so your wars are self contained (you WILL be glad you did one day).
What you might consider is employing maven or Ant Ivy to pull in library jars from a common repository instead. This is very useful and should not be a problem in your scenario.
Edit: A notable exception is the Metro library - web service layer from Glassfish - which needs to be in the web container and not in the web application.