Hi, I am not really an expert on Cocoon's internal architecture but have been using it for something other than web publishing. Hope, this brings a different perspective to the discussion ( I have keenly read the exchange between Stefano and Berin ).
I do have some thoughts on the **need** to have easily deployable "Cocoon Web Application". The way I have been looking at Cocoon is that it gives me a framework to assemble my processing pipelines. I develop my application as a set of processing pipelines ( and the underlying components, XSPs and whatever else you need ), and test it by modifying the sitemap.xmap, cocoon.xconf, copying .jar and other files at appropriate locations. How do I release my application? I could build a huge .war with everything in it ( including the Cocoon stuff ). As Stefano pointed out and I believe most of us would agree, it is not the most desirable situation. Currently I do it this way, but it is not elegant. What I would really love to have is mechanism by which I could supply just my stuff ( as an archive file with certain directory structure ) and make an existing Cocoon deployment to run it. I believe this is what Stefano proposed. For some time, I wondered whether Cocoon needs to do this ( classloader and security context mgmt. ) or are J2EE Containers ( Servlet Container, EJB Container etc. ) better suited for this job. Two things make me think that a separate context mgmt. by Cocoon is desirable: (i) Servelt containers do not allow a "hierarchy" of deployable units ( so Cocoon can't have its deployable units as servlets and still allow them to use its classes and resources ); (ii) Cocoon may be deployed as containers other than Servlet. Let me elaborate on this: as usage of XML becomes more and more widespread, people would need Cocoon like framework for areas other than Web publishing. Examples include: building "Business Service Interface" compliant to higher level protocols such as ebXML, RNIF or BizTalk; building web services that need signficant XML handling ( say a program that validates and manipulates RosettaNet PIP ). Now, one could argue that Cocoon is Web Publishing Framework and it doesn't need to worry about other usage. Well, isn't the beauty of a technology is its usage and extension in ways not thought out by its originators? Regards, Pankaj Kumar. > -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > Sent: Sunday, September 30, 2001 8:27 AM > To: Cocoon > Subject: [RT] Cocoon web applications > > > This is something I always wanted to bring up but never > considered it to > be a priority high enough, but as soon as Cocoon2 reaches a > status where > it's useable in production sites, people will start asking > for something > more user friendly than a WAR file that can get as big as hell. > > Let me start saying that I have a love/hate approach with WAR > files and > has nothing to do with the acronym which I *very strongly* dislike for > the unfortunate resonance with a terrible thing. > > ok, pacifist disclaimer given, I'll being saying that I love > the way we > install cocoon in a big file we deploy on all servlet containers. Many > have already personally expressed their happyness to me > compared to the > hassle that they required for installation for Cocoon1. This is mainly > given to the webapp deployment concept that latest servlet > API include. > > So, if you consider Cocoon and its samples a single web application, > this way is perfect and you will never going to need anything > else, but > as soon as you start adding your own stuff, you'll find out > that Cocoon > is not a single web application but a framework for applications. > > In short, as Tomcat is a container for servlet-based web applications, > Cocoon is a container for cocoon-based web applications. The > parallel is > evident to me and should *not* require (as Jeremy was asking, clearly > touched by the same feeling) separate cocoon instances just > to *deploy* > different cocoon-based web applications. > > There is also another reason: while there exist components that are > general enough to be distributed with Cocoon, in some other > circumstances, such components, might well turn out to be to specific > for a particular need (specific actions tight to your own business > logic, or specific transformers that are triggered by some precise > semantic, etc..) > > In this respect, there is a big parallel between servlet-based web > applications and cocoon-based web applications: both require a > "deployment descriptor" that gives the container instructions on where > to "mount" it, where to find web-app specific components, > libraries and > resources. > > Clearly, the sitemap is the closes thing that matches this. > > Let's make a solid example: I started integrating my image > gallery thing > which now requires 12 (or so) new classes added to the Cocoon > distribution (some 6 new components), but they are general > enough to be > useable on many other circumstances, but one component which is simply > too specific to be of any use in other circumstances. > > Currently, the operations that we have to do to *install* a new > cocoon-based web application are: > > 1) prepare a directory with all the required files > 2) mount the new web-app sitemap in the sitemap that controls the > URI-space we want to mount our stuff on > 3) place our web-app specific components in the folder for new > components (defined in cocoon.conf, if my memory doesn't fail) > 4) have the servlet container restart the entire web-application > handled by Cocoon. > > While, following the servlet parallel, we should do: > > 1) have a CWA (Cocoon Web Application) file with a manifest file (or > equivalent thing) that specifies where is the sitemap file (I'm also > happy with forcing the sitemap file to be called sitemap.xmap > and places > in the root of the package, thus eliminating the need for such a > manifest file) and contains all the required things (resources, > stylesheets, additional components and libraries, entity catalogs, > etc..). > > 2) open the cocoon manager (similar to Tomcat 4.0 manager > webapp, just > *much* more user friendly) and authenticate (if more security is > required this could be mapped over an SLL-secured connection and > authentication guaranteed by client-side certification, but > this is none > of our concern since Cocoon doesn't handle nor should that part of the > HTTP connection). > > 3) upload the CWA file (unlike Tomcat 4.0 manager which > simply requires > you to indicate where the CWA file is on the machine, with > upload we can > deploy a CWA from another machine entirely which is a great feature). > > 4) tell Cocoon to start the deployed CWA > > and that's it, without even having to stop Cocoon or even tell the > servlet container about what we are doing. > > Of course, Cocoon's classloader should be rearchitected to > allow several > "contexts" which different classloaders, this will automatically solve > the issues of having to run multiple cocoon instances to separate the > resolution space of different cocoon-based webapps. > > But there are other things that might turn out incredibly > useful: almost > everybody works with two copies, one for development and one for > production. The first is used when developing, the second is deployed > and used until changes are required. > > Everybody that has real-life working knowledge knows that is almost > impossible to force people to work on a centralized version, > expecially > if the easiest way to modify something is to work on what is currently > live. > > Currently, the processing cycles are something like: > > 1) write your webapp under the /cocoon2/ folder > > 2) use cocoon build file to generate the WAR file (which > contains your > stuff as well) > > 3) deploy that on the servlet container. > > but then you note that your stylesheets have something wrong, so you > don't do this over and over (since the cocoon-war file is so big and > restarting the entire crap takes forever and a half) but simply modify > the stylesheets in-place while they are live. > > You can bet your ass that you'll forget to copy back the > changes to your > original location. > > Result: next revision gets deployed, many things that > previously worked > well (expecially in sections you didn't touch because they were just > perfect as they were) don't work anymore. This is called: lost update. > > One solution is to do the deploying once cocoon2 fresh out of the box, > then install your stuff over on the deployed version. > > NOTE: the servlet API doesn't say *anything* about what happens to > deployed files that are subsequently modified after being > unpacked from > the WAR. In some circumstances, the container might even erase the > unpacked version when the web-app is stopped or the container is shut > down in order to save space. The Servlet API assume the WAR > file and the > unpacked version are the *same* and unpacking occurs only for speed > reasons, not to allow you to modify things live. > > So, you installed Cocoon2 fresh, it gets unpacked, you stop tomcat > without shutting down but simply kill -9 it or CTRL-C on the > shell, you > add your stuff and work well. > > C'mon, this is crap, we must come up with something smarter. > > Ok, the idea is: how do I make the files deployed unmodifiable? > > My solution is: compile everything. Tranquillity by obscurity. > > If you transform all XML files into CompiledXML files (using > the code I > wrote for a long time ago and which is now used in the cache system), > not only parsing performance is greatly improved on live > sites, but also > we obtain that people will very unlikely modify directly the unpacked > files because they are, in fact, binary. > > This also means precompiling sitemaps and XSPs and everything > that needs > compilation. > > Of course, this is not suitable for close-cycle development of cocoon > web apps: I could not want to have to recompile my entire CWA, deploy, > restart, etc, everytime I have to modify my stylesheet, it would be > foolish to impose this, but on production this makes a real > difference, > expecially in those places where carefully scrutinized > quality assurance > phases must be performed before something enters production. > > In these situations, we must take all the actions to allow packages as > sealed as possible (possibly even crypto-sealed) to be deployed even > remotely on a live site, making also possible to upgrade an existing > package with a new one while the other is running (which is not that > hard to do with carefully designed multi-threading management of > subcontexts). > > Currently, development of cocoon webapps is rough and not > engineered: is > mostly left to the user ability to manage the process. > > In the future, I'd love to make it possible to design the > system in such > a way that concerns are well kept separate even during the two stages, > development and production, for example, performing sitemap > interpretation during developement (since no high load is > required, but > faster responsiveness at structure changes) while performing sitemap > compilation on deployment. Same thing for compiled XML. > > Ok, hope this is enough to start a discussion. If you have any > suggestion to shape the way you will develop, deploy, manage > your future > webapps in cocoon, make yourself heard now at design stage so that we > can get down in coding with a clear indication on what the people want > or would like to see. > > Ciao. > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
