Last time I used .ear packaging there was no support for sharing information between web applications: you needed to use web services, rest, etc. This evening I just made a search on the internet to check if things are better now. It seems that nothing is changed.
I found that some application servers have implemented proprietary solutions, to share the session between web applications. I suppose that the environments for the web applications are isolated and you probably still need to juggle with the packaging.
Some years ago, I and one of my friends were developing a product that was having common features for different customers. We was trying to find a way to keep a single application under development, having separated modules for the customizations. It was impossible with the current J2EE specification and we had to play a lot with CVS and Ant scripts. Finally we ended splitting the application in different branches.
Today, I am planning a web application and I would like to use maven to package features inside a web applications as plugins.
It would be nice if Java web application specification were supporting a structure of a superwar containing subwars into the WEB-INF/lib in addition of the jar files that we already have. A sort of web application that can be deployed inside other ones. A web application component (wac?). For instance, I could write a web application component to handle the registration, the login, and the user management, and deploy that feature in all the applications needing that.
If JSP were able to be loaded from the ClassPath, like a velocity template, it would have been a great solution as well: you can package all the web resources needed for one feature into a .jar artifact to be included in the web archive as a normal library inside WEB-INF/lib. Imagine if your web application can be split in jar files implementing set of features that you can sell separately: the core war file at runtime could just check for the presence of the available features, detecting implementing class in the ClassPath, and enable new menu items and widgets. Also the customer could cut off features that he doesn't want, simplifying the user interface, and lighten the deployment and the memory footprint.
Template engines, like Velocity or FreeMarker, can fit this: templates are loaded as stream from any source. JSPs can not. Unless you intend to pre-compile them and export in the containing war all the mappings for the generated Servlets. Not really convenient.
This limitation is a real pity: over the years JSP has become much powerful but this limitation drastically cuts the field of applicability for this technology if your goal is the reuse. I read some company blogs that was implementing special mechanisms to support component deployment and JSP loading from the ClassPath:
JSP files can be located anywhere: inside the war, on the file system, inside a local jar file, inside a remote jar file or a combination of all those. This is quite nice in development because JSPs can be located in the source tree (instead of packaged in a WAR) and developers can be much more productive.
This feature needs to be included in the standard JSP specification.
I did some research on the past to see if it was possible, using a ServletFilter, to substitute the ServletContext with an extended one having the ability to load JSP files from the CassPath. At that time, this attempt was not successful; I'll try again, to see if in the meantime Tomcat or Jetty added this possibility out of the box, or if this time my playing with the Servlet Container will be more lucky.
|« May||Jul »|
- Android (3)
- Apple (30)
- Books (7)
- Eclipse (14)
- Errors (5)
- Firefox (7)
- Git (3)
- Hardware (18)
- Horror Code (8)
- Internet (21)
- Java (106)
- Life, universe and everything (45)
- Lifehacks (26)
- Linux (53)
- Opinions (26)
- OSX (11)
- OWNER API (3)
- Python (1)
- Software (35)
- Speeches and Conferences (8)
- Unix (5)
- Web (23)
- Windows (19)
Android apple architecture Bash bsd configuration CSS Development Düsseldorf framework free Git Google Hardware hdr How-To howto Java Karmic library Linux lion MacBook maven opensource Open Source Opinion os x OSX owner owner api patterns Pitfalls Practices properties Software TDD Testing tip tonemapped Tricks Ubuntu unix video Web