OK, let me give a brief description of the project I work on, and where the current webapp system falls short:
We make a web application that is sold to hundreds of customers to install on their own servers. This is somewhat unusual, but isn't really in conflict with the spec. In fact, WARs can make it easier. Also, we are in fact heterogeneous; part Java and part perl. We're slowly migrating perl stuff to Java, but at the same time, we're starting to add some .Net components in the Windows version, so I think language heterogeneousness will always be a requirement. Even that's not the big problem, though. The big problem is that our product is evolving from an application to more of a tool platform. Our customers need to be able to install packaged extensions, at runtime, without interrupting service in any way. These extensions have both back-end functionality and JSP UIs. Furthermore, each extension has its own security restrictions: they run in a sandbox with only the permissions that the administrator approves when installing it. The way we've come up with to do that is to package the extensions as webapps, and to create a Tomcat-specific class to load and unload them. But we have some shared components: UI taglibs, for example, that we would *like* to centralize in the platform code, rather than duplicating them across each extension (with the associated risk of them falling out of sync). We've been able to do that to an extent, but in (IMO) inelegant, container-specific ways. It works, but it's not perfect. So what I'd like to see (maybe in Servlet 3.0) is some concept of a federation of cooperating but mostly independent webapps. Or perhaps a hierarchical webapp of some sort with pluggable modules and a standard API to load and unload them. I admit that our case is a bit unusual, but I think this sort of thing will become increasingly common. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 > -----Original Message----- > From: Will Hartung [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 1:24 PM > To: Tomcat Users List > Subject: Re: JSP files between many webapps > > > > From: "Tim Moore" <[EMAIL PROTECTED]> > > Sent: Friday, February 14, 2003 9:52 AM > > Subject: RE: JSP files between many webapps > > > > I have to say that, while the webapp concept is nice in > many respects, > > it's really not adequate for large, complex applications > with multiple > > component modules. It certainly makes the simple, most common case > > far more manageable than it was before, but there are some projects > > (probably a growing number) for which the single-unit webapp model > > doesn't quite cut it, and those of us building systems like > that are > > constantly struggling against the limitations of the > servlet spec. :-\ > > Not to doubt what you're saying at all, but this seems to me > that the limitations can be mitigated if they're known about > in advance. > > Now, the Webapp isn't perfect, and leveraging a legacy > application into the iron fist of a Webapp can be difficult > to say the least. Not to mention integration of a > heterogenous application that isn't "pure Java". Lots of fun > to be had there. > > However. > > I look at the Webapp and think of it at a pretty simple > level. The Context. Within the context, you have mappings to > the assorted segments of the Webapp. > > Assuming a "pure Java Webapp" solution. > > If your multiple component application is managed at the > Webapp level, then, yes, you will have problems. But that > begs the question of why you're using the Webapp as your > component layer, when in reality it's the integration layer > of the system. To be fair, I think the component level is the > Servlet layer and its associated mappings within the web.xml, > not the Webapp layer. > > In EJB parlance, you don't integrate EARs (The EJB version of > a WAR), you integrate disparate EJBs INTO EARs. > > If you have two Webapps to integrate, why not break them into > their component bits, integrate the web.xmls, pushing context > level mappings down into the servlet mappings, and then > rebundle into a Webapp? > > For example, if you have context1.war and context2.war, and > each one has ServletMapping, then you can create a new > web.xml that has context1/ServletMapping and > context2/ServletMapping. I know, looks easier than it is. > > Certainly you begin to run into potential namespace issues as > you fuse the two together, but this seems doable and I think > this is how the Webapps were essentially meant to be used, > particularly today. > > What kind of issues are you running into that would frustrate > this kind of process of integration? > > Because once you're into the single WAR, then your cross > authentication issues go away, resource shariing issues > (assuming no naming clashes) are absorbed, etc. > > I'd just like to know what you're encountering, as I think > it's important to highlight issues that can be brought up > with the JSR groups for future versions of the spec. > > Regards, > > Will Hartung > ([EMAIL PROTECTED]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
