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:33:32 GMT

I forgot to mention that the Tomcat CVS from Apache
contains the ANT targets for building the TomcatBlock,
however, the source files needed for this do not exist
in the Apache Tomcat CVS src.


> 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 scarry - a build process that runs much
> longer than the Tomcat build which looks really 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 Tomcat build).  Arfter faileing to get eas.betaversion.org
> CVS built in a runnable form we focussed 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, then you discover the build files are out of sync
> with the distributions referenced in the readme.  The impression
> I was left with is that Tomcat probably needs a couple more months
> to get itself sorted out and that that the eas.betaversion.org
> 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 please 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 blocks hould 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
>


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


Mime
View raw message