Stefano Mazzocchi wrote: > > 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.
I had a solution to this problem posted a while back. It dealt with fixing a number of issues related to classloaders and installation. Basically, you have the option of the standard war file, an installed cocoon base, or an EAR file with all the Cocoon libs in one place. I am working on a way to make the ExcaliburComponentManager more resource friendly, and really help. There are some issues to work out, but as that is an Avalon Excalibur optimization, I would prefer to discuss those details on the Avalon developer's list. > 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. Yes. This is one of the goals we for C2. For the most part, it is pretty good. > 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. Wasn't this meantioned on the web site? Yes, Cocoon is a publishing/webapp framework, just as Avalon is a Server Side Framework. However, I have some reservations about the solution you are proposing below, and hopefully I can voice them in an intelligent manner. > 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. As an avid Cocoon developer and user (I have sold my IT department on it), I prefer to grow my Cocoon Webapp in a controlled environment, without automatic deployment of new sections. I will expound below. > 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. It may be the closest thing, but it is not the best thing. Currently, in order to mount a sub-sitemap (effectively what you are talking about), you must include an entry in the parent that shows where the child sitemap is. This allows for a controlled URI space--something you have been an avid proponent of. Automatic discovery and deployment of Cocoon webapps requires that we allow our URI space to be at the mercy of your deployment tool. Clearly, you cannot see that as an optimal solution. It is the same flaw in WAR files. Yet another issue arrizing from the URI space issue is where to locate all your images and resources. I prefer to have one URI for each resource, wether it be image or stylesheet. I can't reference an image at "/images/foo.jpg" because my webapp or cocoonapp may not be installed at the root context. There really is no way of automatically rewritting the location to reference the context root. What I end up doing is writting a rule in my sitemap that makes "images/foo.jpg" read the same resource no matter what directory it is called from--effectively poluting my URI space. Another side affect of the sitemap is that you cannot refer to resources in a parent sitemap. The whole concept is centered arround the resources being in the same directory as the sitemap, or below. I find this frustrating, as I am forced to duplicate resources in my directory hierarchy just so the entire site can have the same look and feel. Clearly, Cocoon needs to focus on some key resource resolution issues to make it work properly. Part of the issues come from resolving the names. Perhaps views are our ticket to standard look and feel. However the site maintainer needs the perogative of adjusting the look and feel of the site without affecting the logic of the site. > 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) Cocoon.xconf actually. > 4) have the servlet container restart the entire web-application > handled by Cocoon. This part is a pain. I have a solution to remove the need to restart the webapp when we change Cocoon.xconf. Avalon Excalibur has a new resource monitoring system. With the ActiveMonitor, the servlet can know when to reload Cocoon.xconf and apply the changes. > 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. It sounds promissing, but I am not sold on it yet. Here are the issues I have--and added complexity is the least of them. First, the sitemap is too self contained to allow for meaningful deployment of new functionality while maintaining consistent look and feel. The CWA would be self-contained so that it would use its own resources and not be allowed to be overridden by the parent. Effectively, the new functionality would have the same look and feel regardless of where it is used. That part negates one of Cocoon's strengths. The ability to have a consistent look and feel in a scalable manner. The only way I see around that is if the user is wise, and implements the sitemap so that the CWA only acts on XML. For instance, one of the methods I adopted for the tutorial app in CVS HEAD is to have a standard resource mapping for all HTML so that the look and feel was consistent. The mapping would then call the XML version (that returned XML in the Stylebook format). This allows the parent sitemap to theme any new functionality. Because the sitemap is too flexible, this approach can't be enforced for the CWA--leading to unpredictable results later. > > 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 1) create a new context with Cocoon installed. > 2) use cocoon build file to generate the WAR file (which contains your > stuff as well) 2) use your own build process (usually derived from Cocoon's build file). > 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. Actually, when I am developing a webapp using Cocoon I end up doing it "live" in the servlet engine. When I have it working correctly, I copy it back to the build process. This leaves the CVS logs not as incremental as they should be--but it works. Another alternative is to have CVS check out the webapp directly into the Tomcat's webapps directory and work on it from there. The rest of the stuff is how to assemble the webapp--so there is very little extra work. > One solution is to do the deploying once cocoon2 fresh out of the box, > then install your stuff over on the deployed version. -1 The process of overwriting existing stuff is very complex. > 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. Exactly. > 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. I like this approach. Especially for the XSP pages. I would even go so far as to write a Sitemap mangler that compiled your XSP pages and included the classes in the proper location and rewrote your sitemap.xmap file so that they are treated like hand written generators. > 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. Exactly. Providing a tool that performs this step is a boon. It takes all the guesswork out of compiling everything and makes the entire app self contained. I went through a nightmare install using ColdFusion (I know I keep rehashing this one, but it is burned in my memmory), because there was no way to simply drop an archive and have everything work. > 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). :) I have learned a few things about threading and race conditions. Seriously, I get your point. Everything would be run from the context that is currently installed until the new version is installed and fully set up. Then we switch to serving the new content while we dispose of the old content. > Currently, development of cocoon webapps is rough and not engineered: is > mostly left to the user ability to manage the process. I concur with this statement. Hopefully my tutorial sheds some light on an approach that is workable for more than just my crew and I. > 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. +1 > 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. I made another proposal that would be I think a better approach than the sitemap concept as a whole. Basically, it is breaking the sitemap into pieces that are required for the management of the resources. It keeps the graphic designers in charge of their resources, Developers in charge of their resources, etc. It was a few months ago (I think around March/April). I proposed it to Giacomo as I did not want to distract from the focus on C2 release at the time. I will see if I can dig up the proposal in my archives. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
