You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jason van Zyl <ja...@zenplex.com> on 2002/09/20 02:38:10 UTC
Summary of excalibur wrt Avalon 5
Hi,
Could someone post a short summary of what pieces in excalibur are being
considered for use in Avalon 5? I'm plugging away at making a container
and I would like to use as many of the standard building blocks as I can
but I still do not have a very good grasp on what in excalibur is going
to be used for what.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2002-09-20 at 11:20, Leo Simons wrote:
>
> I hope so, though I doubt it ;)
That helps a lot actually. Thanks again for taking the time to do the
summary. It really does help. I appreciate it.
> cheers,
>
> Leo
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Summary of excalibur wrt Avalon 5
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Sat, 21 Sep 2002 01:31, Leo Sutic wrote:
> > > From: Leo Simons [mailto:leosimons@apache.org]
> > >
> > > concurrent
> > > -------------
> > > dunno.
> >
> > Should move to commons.
>
> Or should be replaced by doug leas stuff ;)
util.concurrent? Definitely.
(Shouldn't be in Excalibur anyway.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Peter Donald <pe...@apache.org>.
On Sat, 21 Sep 2002 01:31, Leo Sutic wrote:
> > From: Leo Simons [mailto:leosimons@apache.org]
> >
> > concurrent
> > -------------
> > dunno.
>
> Should move to commons.
Or should be replaced by doug leas stuff ;)
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Summary of excalibur wrt Avalon 5
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> concurrent
> -------------
> dunno.
Should move to commons.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-09-20 at 16:11, Jason van Zyl wrote:
> > >Could someone post a short summary of what pieces in excalibur are being
> > >considered for use in Avalon 5?
> > >
> >
> > I would ignore A5 if I were you. Based on the discussions on A5, there
> > were no convincing arguments for a major version increment over A4. My
> > own conclusion is that 4.X is here to stay for a good time yet.
>
> That's fine then. A summary of all the activity and plans for the tools
> that will be rolled into subsequent versions of avalon.
my take: not gonna happen (anytime so soon as to take it into account).
Not with our meta model wars......
> > >I'm plugging away at making a container
> > >and I would like to use as many of the standard building blocks as I can
> > >but I still do not have a very good grasp on what in excalibur is going
> > >to be used for what.
> >
> > Its simply a collections of tools and utilities that generally leverage
> > Avalon Framework lifecycle patterns. They typically get used within
> > component and container implementations. Excalibur can be viewed as the
> > commons library for Avalon.
>
> Sure, but what I'm interested in are things like containerkit. I would
> like to know if it's worth the time to try and integrate that code into
> my container. Or the various meta models, or the interceptors. I'm just
> looking for a short summary on where the desire lies to maintain all
> these new packages that are cropping up and how they might fit into new
> versions.
No-one is quite sure on all this atm I think. I'm going to burn my hands
trying to do this overview...this is very much IMHO. (everyone else, I'm
okay if y'all want to add to this or go into long discussion, but I
won't be watching ;)
altrmi
-------------
very cool, not used very much. Whether it'll live long depends on
'marketing' I think.
assembly
-------------
Really is "Merlin 2". Steve's doing a lot of work and as long as his
company is going strong I suspect it'll stay for sure =)
Other people are also interested and doing some stuff so Merlin will be
around, though it might change substantially because of fortress
integration.
Wouldn't recommend it for production, definately for ideas and
alpha/beta stuff.
baxter
-------------
Will live. Useful, stable.
bzip2
-------------
Will move. Useful, stable.
cache
-------------
dunno.
cli
-------------
Will move. Useful, stable.
collections
-------------
Will move. Doesn't belong here. Useful, stable.
component
-------------
Will die. Useful, stable.
concurrent
-------------
dunno.
configuration
-------------
dunno. Useful.
container
-------------
dunno.
containerkit
-------------
Will be around. Sound idea, most important parts supported by merlin, PD
pushing it in different areas. There's the meta model war problem
though...
converter
-------------
dunno.
csframework
-------------
Might be the future for all of us in the end =)
datasource
-------------
Will stay. Useful, stable.
event
-------------
dunno. Very cool but definately alpha.
extension
-------------
dunno. Cool. Might move.
fortress
-------------
dunno. Very much useful, might merge with Merlin. I think it deserves an
alpha release and more attention than it has been getting recently =)
Though it has less functionality than merlin, it is good at what it
does. Might be a good choice for you, as it is basically geared at
cocoon-like stuff.
i18n
-------------
Should move, might stay. Useful, stable.
info
-------------
dunno. Likely meta model war casualty. Very nice otherwise.
instrument
-------------
Useful, stable, cool.
instrument-client
-------------
Useful, stable, cool.
instrument-manager
-------------
Useful, stable, cool.
interceptor
-------------
pre-alpha =)
Would stay away for the next year =)
io
-------------
Useful, stable, should move.
jprocess
-------------
dunno.
loader
-------------
dunno.
logger
-------------
dunno. If you use component, use this.
merlin
-------------
Will die. Use the assembly package.
meta
-------------
dunno. Likely meta model war casualty. Very nice otherwise.
monitor
-------------
dunno.
naming
-------------
dunno. Seems useful.
pool
-------------
dunno. There are pooling impls all over the place. Hope this gets
cleaned up ;)
sourceresolve
-------------
dunno.
store
-------------
Stable, useful.
tar
-------------
Will move. Stable, useful.
testcase
-------------
Hope it will be replaced with something more extensive and solid.
Esential though.
thread
-------------
dunno. Yet more pooling. Useful.
threadcontext
-------------
dunno.
tweety
-------------
Will be around. Stable, useful, but don't use =)
util
-------------
dunno. Hope it moves.
xmlbundle
-------------
dunno. Hope it moves.
xmlutil
-------------
dunno. Hope it moves.
zip
-------------
Will move. Stable, useful.
Quite a long list =)
When I mention "useful", it means I've used it and it worked. When I
mention "stable" it means I *think* the API won't change much anytime
soon.
When I mention "dunno" the package is short on docs and/or I haven't
used it.
Generally, for alpha development, I say use everything but the stuff
dealing with meta models. For beta development I dare say these are
okay:
bzip2
cli
i18n
io
naming
zip
fortress
assembly
cache
datasource
altrmi (not because it stable but because it fits a void)
baxter
cli
collections
configuration
io
i18n
instrument-*
testcase
For stable development:
bzip2
cli
i18n
io
zip
component
baxter
cli
instrument-*
testcase
Not to say that packages not listed are not of good quality I just don't
know enough to say so.
I personally find that the excalibur package as a whole is still messy
and there is a lot of documentation missing for many packages. This says
little about the stability or usability of the code, but for larger
projects with multiple people working on them, it is a serious problem
and hence I stay clear of overything larger than a few classes in those.
That's a big part in the above recommendations.
> I'm not looking for a detailed roadmap as I'm fully aware how thing may
> change and I'm fine with making alterations as necessary to keep up with
> changes until a release. I just wanted to get a little better picture
> for myself and hoped that a short one line summary of each package would
> help.
I hope so, though I doubt it ;)
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2002-09-20 at 02:33, Stephen McConnell wrote:
>
>
> Jason van Zyl wrote:
>
> >Hi,
> >
> >Could someone post a short summary of what pieces in excalibur are being
> >considered for use in Avalon 5?
> >
>
> I would ignore A5 if I were you. Based on the discussions on A5, there
> were no convincing arguments for a major version increment over A4. My
> own conclusion is that 4.X is here to stay for a good time yet.
That's fine then. A summary of all the activity and plans for the tools
that will be rolled into subsequent versions of avalon.
> >I'm plugging away at making a container
> >and I would like to use as many of the standard building blocks as I can
> >but I still do not have a very good grasp on what in excalibur is going
> >to be used for what.
> >
> >
>
> Its simply a collections of tools and utilities that generally leverage
> Avalon Framework lifecycle patterns. They typically get used within
> component and container implementations. Excalibur can be viewed as the
> commons library for Avalon.
Sure, but what I'm interested in are things like containerkit. I would
like to know if it's worth the time to try and integrate that code into
my container. Or the various meta models, or the interceptors. I'm just
looking for a short summary on where the desire lies to maintain all
these new packages that are cropping up and how they might fit into new
versions.
I'm not looking for a detailed roadmap as I'm fully aware how thing may
change and I'm fine with making alterations as necessary to keep up with
changes until a release. I just wanted to get a little better picture
for myself and hoped that a short one line summary of each package would
help.
> Hope that helps.
>
> Cheers, Steve.
>
> >
> >
>
> --
>
> Stephen J. McConnell
>
> OSM SARL
> digital products for a global economy
> mailto:mcconnell@osm.net
> http://www.osm.net
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Stephen McConnell <mc...@apache.org>.
Jason van Zyl wrote:
>Hi,
>
>Could someone post a short summary of what pieces in excalibur are being
>considered for use in Avalon 5?
>
I would ignore A5 if I were you. Based on the discussions on A5, there
were no convincing arguments for a major version increment over A4. My
own conclusion is that 4.X is here to stay for a good time yet.
>I'm plugging away at making a container
>and I would like to use as many of the standard building blocks as I can
>but I still do not have a very good grasp on what in excalibur is going
>to be used for what.
>
>
Its simply a collections of tools and utilities that generally leverage
Avalon Framework lifecycle patterns. They typically get used within
component and container implementations. Excalibur can be viewed as the
commons library for Avalon.
Hope that helps.
Cheers, Steve.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Summary of excalibur wrt Avalon 5
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Fri, 20 Sep 2002 10:38, Jason van Zyl wrote:
> Could someone post a short summary of what pieces in excalibur are being
> considered for use in Avalon 5? I'm plugging away at making a container
> and I would like to use as many of the standard building blocks as I can
> but I still do not have a very good grasp on what in excalibur is going
> to be used for what.
Depends on exactly what sort of container you are building. Heres my take;
* Extension:
Basically manages JDK1.3+ "Optional Packages" or JDK1.2 "Extensions". These
same extensions are being readily used in EJB/Servlet engines and would be
great to be used in Avalon containers. While it is still "alpha" - it is
fairly stable. We haven't made it beta because the stuff in
excalibur.packagemanager.* will change it's API eventually (Essentially when
we create a PackageManager that mirrors manages a large file directory we
expect the API may change). BTW it would be great if Maven automagically
generated these descriptors when created jars ...
* Loader:
Use it for complicated ClassLoader management. Is not yet completed but when
it is it will be damn stable. I am unit testing it up the wazoo to make sure
it works all good. Been bitten too many times in the past by ClassLoaders to
not ;) Will be finished in 2 weeks or unless you want to help code it up ;)
* Logger:
Useful - but it offers a more developer centric view of logging systems.
Eventually we will need to develope a more "admin" orientated system but we
aren't there yet.
* i18n:
Stable - Use it.
The above are all fairly fundamental stuff. The rest you can use or not use
depending on what type of container you are writing. My recomendations
* Monitor:
Mostly stable. Maybe use it. Needs a complete refactoring though ...
* MPool:
Use it in preference to old pool stuff.
* ContainerKit:
Don't use it. The only stable concepts in it are the idea of separating info
(type information) / metadata (instance information). The factory ideas are
also fairly stable but interface will change (to add ServiceInfo). All the
rest is junk code thats is being used to test/validate ideas. If you need or
want anything from this project then copy-paste it into your own.
* ThreadContext:
Useful if you need to have separate isoalted application parts and also need
to manage lots of thread-local variables. But one hell of a PITA thing to
manipulate and together with ClassLoader stuff the most painful thing to work
with. But then again if you need isolation then use it.
* Baxter:
Useful stuff if you need to use JMX. We actually need to back port a bunch of
stuff from Phoenix into baxter. There is also Commons Modeller to look at
aswell.
* Info:
Useful stuff but still not stable. If you want to do metadata then use it but
realize it may change slightly in future. The things that will change;
- ServiceInfo needs to be able to contain MethodDescriptor (and thus
ParameterDescriptor)
- ServiceInfo needs to be able to loaded from XML and so forth
- Needs documentation of how we generate the descriptor from javadoc tags.
- Needs unit tests for everything, especially generation of descriptors from
xdoclet process
* Interceptor:
Not committed yet and wont be for a while. It will radiacally change the way
we build containers. To the point where in many cases there will not need to
be any new containers. Essentially we have 2 "flavours" of interceptor.
One Intercepts invocations/method calls and can do similar stuff to EJB
servers do. (ie Security, Transaction stuff) do stuff Avalon does (separate
and fix thread contexts ala ContextClassLoader and friends), general things
(log every method call) and do things that are fairly domain specific (charge
someone 2c each time they invoke method).
The other intercepts access/release calls to component. This Interceptor
chain allows you to run components through their lifecycle and perform all
sorts of sharing policys (pooled, created per request, etc), creation policys
(facade for webservice, rmi service, EJB etc) and add all sorts of magic to
lifecycle (ie bind component to RMI registry or as webservice or JMX, add
instrumentation lifecycle, activate components on demand).
I suspect after that is in place we will see a reduction in number of
containers until the only difference is the arrangment of interceptors.
Anyhow it is not in place now and probably wont be stable and complete for a
while. So theres nothing to use now and depends upon the longevity you want
for your container. If you want longevity then I would recomend that you
build an interceptor based architecture. Of course that could be my desire
for someone else to do the work talking ;)
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>