HappyEngineer
asked on
splitting up a huge webapp is hard to do?
I suspect the answer is no, j2ee has no support for anything like this, but I'll ask anyway.
I have a webapp that is getting unweildy because pretty much everything keeps getting added to it.
I have a new project that needs to run on the same machine as that webapp and share all the object caches as that webapp and forward to a few of the jsps in that webapp. But, I'd like to keep it separate so that it doesn't take so long to do a clean compile and so that I can deploy it separately without having to worry about changes to the rest of the webapp.
I'm pretty sure it's not possible. Yes, I could create a 2nd webapp and deploy that separately and then use getContext to get the context of the first app if I wanted to forward to jsps or call servlets. But I don't think there's any way to use the same caches (like static object caches).
In fact, what I'd like is webapp server support for the equivalent of copying the entire second webapp into the first webapp and the just deploying the combined app.
The major issues here are:
- You can't just unzip a war inside of another war and expect it to work. Doing that with a jar works, but a war has a web.xml which cannot be split up.
Or, to put it another way, the web.xml cannot be split up within the same webapp so that parts of the webapp could be replaced without messing with the rest of it.
- two different webapps are loaded with separate classloaders so that all static objects are loaded twice and all statically executed code is executed twice which means that all singletons will exist twice and all singleton background threads will be executing twice.
If I only cared about this on the server than I could accomplish this by having the build.xml combine the two webapps with a separate special web.xml and then deploy that war. But, this would obviously not be helpful when developing with Eclipse or any other ide. If I did that then the webapp wouldn't work until it was combined. In that case there's no point in ever keeping it separate.
I thought that EAR files might help out, but it looks to me like they're just for deployment.
Struts sort of has a thing in it that allows for multiple sub-applications to exist. I haven't looked into that very deeply. Is there something there that might be worth looking into? I've only ever used struts in a single webapp.
I'm hoping that there's technology out there that I'm not aware of that will allow me to get away from the stuff-it-all-in-one-webapp
I have a webapp that is getting unweildy because pretty much everything keeps getting added to it.
I have a new project that needs to run on the same machine as that webapp and share all the object caches as that webapp and forward to a few of the jsps in that webapp. But, I'd like to keep it separate so that it doesn't take so long to do a clean compile and so that I can deploy it separately without having to worry about changes to the rest of the webapp.
I'm pretty sure it's not possible. Yes, I could create a 2nd webapp and deploy that separately and then use getContext to get the context of the first app if I wanted to forward to jsps or call servlets. But I don't think there's any way to use the same caches (like static object caches).
In fact, what I'd like is webapp server support for the equivalent of copying the entire second webapp into the first webapp and the just deploying the combined app.
The major issues here are:
- You can't just unzip a war inside of another war and expect it to work. Doing that with a jar works, but a war has a web.xml which cannot be split up.
Or, to put it another way, the web.xml cannot be split up within the same webapp so that parts of the webapp could be replaced without messing with the rest of it.
- two different webapps are loaded with separate classloaders so that all static objects are loaded twice and all statically executed code is executed twice which means that all singletons will exist twice and all singleton background threads will be executing twice.
If I only cared about this on the server than I could accomplish this by having the build.xml combine the two webapps with a separate special web.xml and then deploy that war. But, this would obviously not be helpful when developing with Eclipse or any other ide. If I did that then the webapp wouldn't work until it was combined. In that case there's no point in ever keeping it separate.
I thought that EAR files might help out, but it looks to me like they're just for deployment.
Struts sort of has a thing in it that allows for multiple sub-applications to exist. I haven't looked into that very deeply. Is there something there that might be worth looking into? I've only ever used struts in a single webapp.
I'm hoping that there's technology out there that I'm not aware of that will allow me to get away from the stuff-it-all-in-one-webapp
ASKER
Huh? That can't be right. If I reference a static variable and changed it then there's no telling which code would get the modified value and which would get the unmodified value. If I have a static cache of objects that's 50M in size then it'd be doubled. I'm sure I'd have noticed if that had ever happened.
Hi,
Two things here. First, some application servers, WebSphere for example, allow you to specify the classloading behavior of web applications. By default each web application is loaded by a different classloader. That's because you usually want that separation. But WAS allows you to specify a single WAR classloader for all web applications.
The second thought is to package your web applications as part of an enterprise application. The enterprise application classloader sits above (is the parent of) the web application classloader(s). As the default classloader delegation strategy is parent-first, the WAR classloaders consult the EAR classloader first. If you have shared classes with static data that you want all web applications to share, have it loaded by the EAR classloader.
Best regards,
Jim Cakalic
Two things here. First, some application servers, WebSphere for example, allow you to specify the classloading behavior of web applications. By default each web application is loaded by a different classloader. That's because you usually want that separation. But WAS allows you to specify a single WAR classloader for all web applications.
The second thought is to package your web applications as part of an enterprise application. The enterprise application classloader sits above (is the parent of) the web application classloader(s). As the default classloader delegation strategy is parent-first, the WAR classloaders consult the EAR classloader first. If you have shared classes with static data that you want all web applications to share, have it loaded by the EAR classloader.
Best regards,
Jim Cakalic
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In the link above see (J2EE classloader hierarchy)
That could also possibly happen within a single webapp, I would try and avoid relying on a single class loader being used for a webapp.