Peter Donald wrote:
>
> Well - I guess the prime example could either be processor package or the
> remaining thread package (ie ThreadContext/ThreadPool/ThreadManager). In
> theory the processor package is nice. It is based on looking at existing
> designs (ie jboss/tomcat/james/cocoon mainly) but as yet we have not
> incorporated it widely enough to see if it really is worthwhile.
>
> Also the same with ThreadContext/ThreadPool/ThreadManager - I have been
> using the same interfaces for close to 2 years but it hasn't seen wide
> application yet. I suspect that we will in the future require the addition
> of something like a ThreadControl to send signals/interupts and other odd
> things.
Well, the Thread stuff is dependant on the pools. I need to apply the same
approach to the Avalon pools as I did for Cocoon and DataSources. I'm just
swamped.
Until that time, it won't be stable on SMP systems--and possibly even on
single processor systems.
> >> * 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?
>
> CascadingThrowable/ExceptionUtil is about the only other thing that pops
> into mind.
Cool beans.
> >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?
>
> I am not sure I fully understand it - I would like to backport it but thats
> is up to you ;) If you think it is bonza then we can backport it.
The only thing is getting the Role -> Default Implementation mapping abstracted.
I can't remember where we left off with that. Other than that everything is
copasthetic
> >> 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?
>
> Well I guess it is a naming thing. It is really hard to "sell" avalon
> because it includes everything - including the kitchen sink ;) I want to
> separate out the stable from non-stable and I thought this was the best way
> to do it. I am really open to anything ... the only limitation is time
> because we need to be stable before c2 is.
I think it will be an acceptible comprimise.
> >> 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.
>
> It has been well tested but it is not "framework". It doesn't form part of
> components lifecycle or management etc. In fact it could be reimplemented
> independent of Avalon/Framework in theory.
Point taken.
> For instance a new component just added to commons (namely pool) is IMHO
> better than our version of pool. It wasn't until I saw it that I saw our
> version was lacking (also when I tried to pool datagram-packets that it is
> impossible to implement poolable with). Ideally if that proves to be better
> in long run it would be better to allow us to switch in that implementation.
Any improvements will be appreciated.
> I agree we should stabilize it though (maybe even marking it as stable in
> javadocs) however I don't think it should be in same repository as other
> lifecycle orientated code.
Agreed.
> >> 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?
>
> Yep - I will probably check it in tomorrow .. SAMBA has crashed and I
> currently can't access my code to commit it ;l
Don't you just love it when software works !P
> >> 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.
>
> That was the idea - the question I am really asking I guess is the
> conceptual purity worth the impracticality. Some days I would say yes -
> other days I say no. In general useage I would say no but for building
> other frameworks I would say yes ... so I am not sure ;)
Since you are vasilating so much, I would suggest keeping it the way it is
until you can objectively quantify and qualify why you want to remove the
Component interface. So for version 4.0 we keep the Component interface.
I think that conceptually, having the Component interface helps to force
the thinking in a Component Oriented Programming mindset--as opposed to
simply an Object Oriented Programming mindset.
In theory, a Component does not have to be expressed in an Object Oriented
fashion. An example of this is CORBA C binding. You have specified the
Component by interface, but you implemented it in an Procedural Language.
In practicality, Avalon does not use CORBA, so we can be assured that we
are manipulating Java objects. Clients need to expect an Interface, not
a Class. The implementation of that Interface is returned to them. I must
say, that I debated whether or not to import and use the javax.sql.DataSource
interface for the DataSourceComponent code. The reason I ended up not doing
that is because I was providing an access mechanism to a client that may
not have that interface in the classpath. The reason I chose the longer
class name is to avoid confusion over the javax version vs. the Avalon
version.
It would have been handy to return a javax.sql.DataSource object, but in the
end, the separate Component (that I used as a Proxy or Wrapper for the javax
in the J2EE version) was both conceptually and practically the right way
to go.
>
> >> 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.
>
> excellent!
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
