Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: <cocoon-dev@xml.apache.org>
Subject: [C2][VOTE - it is a new one] Sync C2.0 and C2.1 branches
Date: Thu, 6 Sep 2001 11:33:03 +0200
Message-ID: <MCEHJNGEDNCOGPCCMCEKKEMNCDAA.leo.sutic@inspireinfrastructure.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3B9648AE.A5EDBB68@apache.org>
Importance: Normal


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

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

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

 - Do we have an agreement on the preferred method.

/LS


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