That may be true...I'd like to move to EJB or equivalent in particular. But many of our problems are purely at the UI level: the servlet spec really doesn't have any provision for making a "container webapp" with a UI framework that is shared between multiple independent "subapps".
-- 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 14, 2003 1:50 PM > To: Tomcat Users List > Subject: Re: JSP files between many webapps > > > It's a matter of planning. The J2EE enterprise solution is not just > about servlets. > That API by itself is not the answer. > > If you folks are struggling with the limitations of the servlet spec, > then is probably > because you are pushing it beyond its design intention. > Perhaps, it's > time to look > at extending your system or rethinking it. Have you thought about > using other > APIs i.e., JNDI, EJBs, JMS etc? These come at a price, but > depending > on > your scale, it may just be the right move. > > Best, > -Francisco Bido > > > On Friday, February 14, 2003, at 12:23 PM, Will Hartung wrote: > > >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
