avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: One user's point of view ( was RE: showcasing Avalon)
Date Fri, 30 Mar 2001 01:20:35 GMT

Peter Donald [mailto:donaldp@apache.org] wrote
> Just in case you were not aware there is a project at eas.betaversion.org
> that has Blocks for OpenEJB server, Tomcat and possibly more in
> the future.
> It may be useful to use their implementations of Blocks (like TomcatBlock)
> etc.

We tried to use this on the first pass - result was a block thorowing null
pointer exceptions.  Underlying this was a build process that was rather
- a build process that runs much longer than the Tomcat build which looks
out of control becuase you end up seeing lots of Tomcat build error over and
over again (something linked to the recusive ant target defined in the
build).  Arfter faileing to get eas.betaversion.org CVS built in a runnable
we fopcussed on Tomocat from Apache which tured out to have its own
skeletons in
the closet - first of all the build process from the CVS assumes you have
half of
Apache already build and installed, together with a bunch of stuff from Sun,
you discover the build files are out of sync with the distributions
referenced in
the readme.  The impression I weas left with is that Tomcat probably needs a
couple more months to get itself sorted out and that that the
team have still work cut out for them before this a TomcatBlock can be
considered as a re-usable entity (but if anyone out there is on top of this
correct me - a.k.a. "I would really like to be corrected").

> At 02:21  30/3/01 +0200, Stephen McConnell wrote:
> >Just for reference, we intent to include the James and Tomcat blocks
> >(enabling the introduction of email and web gateways to the OSM
> platform).
> >Getting symcronization between Avalon/Phoenix/James/Tomcat is to say the
> >least a painful experience. One of the principal "pains" in this process
> >is the lack of support in Avalon for lifecycle components "install",
> >"upgrade", "degrade" and "uninstall".  For example, when a new version
> >of James is released, and the new version contains an updated
> assembly.xml
> >file - its a pain because I have to go though and figure out what needs
> >to be changed in my "James block that I'm declaring to my customers" -
> >actually this is a complaint - centralised handling of configurations
> >in Avalon/Phoenix doesn't work when attempting to build and deploy real
> >applications with cross-vendor-block dependencies.  Its just too painful.
> >I would prefer to see a clear and distinct install phase in
> which different
> >blocks publish default configuration profiles ... during this phase, and
> >block should be able to validate an exiting profile (preferably
> marked with
> >a version identifier) and incorporate existing information into a new
> >configurations. On the Tomcat block front - we have encountered lots of
> >problems - inconstancies between CVS content on the apache site and build
> >files (i.e. build files include targets to create an avalon block but
> >the source code does not exist under the CVS) and a few horror
> stories when
> >attempting to build the Tomcat block (which is not to say that we have
> >given up on the Tomcat block - its just that its we are at the point of
> >deciding if we do this ourselves or wait).
> agreed 100%
> I am actually trying to work on this at the moment but are having some
> problems finding a good design. I was trying to use JNDI and allow
> configurations to be sucked down from LDAP ... but I am having a
> few issues ;)

My view (and this is not a developer view) is that I would like to see a
similar pattern to the Loggable, Configurable, Contextualizable, Startable
... patterns.  What I imagine is a service (not necessary a component) that
supports a lifecycle interfaces like "Installable", "Upgradable",
"Degradable", and Removable.  How these interfaces are implemented is anther
question and that where we get into the question of how assembly
configurations are built and where the default configuration come from.

For reference, what are the issues you referring too ?

Cheers, Steve.

> 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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message