Leo Sutic wrote:
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >
> > 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
