You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2002/04/10 14:59:48 UTC
Lifecycleable interface
I am about to do some more work on Jesktop (given there is more competition currently). Nicola
Ken suggested that Jesktop could benefit from general services and I am inclided to do that, but
maybe there is a case for a hot-puggable system like Jesktop to have a Lifecycleable api. As this
possibly applies to Avalon in genral. As such, I'd like to propose it here :
interface Lifecycleable {
// int getStage(); // maybe ?
String getLifecycleInterface();
void startupLifecycle(Object obj);
void shutdownLifecycle(Object obj);
}
DefaultLogEnabledLifecyclable extends AbstractLogEnabled implemnents Lifecyclable{
public String getLifecycleInterface() {
retrurn "org.apache.avalon.framework.LogEnabled";
}
public void startupLifecycle(Object obj) {
((LogEnabled) obj).enableLogging(getLogger());
}
public void shutdownLifecycle(Object obj) {
((LogEnabled) obj).enableLogging(null); //maybe
}
}
And similar for Iniializable, Startable, Dooable, Blahable...
Thoughts?
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Cocoon skin ready
Posted by Peter Donald <pe...@apache.org>.
On Sun, 14 Apr 2002 02:13, Nicola Ken Barozzi wrote:
> The newly proposed Avalon skin TBU in Cocoon site generation is ready.
>
> Unfortunately, the POI dev that updates the site liked the skin so much he
> used it right away.
> I hope this isn't a problem, and apologise in case.
>
> Since it was AFAIR a proposal, you can see if you like it by looking at
> http://jakarta.apache.org/poi/ .
looks good.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Cocoon skin ready
Posted by Leo Simons <le...@apache.org>.
> The newly proposed Avalon skin TBU in Cocoon site generation is ready.
yay! Good work =)
>
> Unfortunately, the POI dev that updates the site liked the skin so much he
> used it right away.
> I hope this isn't a problem, and apologise in case.
;) Free software pertains to graphics as well...
> Since it was AFAIR a proposal, you can see if you like it by looking at
> http://jakarta.apache.org/poi/ .
Note that POI doesn't use page titles like we do, so there is no title.
Also not that they don't use the breadcrumb javascript properly, so it
looks a bit awkward.
> Anyway, the only thing needed to run it without Centipede is is the
> forrest.cent.jar file.
> Unpack it and call the xbuild.xml Ant build file, specifying before the
> necessary properties. The properties are easily specified in xml files in
> Centipede, so it's easy to call the Centipede task that loads them.
Could you put this in CVS (proposal dir) / supply a patch? (I'm not quite
sure which properties you talk about, etc.)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Avalon Cocoon skin ready
Posted by Nicola Ken Barozzi <ni...@apache.org>.
The newly proposed Avalon skin TBU in Cocoon site generation is ready.
Unfortunately, the POI dev that updates the site liked the skin so much he
used it right away.
I hope this isn't a problem, and apologise in case.
Since it was AFAIR a proposal, you can see if you like it by looking at
http://jakarta.apache.org/poi/ .
To see how the site generation works with Cocoon in Centipede, you can take
a look in the POI CVS module.
Anyway, the only thing needed to run it without Centipede is is the
forrest.cent.jar file.
Unpack it and call the xbuild.xml Ant build file, specifying before the
necessary properties. The properties are easily specified in xml files in
Centipede, so it's easy to call the Centipede task that loads them.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lifecycleable interface
Posted by Paul Hammant <Pa...@yahoo.com>.
James,
I think that in the end, the guys have a point in that this does not fit
Phoenix very well. It does sorta break the IoC idea. A redeeming pont
is that the way Jeskop mounts apps that are largely already writen there
is a lot of breaking of IoC going on inside the scope of that hosted
app. As such, and becase of the hot-pluggable nature, I am going to
create the interface after all, but inside Jesktop.
- Paul
>Paul,
>
>As an application developer, I am fully appreciate what you are going to do.
>
>Phoenix has a drawback as a server/container of other application
>containers(i.e. serlvet, EJB, Jesktop etc..). It doesn't provide a simple,
>united way to allow applications(i.e., a servlet deployed in a serlvet
>engine contained in phoenix) to communicate with the phoenix kernel, other
>sars, and other blocks assemble within the same sar.
>
>I hope in the future, I can answer the question 'Why deploy a servlet in Jo!
>running inside Phoenix, but not a standalone Jo! environment' as 'The
>servlet can utilize services provided by other phoenix blocks'(The Beauty of
>Phoenix).
>
>James Lau
>
>----- Original Message -----
>From: "Paul Hammant" <pa...@yahoo.com>
>To: "Avalon" <av...@jakarta.apache.org>
>Sent: Wednesday, April 10, 2002 8:59 PM
>Subject: Lifecycleable interface
>
>
>>I am about to do some more work on Jesktop (given there is more
>>
>competition currently). Nicola
>
>>Ken suggested that Jesktop could benefit from general services and I am
>>
>inclided to do that, but
>
>>maybe there is a case for a hot-puggable system like Jesktop to have a
>>
>Lifecycleable api. As this
>
>>possibly applies to Avalon in genral. As such, I'd like to propose it here
>>
>:
>
>>interface Lifecycleable {
>> // int getStage(); // maybe ?
>> String getLifecycleInterface();
>> void startupLifecycle(Object obj);
>> void shutdownLifecycle(Object obj);
>>}
>>
>>DefaultLogEnabledLifecyclable extends AbstractLogEnabled implemnents
>>
>Lifecyclable{
>
>> public String getLifecycleInterface() {
>> retrurn "org.apache.avalon.framework.LogEnabled";
>> }
>> public void startupLifecycle(Object obj) {
>> ((LogEnabled) obj).enableLogging(getLogger());
>> }
>> public void shutdownLifecycle(Object obj) {
>> ((LogEnabled) obj).enableLogging(null); //maybe
>> }
>>}
>>
>>And similar for Iniializable, Startable, Dooable, Blahable...
>>
>>Thoughts?
>>
>>- Paul
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Everything you'll ever need on one web page
>>from News and Sport to Email and Music Charts
>>http://uk.my.yahoo.com
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lifecycleable interface
Posted by Leo Simons <le...@apache.org>.
> Phoenix has a drawback as a server/container of other application
> containers(i.e. serlvet, EJB, Jesktop etc..). It doesn't provide a simple,
> united way to allow applications(i.e., a servlet deployed in a serlvet
> engine contained in phoenix) to communicate with the phoenix kernel, other
> sars, and other blocks assemble within the same sar.
This follows directly from the implementation of the Inversion of Control
pattern. You should not see it as a drawback!
> I hope in the future, I can answer the question 'Why deploy a
> servlet in Jo!
> running inside Phoenix, but not a standalone Jo! environment' as 'The
> servlet can utilize services provided by other phoenix
> blocks'(The Beauty of
> Phoenix).
I think that 'The servlet can utilize services provided by other phoenix
blocks' should not be a feature of phoenix. Rather, it should be a feature
of an application/block running in Phoenix, for example, a JNDI registry.
The reason: we want to guarantee applications running within phoenix a
black box. While it should be possible for others to gain access to the
black box (ie use the services it exposes), this is not something the
kernel should do, but rather something the application in that black box
should do itself.
In concrete terms, we have Phoenix running a JMX Server in one block
(and the kernel registers itself with the JMX Server), another block
running EOB (which registers itself with the JMX Server) and yet
another block running Jo! (which registers itself with the JMX Server).
Jo! can now access EOB through JMX, but not through the kernel.
Further discussion should go to the phoenix list, of course.
regards,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lifecycleable interface
Posted by Leo Simons <le...@apache.org>.
> Phoenix has a drawback as a server/container of other application
> containers(i.e. serlvet, EJB, Jesktop etc..). It doesn't provide a simple,
> united way to allow applications(i.e., a servlet deployed in a serlvet
> engine contained in phoenix) to communicate with the phoenix kernel, other
> sars, and other blocks assemble within the same sar.
This follows directly from the implementation of the Inversion of Control
pattern. You should not see it as a drawback!
> I hope in the future, I can answer the question 'Why deploy a
> servlet in Jo!
> running inside Phoenix, but not a standalone Jo! environment' as 'The
> servlet can utilize services provided by other phoenix
> blocks'(The Beauty of
> Phoenix).
I think that 'The servlet can utilize services provided by other phoenix
blocks' should not be a feature of phoenix. Rather, it should be a feature
of an application/block running in Phoenix, for example, a JNDI registry.
The reason: we want to guarantee applications running within phoenix a
black box. While it should be possible for others to gain access to the
black box (ie use the services it exposes), this is not something the
kernel should do, but rather something the application in that black box
should do itself.
In concrete terms, we have Phoenix running a JMX Server in one block
(and the kernel registers itself with the JMX Server), another block
running EOB (which registers itself with the JMX Server) and yet
another block running Jo! (which registers itself with the JMX Server).
Jo! can now access EOB through JMX, but not through the kernel.
Further discussion should go to the phoenix list, of course.
regards,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lifecycleable interface
Posted by James Lau <ja...@hotmail.com>.
Paul,
As an application developer, I am fully appreciate what you are going to do.
Phoenix has a drawback as a server/container of other application
containers(i.e. serlvet, EJB, Jesktop etc..). It doesn't provide a simple,
united way to allow applications(i.e., a servlet deployed in a serlvet
engine contained in phoenix) to communicate with the phoenix kernel, other
sars, and other blocks assemble within the same sar.
I hope in the future, I can answer the question 'Why deploy a servlet in Jo!
running inside Phoenix, but not a standalone Jo! environment' as 'The
servlet can utilize services provided by other phoenix blocks'(The Beauty of
Phoenix).
James Lau
----- Original Message -----
From: "Paul Hammant" <pa...@yahoo.com>
To: "Avalon" <av...@jakarta.apache.org>
Sent: Wednesday, April 10, 2002 8:59 PM
Subject: Lifecycleable interface
> I am about to do some more work on Jesktop (given there is more
competition currently). Nicola
> Ken suggested that Jesktop could benefit from general services and I am
inclided to do that, but
> maybe there is a case for a hot-puggable system like Jesktop to have a
Lifecycleable api. As this
> possibly applies to Avalon in genral. As such, I'd like to propose it here
:
>
> interface Lifecycleable {
> // int getStage(); // maybe ?
> String getLifecycleInterface();
> void startupLifecycle(Object obj);
> void shutdownLifecycle(Object obj);
> }
>
> DefaultLogEnabledLifecyclable extends AbstractLogEnabled implemnents
Lifecyclable{
>
> public String getLifecycleInterface() {
> retrurn "org.apache.avalon.framework.LogEnabled";
> }
> public void startupLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(getLogger());
> }
> public void shutdownLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(null); //maybe
> }
> }
>
> And similar for Iniializable, Startable, Dooable, Blahable...
>
> Thoughts?
>
> - Paul
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lifecycleable interface
Posted by Berin Loritsch <bl...@apache.org>.
Honestly, I'm not sure what problem you are trying to solve.
Perhaps you could give a little background?
Paul Hammant wrote:
> I am about to do some more work on Jesktop (given there is more competition currently). Nicola
> Ken suggested that Jesktop could benefit from general services and I am inclided to do that, but
> maybe there is a case for a hot-puggable system like Jesktop to have a Lifecycleable api. As this
> possibly applies to Avalon in genral. As such, I'd like to propose it here :
>
> interface Lifecycleable {
> // int getStage(); // maybe ?
> String getLifecycleInterface();
> void startupLifecycle(Object obj);
> void shutdownLifecycle(Object obj);
> }
>
> DefaultLogEnabledLifecyclable extends AbstractLogEnabled implemnents Lifecyclable{
>
> public String getLifecycleInterface() {
> retrurn "org.apache.avalon.framework.LogEnabled";
> }
> public void startupLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(getLogger());
> }
> public void shutdownLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(null); //maybe
> }
> }
>
> And similar for Iniializable, Startable, Dooable, Blahable...
>
> Thoughts?
>
> - Paul
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lifecycleable interface
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>This was the approach taken with an early version of phoenix. However it was
>a lot of damn work for very little benefit and I could never justify the cost
>of using it.
>
I appreciate it is a bad fit for Pehoenix and Cocoon, but for Jesktop it
is compelling as it allows extened functionaility.
Perhaps I will evolve it in Jesktop and if needs be it can be sucked
into framework even if no other Avalon comp uses it.
>Is there a reason why ApplicationListener wont do what you need to do?
>
I'll think about it, but I am not sure if that can servr the needs of
hot pluggable services.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Lifecycleable interface
Posted by Peter Donald <pe...@apache.org>.
Hi,
This was the approach taken with an early version of phoenix. However it was
a lot of damn work for very little benefit and I could never justify the cost
of using it.
Is there a reason why ApplicationListener wont do what you need to do?
On Wed, 10 Apr 2002 22:59, Paul Hammant wrote:
> I am about to do some more work on Jesktop (given there is more competition
> currently). Nicola Ken suggested that Jesktop could benefit from general
> services and I am inclided to do that, but maybe there is a case for a
> hot-puggable system like Jesktop to have a Lifecycleable api. As this
> possibly applies to Avalon in genral. As such, I'd like to propose it here
> :
>
> interface Lifecycleable {
> // int getStage(); // maybe ?
> String getLifecycleInterface();
> void startupLifecycle(Object obj);
> void shutdownLifecycle(Object obj);
> }
>
> DefaultLogEnabledLifecyclable extends AbstractLogEnabled implemnents
> Lifecyclable{
>
> public String getLifecycleInterface() {
> retrurn "org.apache.avalon.framework.LogEnabled";
> }
> public void startupLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(getLogger());
> }
> public void shutdownLifecycle(Object obj) {
> ((LogEnabled) obj).enableLogging(null); //maybe
> }
> }
>
> And similar for Iniializable, Startable, Dooable, Blahable...
>
> Thoughts?
>
> - Paul
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
--
Cheers,
Pete
------------------------------------------------------------
militant agnostic: i don't know, and you don't know either.
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Lifecycleable interface
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, so after you have instantiated a class,
you inspect it and send it through a pipeline of
Lifecyclable objects that each apply a single
lifecycle "checkpoint"?
Basically a ComponentFactory, but extensible to new
lifecycle interfaces by addition of LifeCyclable
handlers?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>