You still can keep your concept of "Application". I look at Cocoon as a framework, within which my applications run. I make each application a subdirectory off the main directory, and each has its own sitemap. The benefit is that I have a "clean" sitemap, (i.e. very few map:component definitions except those that are specific to the application, like actions) and then I have a certain degree of portability. I have development and deployment copies of my website, which is comprised of 4 such applications. When I want to roll a new version of an application, I jar up the appropriate directory, copy it to the production machine and unjar. All automated, too.
A traditional Servlet Spec-based application is a different paradigm from a Cocoon-based application which, obviously can only run inside Cocoon. In a way, you are comparing apples and oranges. A Cocoon-based application does have certain ties to the framework: the application sitemap must be referenced in the main sitemap and it shares WEB-INF/libs and the settings in web.xml/cocoon.xconf. Unless, of course, you write your own class-loader that picks up jars from your application directory structure. Regards, Lajos galatea.com Cocoon training, consulting & support Robert Bourdeau wrote: >>>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". For me, the 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, > but in Cocoon they do not get their own WEB-INF directory. 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. > > 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. > > 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]> > > -- --------------------------------------------------------------------- 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]>
