You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/03/29 09:23:02 UTC
showcasing Avalon
It occured to me that I was unable to find a
live server running on Avalon referenced
anywhere. Assuming there are, where can I
find those.
Also, has there been discussion of setting up
some kind of Jakarta project showcase server,
where there are live demos of avalon/tomcat/etc?
I browsed enhydra's airsent.com demo, and thought
"hey, that could be done in a week or two using
Jakarta projects. Should be a nice demo for suits."
Comments, from suits and non-suits?
g'night!
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: showcasing Avalon
Posted by Harmeet Bedi <hb...@yahoo.com>.
I think it is a very good to eat your own dog food and showcase it.
I think there should be place for demos, but also if one can run parts of
Jakarta site on Jakarta projects, then it should be attempted
2 good objectives would be to migrate
- Mailing lists to James, listserv facilities.
- Mail Archives UI using Jakarta-JSP and the TagLib project. I believe 4.0
uses Avalon, but not 3.2.1.
Harmeet
A Comment non-suit. :-)
g'night!
----- Original Message -----
From: "Leo Simons" <ma...@leosimons.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, March 28, 2001 11:23 PM
Subject: showcasing Avalon
> It occured to me that I was unable to find a
> live server running on Avalon referenced
> anywhere. Assuming there are, where can I
> find those.
>
> Also, has there been discussion of setting up
> some kind of Jakarta project showcase server,
> where there are live demos of avalon/tomcat/etc?
> I browsed enhydra's airsent.com demo, and thought
> "hey, that could be done in a week or two using
> Jakarta projects. Should be a nice demo for suits."
>
> Comments, from suits and non-suits?
>
> g'night!
>
> LSD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: showcasing Avalon
Posted by Harmeet Bedi <hb...@yahoo.com>.
I think it is a very good to eat your own dog food and showcase it.
I think there should be place for demos, but also if one can run parts of
Jakarta site on Jakarta projects, then it should be attempted
2 good objectives would be to migrate
- Mailing lists to James, listserv facilities.
- Mail Archives UI using Jakarta-JSP and the TagLib project. I believe 4.0
uses Avalon, but not 3.2.1.
Harmeet
A Comment non-suit. :-)
g'night!
----- Original Message -----
From: "Leo Simons" <ma...@leosimons.com>
To: "Avalon Development" <av...@jakarta.apache.org>
Sent: Wednesday, March 28, 2001 11:23 PM
Subject: showcasing Avalon
> It occured to me that I was unable to find a
> live server running on Avalon referenced
> anywhere. Assuming there are, where can I
> find those.
>
> Also, has there been discussion of setting up
> some kind of Jakarta project showcase server,
> where there are live demos of avalon/tomcat/etc?
> I browsed enhydra's airsent.com demo, and thought
> "hey, that could be done in a week or two using
> Jakarta projects. Should be a nice demo for suits."
>
> Comments, from suits and non-suits?
>
> g'night!
>
> LSD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: jmx (RE: showcasing Avalon)
Posted by Peter Donald <do...@apache.org>.
At 09:42 29/3/01 +0200, Leo Simons wrote:
>> I was actually thinking about doing that for cocoon but have been
>> too lazy.
>> It could be good to do if someone was willing to do the work ... ;)
>
>not me, not me! :)
>
>I'm 70% through the JMX spec. This sounds like a very interesting
>project to tackle. I think I'm going to give it a try; coding to
>start somewhere next week.
excellent!
>So, what are the ideas on it so far? Specifically:
>
>- would there be any (license) problems using the RI (the com.sun.*
>classes)?
The license problem would be that we would not be allowed to say that
Avalon/Phoenix was JMX compliant. There are other implementations out there
(enhydra has one) which if switched to later we could now say was jmx
compliant (I think - thou we may need to check with lawyers).
>- has anyone thought about how phoenix/jmx should be integrated (I
> myself see the possibility of simply making the jmx server a
> component, but that may lead to loop dependencies)?
Heres what was discussed a while ago (thou you would have to figure out if
it is the write way to do it).
* Main.class initially starts a MBeanServer.
* Then Main.class would then also send a "go" signal to the MBeanServer
which would launch the kernel and start it up. It could also (optionally?)
install/deploy any .sars in apps directory.
* The Kernel has it's own separate MBean that manages deployment of sars,
and lifecycle of kernel etc. (ie start, stop)
* Each server-application has it's own MBean that is used to manage it's
lifecycle (ie install, deploy, start, stop, undeploy, uninstall). It may
also have a MBean to configure various services
(logging/classpath/policy/configuration/whatever).
* each Block can optionally export a management interface
The way we thought about implementing it was something like
org.apache.phoenix.engine.management.*
Contains generic management classes. ie It would contain default interfaces
(and implementations) for the common lifecycle management interfaces. It
would also contain classes that discover and use dynamic dispatching (via
reflection) of methods/classes etc.
org.apache.phoenix.engine.management.jmx.*
Contains all the management filese directly related to JMX. ie The server
and MBean wrappers. It would most likely use DynamicMBeans (or whatever
they are called) to do the work. It would use
org.apache.phoenix.engine.management.* to do the dispatching etc.
Of course this is long-term ideas and it would be best to start with
something simpler and working ;) What do you think of the above?
>- has anyone thought about how Avalon's Service relates to an MBean?
> (should Service extend MBean?)
Some services are directly equivelent to one of their MBean services are.
ie
org.apache.cornerstone.demos.helloworldserver.HelloWorldServer
Others are more developer orientated rather than management orientated. So
I believe that when we are implementing it we are going to need add an
extra tag to service element in .xinfo files. (Namely to indicate whether
it is a management interface or not). Or maybe we could add extra elements
in .xinfo. I really don't know - I guess it is something you will have to
figure out ;)
>- does anyone know of open source use of jmx besides jboss, enhydra and
> the reference implementation?
nope - theres a few servers that offer a MBean (ie tomcat) but no others I
know of that that use an agent or a MBeanServer.
>- any company out there wishing to pay for my phone bill for time
> invested in Avalon (I may have to switch to water & bread soon)?
> (okay so maybe it's off-topic....)
;)
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
RE: jmx (RE: showcasing Avalon)
Posted by Stephen McConnell <mc...@osm.net>.
Harmeet Bedi [mailto:hbedi@yahoo.com] wrote:
[snip]
> I think Avalon is great.
Me too!!
> It just needs to get into stabilization phase and
> brand building phase. I think individuals in different
> companies would get it. My fear is that Avalon could get
> too complicated.
I think this is a question of "brand management" .. here are
the things that I have in mind when I look at the "Avalon
big-picture"
Phoenix
- a server activation framework - makes life easier
because I can use a "quasi-standard" model for
configuration of different blocks, deployment under
a .sar, etc.
- feels incomplete because of the lack of a management
interface (even a little local command line interface
to start the server, reconfigure, stop, etc. would
complete the picture)
- biggest benefit is "potential" to re-use third-party
blocks but (although this hasn't materialised yet)
Avalon
- a set of interfaces that a project can use to improve
code quality and consistency .. its kind of like going
beyond coding practices and saying, ok, this is a set
of patterns that will be used on project X - based
on our experience that patterns work nicely (although
I think the Cascading exception model is insufficiently
exploited)
Cornerstone
- confusing, on one hand it looks like a set of
demonstrations on how to build a block, and the
demonstration were questionable a couple of months ago,
which lead to the assumption that "ok, that's nice, so
lets focus on the real things - Avalon core and Phoenix -
however, James used cornerstone components in a real context
which doesn't sit well with this theory - hence a little
confusion - maybe "demo" content should be slit out
away from real re-usable Cornerstone blocks?
Each of these packages target distinctly different in the types of users.
In the Phoenix case its the server administrator and his problem is
configuration, deployment, management, etc. In the Avalon case the target
is the "responsible" for project policy, coding standards, object model,
etc. In the Cornerstone case its the developer who wants to be able to
re-use existing components - but the bottom line here is that these
components are only as good as the documentation supplying the code as a
fallback position does not cut it IMNSHO) - but before someone jumps on me
for saying this, I have to confess that I haven't really check the javadoc
on the cornerstone blocks in at least a couple of months - maybe things
have been updated.
Conclusions ....
(1) move demo stuff out of Cornerstone if Cornerstone is
more than a demo
(2) focus Phoenix "brand" as the runtime server deployment framework
- should be enhanced to handle ".sar"/".bar" declaration of the
version of Phoenix need for deployment (if you have
any doubts about this, just try plying around with
Avalon CVS, Jakarta James, Jakarta Tomcat and the
eas.betaversion.org blocks :-)
(3) focus Avalon on best-of-breed software practice
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: jmx (RE: showcasing Avalon)
Posted by Harmeet Bedi <hb...@yahoo.com>.
----- Original Message -----
From: "Leo Simons" <ma...@leosimons.com>
Sent: Thursday, March 29, 2001 11:42 AM
Subject: jmx (RE: showcasing Avalon)
> > I was actually thinking about doing that for cocoon but have been
> > too lazy.
> > It could be good to do if someone was willing to do the work ... ;)
>
> not me, not me! :)
>
> I'm 70% through the JMX spec. This sounds like a very interesting
> project to tackle. I think I'm going to give it a try; coding to
> start somewhere next week.
Some time back, I had hit the problem of JMX and avalon. A different Avalon
Kernel was created and JMX based MBean Server. For me the refactoring was
more important than the JMX issues. But writing a limited JMX Dynamic MBean
based server seemed to be easiest to do.
>
> So, what are the ideas on it so far? Specifically:
>
> - would there be any (license) problems using the RI (the com.sun.*
> classes)?
I think it is a high gain and low pain path. Could be good for protoyping
and building on, and then move migrate to something without license baggage.
> - has anyone thought about how phoenix/jmx should be integrated (I
> myself see the possibility of simply making the jmx server a
> component, but that may lead to loop dependencies)?
> - has anyone thought about how Avalon's Service relates to an MBean?
> (should Service extend MBean?)
I think it should be part of Kernel. Avalon has changed a lot in the last
few months. My earlier work on this was based on taking Avalon B1 (I think),
making each service, an avalon block and derive from a default
implementation that contained reflection code to implement a default Dynamic
MBean. This was pretty painless.
Notification facilities were not implemented.
> - does anyone know of open source use of jmx besides jboss, enhydra and
> the reference implementation?
Enhydra seems to have a lot of good stuff. They have SNMP, and WBEM(I think
this is for paying customers only) implemetation. Their JMX inplementation
is less tainted than sun.
> - any company out there wishing to pay for my phone bill for time
> invested in Avalon (I may have to switch to water & bread soon)?
> (okay so maybe it's off-topic....)
I think Avalon is great. It just needs to get into stabilization phase and
brand building phase. I think individuals in different companies would get
it. My fear is that Avalon could get too complicated.
Harmeet
>
> g'night,
>
> LSD
>
> <java:sig>
> About LSD = new PersonalInfo();
> LSD.name("Leo Simons");
> LSD.email("mail@leosimons.com");
> LSD.URL( [
> http://www.leosimons.com, // personal website
> http://www.atfantasy.com, // fantasy RPG portal
> http://www.the-sign.nl // web-design company
> ] );
> LSD.quote("Buh!");
> email.setSig((String)LSD);
> </java:sig>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
jmx (RE: showcasing Avalon)
Posted by Leo Simons <ma...@leosimons.com>.
> I was actually thinking about doing that for cocoon but have been
> too lazy.
> It could be good to do if someone was willing to do the work ... ;)
not me, not me! :)
I'm 70% through the JMX spec. This sounds like a very interesting
project to tackle. I think I'm going to give it a try; coding to
start somewhere next week.
So, what are the ideas on it so far? Specifically:
- would there be any (license) problems using the RI (the com.sun.*
classes)?
- has anyone thought about how phoenix/jmx should be integrated (I
myself see the possibility of simply making the jmx server a
component, but that may lead to loop dependencies)?
- has anyone thought about how Avalon's Service relates to an MBean?
(should Service extend MBean?)
- does anyone know of open source use of jmx besides jboss, enhydra and
the reference implementation?
- any company out there wishing to pay for my phone bill for time
invested in Avalon (I may have to switch to water & bread soon)?
(okay so maybe it's off-topic....)
g'night,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: showcasing Avalon
Posted by Peter Donald <do...@apache.org>.
At 09:23 29/3/01 +0200, Leo Simons wrote:
>It occured to me that I was unable to find a
>live server running on Avalon referenced
>anywhere. Assuming there are, where can I
>find those.
Umm there is a few up but none that I know on open networks. Besides Avalon
itself doesn't really do anything. There is a few sites up with Cocoon
which uses avalon .. but other than that .. not sure.
>Also, has there been discussion of setting up
>some kind of Jakarta project showcase server,
>where there are live demos of avalon/tomcat/etc?
>I browsed enhydra's airsent.com demo, and thought
>"hey, that could be done in a week or two using
>Jakarta projects. Should be a nice demo for suits."
I was actually thinking about doing that for cocoon but have been too lazy.
It could be good to do if someone was willing to do the work ... ;)
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
Re: One user's point of view ( was RE: showcasing Avalon)
Posted by Peter Donald <do...@apache.org>.
At 11:20 30/3/01 -0700, Carl Parrish wrote:
>> * not sure on how to design namespace. ie Functional vs structural or both
>> ie
>> Functional:
>> app1/blocks/block1/Configuration
>> app1/blocks/block1/ComponentMapping
>> app1/blocks/block1/...
>>
>> Structural:
>> app1/configuration/blocks/block1
>> app1/componentmapping/blocks/block1
>> app1/logs/block1/category
>> app1/policy/block1/category
>>
>
>
>My vote would be for Structual. I'm just getting up to speed on JNDI but
>it seems Like I would want to code it in a Structual environment. What
>would be the major advantages to doing it Functional?
centralized management. It would be nicer to just have to look in context
for all details about one block. The structural model requires another
context per different type of information. Not sure if it is worth the
effort yet thou ;)
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
Re: One user's point of view ( was RE: showcasing Avalon)
Posted by Carl Parrish <ca...@datasoft.com>.
> * not sure on how to design namespace. ie Functional vs structural or both
> ie
> Functional:
> app1/blocks/block1/Configuration
> app1/blocks/block1/ComponentMapping
> app1/blocks/block1/...
>
> Structural:
> app1/configuration/blocks/block1
> app1/componentmapping/blocks/block1
> app1/logs/block1/category
> app1/policy/block1/category
>
My vote would be for Structual. I'm just getting up to speed on JNDI but
it seems Like I would want to code it in a Structual environment. What
would be the major advantages to doing it Functional?
Carl Parrish
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: One user's point of view ( was RE: showcasing Avalon)
Posted by Peter Donald <do...@apache.org>.
At 03:20 30/3/01 +0200, Stephen McConnell wrote:
>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.
What I was thinking was modeling it more like Deployer class. So you would
have a
interface Installer
{
void install( String name, URL location )
throws InstallationException;
void uninstall( String name )
throws InstallationException;
}
This would install components into a container. Installation would involve
essentiall doing most of the work Deployer does now except-
* It does not mark the component as "ready to be run"
* It does not interpret any config files
>For reference, what are the issues you referring too ?
A few implementation and a few design;
implementation
* I didn't really understand JNDI till a bit back
* too lazy to implement DirectoryContext
* Can not hijack global NamingManager as hosted apps may need it
design
* not sure how far to go. ie should we continue to have BlockEntrys or
should everything be put in directory - or should we just mount the
BlockEntry in directory
* not sure on how to design namespace. ie Functional vs structural or both
ie
Functional:
app1/blocks/block1/Configuration
app1/blocks/block1/ComponentMapping
app1/blocks/block1/...
Structural:
app1/configuration/blocks/block1
app1/componentmapping/blocks/block1
app1/logs/block1/category
app1/policy/block1/category
or a combined approach where underlying Structural but have a Functional
line-up that referrs to the correct items.
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
RE: One user's point of view ( was RE: showcasing Avalon)
Posted by Peter Donald <do...@apache.org>.
At 03:33 30/3/01 +0200, Stephen McConnell wrote:
>
>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.
SOunds like joy ;)
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
RE: One user's point of view ( was RE: showcasing Avalon)
Posted by Stephen McConnell <mc...@osm.net>.
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
RE: One user's point of view ( was RE: showcasing Avalon)
Posted by Stephen McConnell <mc...@osm.net>.
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 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,
then
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
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
> >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
Re: One user's point of view ( was RE: showcasing Avalon)
Posted by Peter Donald <do...@apache.org>.
Hi,
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.
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 ;)
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
Re: One user's point of view ( was RE: showcasing Avalon)
Posted by Paul Hammant <pa...@yahoo.com>.
> One of the principal "pains" in this process
> is the lack of support in Avalon for lifecycle components "install",
> "upgrade", "degrade" and "uninstall".
+1
=====
Regards - Paul H
====
CVS -1, Perforce +1
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
One user's point of view ( was RE: showcasing Avalon)
Posted by Stephen McConnell <mc...@osm.net>.
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).
Cheers, Steve.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@osm.net]
> Sent: Friday, 30 March, 2001 01:05
> To: Avalon Development
> Subject: RE: showcasing Avalon
>
>
>
>
> Leo:
>
> OSM are using the Avalon/Phoenix frameworks for several servers that
> collectively establish a collaboration gateway for B2B
> e-commerce. Here is
> the list of servers currently running:
>
> OSM Time Service
> Provides distributed time services complaint with the OMG CosTime
> specifications. This block is a general service component that can
> be accessed as a reference time source for multiple servers
> participating in collaborative business actions (i.e. where it is
> necessary that the time authority can be separated from the business
> process in hand).
>
> OSM Registration and Discovery Service
> Provides support for the publication and discovery of descriptions of
> information resources and business processes and the referral of these
> resources from one business entity to another.
>
> OSM Audit Service
> Provides support for the creation of business object adapters that
> maintain a persistent history about the lifecycle and state
> of remotely located business objects (people, places, things, tasks,
> processors, etc.).
>
> OSM Collaboration Hub
> A server that provides support for the establishment and execution of
> collaborative business processes between distributed participants, the
> execution of business processes that involve sub-process execution in
> remote business domains (e.g. credit provision or logistics), a full
> business object environment enabling creation and management of Users,
> Workspaces, Tasks, a variety of persistent transactions resources,
> Processors, and back-end legacy management through a plug-in Appliance
> framework. The implementation is fully compliant with the OMG
Electonic
> Commerce Domain Specifications for Collaboration and Community
services
> and the Business Object Domain specifications for Task and Session
> services.
>
> Cheers, Steve.
>
> Stephen J. McConnell, OSM sarl
> digital products for a global economy
> http://www.osm.net
> mailto:mcconnell@osm.net
>
>
>
>
> > -----Original Message-----
> > From: Leo Simons [mailto:mail@leosimons.com]
> > Sent: Thursday, 29 March, 2001 09:23
> > To: Avalon Development
> > Subject: showcasing Avalon
> >
> >
> > It occured to me that I was unable to find a
> > live server running on Avalon referenced
> > anywhere. Assuming there are, where can I
> > find those.
> >
> > Also, has there been discussion of setting up
> > some kind of Jakarta project showcase server,
> > where there are live demos of avalon/tomcat/etc?
> > I browsed enhydra's airsent.com demo, and thought
> > "hey, that could be done in a week or two using
> > Jakarta projects. Should be a nice demo for suits."
> >
> > Comments, from suits and non-suits?
> >
> > g'night!
> >
> > LSD
> >
> > ---------------------------------------------------------------------
> > 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
RE: showcasing Avalon
Posted by Stephen McConnell <mc...@osm.net>.
Leo:
OSM are using the Avalon/Phoenix frameworks for several servers that
collectively establish a collaboration gateway for B2B e-commerce. Here is
the list of servers currently running:
OSM Time Service
Provides distributed time services complaint with the OMG CosTime
specifications. This block is a general service component that can
be accessed as a reference time source for multiple servers
participating
in collaborative business actions (i.e. where it is necessary that the
time
authority can be separated from the business process in hand).
OSM Registration and Discovery Service
Provides support for the publication and discovery of descriptions of
information resources and business processes and the referral of these
resources from one business entity to another.
OSM Audit Service
Provides support for the creation of business object adapters that
maintain a persistent history about the lifecycle and state of remotely
located business objects (people, places, things, tasks, processors,
etc.).
OSM Collaboration Hub
A server that provides support for the establishment and execution of
collaborative business processes between distributed participants, the
execution of business processes that involve sub-process execution in
remote
business domains (e.g. credit provision or logistics), a full business
object
environment enabling creation and management of Users, Workspaces,
Tasks,
a variety of persistent transactions resources, Processors, and back-end
legacy management through a plug-in Appliance framework. The
implementation
is fully compliant with the OMG Electonic Commerce Domain Specifications
for
Collaboration and Community services and the Business Object Domain
specifications for Task and Session services.
Cheers, Steve.
Stephen J. McConnell, OSM sarl
digital products for a global economy
http://www.osm.net
mailto:mcconnell@osm.net
> -----Original Message-----
> From: Leo Simons [mailto:mail@leosimons.com]
> Sent: Thursday, 29 March, 2001 09:23
> To: Avalon Development
> Subject: showcasing Avalon
>
>
> It occured to me that I was unable to find a
> live server running on Avalon referenced
> anywhere. Assuming there are, where can I
> find those.
>
> Also, has there been discussion of setting up
> some kind of Jakarta project showcase server,
> where there are live demos of avalon/tomcat/etc?
> I browsed enhydra's airsent.com demo, and thought
> "hey, that could be done in a week or two using
> Jakarta projects. Should be a nice demo for suits."
>
> Comments, from suits and non-suits?
>
> g'night!
>
> LSD
>
> ---------------------------------------------------------------------
> 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