cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Cocoon web applications
Date Tue, 02 Oct 2001 12:01:16 GMT
Berin Loritsch wrote:
> 
> 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, I'll resubscribe to that list (haven't done so yet).

> > 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.

I wholeheartly agree with your statement and I don't think I proposed
anything "automatic", but just easier.

> > 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.

Correct.

> This allows for a controlled URI space--something you have been an avid
> proponent of.

Absolutely Correct and I'm still very concerned about this.

> Automatic discovery and deployment of Cocoon webapps requires
> that we allow our URI space to be at the mercy of your deployment tool.

This is where I disagree.

I never used the word "automatic" because what I described (not even
proposed, just thrown out as a RT to bootstrap a discussion) is a system
that allows you to install web applications in a manner which is
(presumably) more friendly than the rough and undesigned way we do today
that follows the implicit assumptions that Servlet API make that one WAR
file = one web application.

> Clearly, you cannot see that as an optimal solution.

Yes, an optimal solution to my eyes is one that allows you to deploy the
cocoon webapp with the *least* possible effort, but without sacrificing
the full control on what you're doing and mining the implicit separation
of concerns that the subsitemap concept allows.

> It is the same flaw in WAR files.  

Again, I disagree: the only flaw I see in WAR files is the implicit
one2one assumption I stated above and the fact that deployment behavior
is mostly left to the "mercy of your servlet container" (to quote you).

I'm not describing a solution that copies over these bad assumptions,
but one solution that takes the good out of the war file concept
(mostly, the ability to install a package, just as you install software
on your machine, instead of having to place a bunch of files here and
there and mofify a ton of configurations just to make it start, not
talking about coherence between the different webapps installed in the
same system)

> 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.

I've always been an avid proponent of the complete remounting facility
of subsitemaps that lead to the assumptions that all URIs are relative
to the current sitemap and absolute locations were not possible.

While the ability to perform internal redirection makes is possible to
do what you describe above, I came to agree that this is *not* a good
thing and does not improve any concern separation nor makes the
architecture more elegant.

As you imply, rather the opposite.

Expecially thinking about batch processing, such remapped resources
would end up being copied all over the place with a clear inelegance,
redundancy and memory consumption.

I'm happy to reconsider the ability to mount absolute URIs in sitemaps.
(of course, absolute is used here in sense of global cocoon context, not
absolute compared to the entire web site 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.

Careful, this is an entirely different story. While I agree that having
the ability to access absolute Cocoon URIs is a good thing, I still
believe that something like cocoon:../images/logo is *bad* because it
removes the ability to remount the subsitemap.

So, if I want to access the logo without having to duplicate the rule
everywhere, I simply have to refer to cocoon:/images/logo, while, rather
normally, cocoon:images/logo would refer to the current location.

So, given

  /cocoon/ mounts a webapp on "webapp"

  1) /cocoon/images/logo
  2) /cocoon/webapp/images/logo

the four possible way to access the resource are

 cocoon:/images/logo   -> 1
 cocoon:../images/logo -> 1
 cocoon:images/logo    -> 2
 cocoon:./images/logo  -> 2

now, suppose we want to remount the webapp someplace else in another
site (for whatever reason).

 /cocoon/ mounts a webapp on "webapps/webapp"

 1) /cocoon/images/logo
 2) /cocoon/webapps/webapp/images/logo

now, the same four URIs access differently

 cocoon:/images/logo   -> 1
 cocoon:../images/logo -> (not found)
 cocoon:images/logo    -> 2
 cocoon:./images/logo  -> 2

So, while the three other URIs (absolute and the two equivalent local)
maintain the same state independent on their relative position, the
"parent referring" one does not.

This is why it should *not* be available, unless we want to sacrifice
control over webapp remounting and give it to the user. Something I'd
rather *not* do, but not because I don't trust users' ability to manager
their URI space, but because they can become so complex that breaking
transparent remounting at the architectural level places more concerns
on the URI space maintainer and for sure he'll have enough to take care
of.

> 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.

Of course.

I just had an idea: could avalon-like component behavioral dependancies
for cocoon webapps make this possible?

I explain further: think of cocoon webapps as avalon components. Your
image gallery webapp and your webmail webapp being instances of
behavioral descriptions for webapps (sort of "interfaces" for web
applications) and both require the instance of another webapp which
includes the stylesheets they need to complete their job.

So, the contract is that, in order to work, these webapps *require* the
existance of the stylesheet webapp and they require to know how to
access it.

One solution is absolute positioning: the stylesheet-containing webapp,
must be mounted in a specific place. But, this is ugly and might create
collisions, expecially if different versions of the webapp must be
installed (one webapp requires one version and another requires
another).

The other solution is to use the same avalon component discovery
mechanisms: if the package instance of the behavioral interface
"Gallery" requires one package instance intalled of the behavioral
interface "Style", it might use something like

 cocoon://Style/stylesheet/images2html.xslt

which allows three different behaviors:

 cocoon:/images/logo -> absolute positioning
 coocon:images/logo -> relative positioning
 coocon://Look&Feel/images/logo -> role-based positioning

that, IMO, satisfy all needs and make the entire thing *extremely*
elegant.

> > 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.

Sorry :)
 
> >  4) have the servlet container restart the entire web-application
> > handled by Cocoon.
> 
> This part is a pain.

No kidding. Developping the gallery, I have to work on 6 new different
components and have to restart everytime (it takes almost 2 minutes on
my laptop) just to see what I did. The try/fail cycle was so big that I
decided to write standalone components with stdin/stdout interfaces just
to try them out. :(

> 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.

Sounds good.

Tomcat 4.0 allows you to reload a webapp just by hitting an URI
 
 http://localhost:8080/manager/reload?path=/cocoon

(you must add yourself as a role "manager" in the user file in order to
authenticate) but it doesn't always work. 

> > 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.

I totally agree.

> 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.

Agreed, do you think that my proposed avalon-like component solution for
webapps might help in this regard? 

In short, you are asking for more solid and wiser contracts between web
applications and I believe that an absolute URI space accessing is
already a solid contract, but the proposed role-based addressing is a
killer since it allows strong contracts and still complete flexibility
and scalability.
 
> >
> > 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.

Good idea.
 
> > 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.

Yep.
 
> > 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.

Yup.
 
> > 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.

Which is great and will make Cocoon must more used, but still, I think
that good documentation should not *patch* an architectural design
limitation, but sheds some light on both the users (to make them work in
the best scenario) and the developers (to make it possible for users to
be guided by the software first *and* the documentation later, not the
other way around).
 
> > 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

This is, IMO, a big thing. Currently Cocoon is damn powerful but not
very useable. My goal for the future is to keep the power (or even
increase it, if new ideas emerge) and increase the usability at the same
level of its power, without sacrificing nothing that we already
achieved.
 
> > 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.

Yes, I've seen that and I concur that the sitemap forces concerns to
overlap.

I'll be very happy to continue this thread and extend it to what we need
to do to make it easier to use cocoon from a user's perspective and to
allow more complete separation of concerns.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message