splitting up a huge webapp is hard to do?

Posted on 2005-05-10
Last Modified: 2008-03-17
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 approach without the penalties that seem inherant in doing that.
Question by:HappyEngineer
    LVL 92

    Expert Comment

    > two different webapps are loaded with separate classloaders so that all static objects are loaded twice and all statically executed code is executed twice

    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.


    Author Comment

    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.
    LVL 19

    Expert Comment

    by: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
    LVL 15

    Accepted Solution

    I tend to agree with you that each webapp will share its own classloader.
    When using ear for deployment you can define the static cache in the ejb-layer as its classloader going to be the parent
    of the webapp classloader (see ) as it is
    needed to enable webapp access the home/remote interfaces of the EJB.
    LVL 15

    Expert Comment

    In the link above see (J2EE classloader hierarchy)

    Featured Post

    IT, Stop Being Called Into Every Meeting

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    Join & Write a Comment

    By the end of 1980s, object oriented programming using languages like C++, Simula69 and ObjectPascal gained momentum. It looked like programmers finally found the perfect language. C++ successfully combined the object oriented principles of Simula w…
    Java functions are among the best things for programmers to work with as Java sites can be very easy to read and prepare. Java especially simplifies many processes in the coding industry as it helps integrate many forms of technology and different d…
    Video by: Michael
    Viewers learn about how to reduce the potential repetitiveness of coding in main by developing methods to perform specific tasks for their program. Additionally, objects are introduced for the purpose of learning how to call methods in Java. Define …
    This video teaches viewers about errors in exception handling.

    732 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    17 Experts available now in Live!

    Get 1:1 Help Now