Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B9773AB.D19A0441@apache.org>
Date: Thu, 06 Sep 2001 09:01:31 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2][VOTE - it is a new one] Sync C2.0 and C2.1 branches
References: <MCEHJNGEDNCOGPCCMCEKKEMNCDAA.leo.sutic@inspireinfrastructure.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Leo Sutic wrote:
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Davanum Srinivas wrote:
> > > > 10) Parent Component Manager Support - Specify a configurable
> > parent Component Manager from Leo
> > >
> > > Carsten : +1
> > > Berin   : +0 I haven't seen it in full action yet.  Leo
> > > does good work and consults smart folks ;) but I would have
> > > it slated for C2.1
> > > Giacomo : +1
> > > John    : +1
> > > Dims    : +1 But we need better documentation for this.
> 
> Berin, Dims,
> 
> I have yet to see it in full action myself. I am considering classloader/RMI
> regarding how one would use it in a clustered environment. At the moment the
> best choice seems to be a parent component manager that:
> 
>  1) Looks up a Configuration instance via JNDI.
>  2) Instantiates an ExcaliburComponentManager with that configuration.
>  3) Delegates all lookup/release messages to that instance.

This is probably the best and most preferred approach.

> Remote objects would be handled by specifying in the configuration an
> implementing class that looks up and delegates everything to the remote
> object. Since we're using the factory pattern here it can be changed, but
> I'd like to have some way of doing it that enables me to write in the docs
> that "this is the preferred way of doing it".

Ok.  Keep in mind that Remote objects that are core to Cocoon are a bad
idea--it will bring Cocoon to a crawl.

> Having the feature in C2.0 is good for me because it meshes quite well with
> my own development roadmap. The alternative would be to fork the involved
> classes until C2.1 becomes ready for use and that's a mess I do not even
> want to think about.
> 
> The downside is that it is a feature without a preferred usage pattern, with
> almost nonexistent documentation and with nothing but a trivial example.
> 
> What I see as needed from me before the release candidate is:
> 
>  - xdocs/parent-component-manager.xml
>  - A sample involving the preferred method outlined above which I think will
> be:
>     - A component that gives you the current time.
>     - A small server that binds a Configuration object to a JNDI name,
> probably via the Excalibur naming package.

There are two implementations: a pure in-memory JNDI solution and an RMI
                               solution.  Choose wisely.

>     - A CM that looks up the Configuration and does you-know-what.
>     - A generator that looks up the time component and emits the current
> time-of-day.
>     - A stylesheet to present the time.
> 
> The "small server" part is the hard one. I am considering putting everything
> into a static initializer for a class and then specifying that class in the
> load-class init parameter in web.xml.
> 
> So what I need to know is:
> 
>  - Package name for sample components. org.apache.cocoon.components.sample?
> (Will move the parent component manager here as well.)

Samples should never be packaged with the main jar.  They should be compiled
into the WEB-INF/classes/ directory.  Use the package name:

org.apache.cocoon.sample

>  - Do we have an agreement on the preferred method.

I like your vision.  Can you pull it off in time?

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