Peter Donald wrote:
>
> Hi,
>
> Cocoon2 is just about to go beta which means we have to put out a beta
> version of the framework classes. Why is this important ? There is a number
> of reasons that this is a significant event for Avalon. Unlike other
> projects that use Avalon this project is another "framework" which means
> other people will be using Coccon2 to build further products.
I agree.
> If C2s acceptance is anywhere in the vaccinity that I expect it to be then
> there will be a significant number of C2 adopters who will thus be
> indirectly programming to the avalon interfaces. I find it within bounds of
> reason that we get C2 or James to keep up with Avalon when they are alpha
> or don't have "clients" that directly use Avalon. However I find it
> completely unnacceptable for C2s clients to be stuffed around due to
> changes in Avalon.
C2 presents a number of significant improvements over C1, including the
framework. I don't know about JAMES's userbase, but between JAMES and
Cocoon 2, we have pretty much finalized the framework as far as class
content. The current Configuration classes are MUCH easier to use, and
almost a pleasure.
> Hence I propose that we move the "framework" part of avalon to a stable
> beta release to match c2s going beta. This means that once we commit to a
> particular arrangement we will effectively required to support them for a
> long duration into the future. Given this I think we should do the
> minimalist thing to the greatest possible degree. If a pattern is not
> stable and applicable to a sufficiently wide an audience it should not be
> included in the stable framework.
I agree. Does this include Camelot? I think that has been the most dynamic
part of Avalon to date.
> Included in jakarta-avalon CVS is
> 1. Framework/Pattern code
> 2. Utility code
> 3. Components
>
> The most important of which to stabilize is (1). It is expected that
> overtime (3) will be upgraded and (2) is minimal. So I propose the
> following guidelines;
>
> * If it is a component we don't stabilize it yet
The datasources are pretty much stabilized. I haven't heard too much on this
list or Cocoon lately about them.
> * If it is not sufficiently general or only applicable "in theory" then we
> don't stabilize it yet
Not sure on this point. I get the point you are making, but I want to know
what you mean by "in theory".
> * If it is utility code then we only stabilize it if (1) directly uses it
> or C2 and it's clients will use it.
Lock, Framework Interfaces, Configuration, DataSources, is there anything I
am missing?
What about the decision to backport the ComponentManagement classes used in
Cocoon 2? Is that on hold, or is that going to hurry up now?
> Given this I propose that the following 2 hierarchies
> * org.apache.framework (stable framework code)
> * org.apache.avalon (unstable/untested code or components)
I thought the whole framework was Avalon?
> Initially I wanted to separate out implementation and interfaces but given
> our tight deadline I no longer think that is pertinent for this version.
Are we talking an official version 3.x or version 4.0?
> So what do I think should be in org.apache.framework (looking at
> arrangement in current proposal CVS)
> * Configuration package
> * ComponentManager package
> * Context package
> * Lifecycle package
> * Logger package (Contains *Loggable)
> * part of thread package (namely ThreadSafe/SingleThreaded)
> * CascadingExceptions and ExceptionUtil
* DataSourceComponents
They are _very_ well tested by a number of Cocooners, and the only bug
reported has been addressed.
> Everything else would remain in org.apache.avalon for the moment. In the
> future when Camelot is simplified into smaller packages (ie
> container/registry etc) this would be moved across to framework. Also when
> the ThreadContext/ThreadPool/ThreadManager/etc interfaces are adapted
> further they would be moved across.
>
> The rest is either components (ie datasource.*/pool.*) or as yet untested
> extensively (ie processor). The framework/utility code that remains that C2
> uses should either be treated as semi stable (ie datasource.*/Lock) or
> moved into cocoon2 CVS (ie Modifiable).
I need to backport the Pool framework from Cocoon2 to Avalon. I found the
race conditions, and the DataSourceComponents and ComponentPool (C2) use the
architecture. Santiago Gala (the only one I *know* has a MP box) has tested
those two pools to the best of his ability, and doesn't get a lockup.
> I will update the proposal directory with an outline of what I believe is
> the right way to do this. Then we can get to voting/opinions/niggles etc.
> Once we do this we have to develope a strategy to update the current users
> of avalon to use this new code (and if we start a new CVS for it like
> jakart-avalon-framework).
Looking forward to seeing it. We are talking about the /proposal heirarchy
in this discussion right?
> Anyway thats the basic outline of something we can do. One thing I do have
> a query about is whether we want to keep the interface "Component" around.
> Currently "Component" is what is returned from ComponentSelector and
> ComponentManager which means that any components stored in those objects
> must implement COmponent. This can be a PITA when you want to store JDK
> type objects in the CM - I have run afoul of it a number of times and have
> a number of classes who only exist to implement Component. Hence I would
> like to make CM and ComponentSelector return Object instead and completely
> remove the Component interface.
That would make it more consistent with the JavaBean approach. But then I
have to ask, "Why have a COMPONENT management interface?". The idea was to
keep the Components conceptually separate from regular classes. Components
manipulate Classes, either through containment or through some other means.
> Votes/Comments/proposals/etc?
I am totally for Apache Avalon's Framework to be Beta and not changed. I will
help in any way I can.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
