> From: Robert Bourdeau [mailto:[EMAIL PROTECTED]] > > > > It's not that these solutions won't work, but they feel awkward and > > > seem a little like hacks. I work in a shop where we have multiple > > > virtual hosts running on a single server configuration, and within > > > each virtual host, multiple applications. Further, there are dev, > > > alpha, beta, and prod configurations of everything, so I expect to > > > be able to configure my software to allow for the independent upgrade > > > of a Cocoon application from dev to prod without interferring > > > with any of my other applications (except for changes in the common > > > components, Cocoon, Tomcat, etc.) > > > > Every application has WEB-INF directory, thus, it has all the libraries > > it needs and it does not interfere with other applications. > > > > When you upgrade one of the applications, you just replace application > > directory with the version of the new one, replacing all the libraries > > old application has with new versions. This does not affect any other > > application deployed in the system. > > > > > > So, what's the issue? > > > > Vadim > > > You're calling Cocoon "the application".
I see your point, but you can either go with approach: > For me, the Cocoon-based > application is my "Environmental Treaty Information Service", and > my "Work Flow Management System", and my "Guide to Global Population > Projections", and my "Collaborative Document Authoring Environment". > These applications could all be XML applications supported by Cocoon, by Servlet engine (e.g. Tomcat) > but in Cocoon they do not get their own WEB-INF directory. In Tomcat they do get. > In JSP, they > do. Now, yes, I could create subdirs in cocoon/WEB-INF/classes or create > separate jars for each in the libs, and have my apps each include their own. > I'm still mulling this over, and maybe this is all fine. Still mulling this > over. In gneral, I'm wanting something as transparent as a an Apache module, > or add on Tomcat core classes. Something more transparent than Cocoon > current seems. That's was first way, and I guess you know it but don't like it. Other way is described in Lajos Moczar's letter: have separate classloaders. BTW, looks to me that your issue will be addressed by Cocoon blocks. Search for cocoon blocks discussion on cocoon-dev list. > Don't get me wrong. I think Cocoon is great. It's really fantastic. > It's a steep learning curve, but I think it's worth the climb. :) > This is a hunt for the right way to configure an environment for > multiple developers, multiple projects, multiple computers, > and a staged releases. Good luck, Vadim > Thanks for your comments! > > --- Bob > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
