You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Emperor <Da...@gmx.net> on 2002/02/24 20:58:03 UTC
shutdown phoenix gracefully
Steve: thx for your very very useful posts!
And now another question. How can I shutdown phoenix from within a
block? How do I get the embeddor instance I need to shutdown?
Each time I get deeper involved in avalon I could ask 10 more questions
;)
Nils
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: shutdown phoenix gracefully
Posted by Richard Wallace <rw...@a--i--m.com>.
I have a similar question. How can an application shut itself down?
On Sun, 2002-02-24 at 15:11, Stephen McConnell wrote:
>
>
> > -----Original Message-----
> > From: Emperor [mailto:DarkEmperor@gmx.net]
> > Sent: Sunday, 24 February, 2002 20:58
> > To: avalon-dev@jakarta.apache.org
> > Subject: shutdown phoenix gracefully
> >
> >
> >
> > Steve: thx for your very very useful posts!
>
> No problem. But I think I'm going to let you down on the question
> concerning phoenix shutdown.
>
> > And now another question. How can I shutdown phoenix from within a
> > block?
>
> Not possible (but read on).
>
> > How do I get the embeddor instance I need to shutdown?
>
> Check out the ApplicationListener. This provides access to SarMetaData
> and related BlockInfo structures. You can do some level of playing around
> here but only at the block and application level. Basically, you only
> have access to the block or application context so your application cannot
> interfere in another applications space.
>
> There is some JMX management stuff that I honestly don't know much about
> (don't even know if its working or not). In principal it would provide
> management access to Phoenix. Personally I would like to see a pluggable
> controller so I can do things like remote CORBA based start-up/shutdown.
> Umm, Pete .. we spoke about something like this a couple of months back.
> Maybe its time to put it in place ?
>
> Cheers, Steve.
>
> > Each time I get deeper involved in avalon I could ask 10 more questions
> > ;)
> >
> > Nils
> >
> >
> >
> > --
> > 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>
--
Richard Wallace
AIM, Inc. (www.a--i--m.com)
Information Systems Consultants
"Providing New Technology,
the Old-Fashioned Way"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Sat, 31 Aug 2002 22:14, Paul Hammant wrote:
> >>requestShutdown();
> >>
> >> --> we can't be accused of not thinking about this one carefully
> >>(conversation started in Feb).
> >>
> >>How difficult will it be to fit permissions (environment.xml) onto this
> >>given multiple containers?
> >>
> >> <revoke code-base="sar:SAR-INF/lib/*">
> >> <permission
> >>class="org.apache.avalon.somepackage.AppShutdownViaBlockPermission" />
> >> </revoke>
> >
> >Granting permissions are easy to implement (revoking is a PITA unless
> > JDK1.4 specific) but I am not sure they are necessary. The accompanying
> > javadoc indicates that it is just a request and need not be honored by
> > the container.
>
> So basically, the advice would be to grant a specific set of rights for
> the app (when All is not good enough).
Thats the way the java platform works in general. It dervies from javas need
for flexible security combined with performance. With just grants you need to
test once against compiled representation of permissions while if you had
denys it require two tests.
JDK1.4 allows you to "recompile" the grant permission set so you can remove
permissions from an set but you still don't have a standard mechanism for
denies (unless you want to implement it differently in your own components).
> It is a shame that it is not like Ant's <include> <exclude> model.
> Methinks, I may be shot down for holding that up as a good design!!
:)
Much better for us - probably less good for admins though ;/
--
Cheers,
Peter Donald
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>requestShutdown();
>>
>> --> we can't be accused of not thinking about this one carefully
>>(conversation started in Feb).
>>
>>How difficult will it be to fit permissions (environment.xml) onto this
>>given multiple containers?
>>
>> <revoke code-base="sar:SAR-INF/lib/*">
>> <permission
>>class="org.apache.avalon.somepackage.AppShutdownViaBlockPermission" />
>> </revoke>
>>
>>
>
>Granting permissions are easy to implement (revoking is a PITA unless JDK1.4
>specific) but I am not sure they are necessary. The accompanying javadoc
>indicates that it is just a request and need not be honored by the container.
>
>
So basically, the advice would be to grant a specific set of rights for
the app (when All is not good enough).
It is a shame that it is not like Ant's <include> <exclude> model.
Methinks, I may be shot down for holding that up as a good design!!
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Peter Donald <pe...@apache.org>.
On Sat, 31 Aug 2002 19:16, Paul Hammant wrote:
> requestShutdown();
>
> --> we can't be accused of not thinking about this one carefully
> (conversation started in Feb).
>
> How difficult will it be to fit permissions (environment.xml) onto this
> given multiple containers?
>
> <revoke code-base="sar:SAR-INF/lib/*">
> <permission
> class="org.apache.avalon.somepackage.AppShutdownViaBlockPermission" />
> </revoke>
Granting permissions are easy to implement (revoking is a PITA unless JDK1.4
specific) but I am not sure they are necessary. The accompanying javadoc
indicates that it is just a request and need not be honored by the container.
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Stephen McConnell <mc...@apache.org>.
Hi Paul:
Paul Hammant wrote:
> Stephen,
>
>>> requestShutdown();
>>
>>
>> As noted in the thread over phoenix-dev, the addition of the operation
>> requestShutdown to BlockContext (as currently proposed) breaks the
>> component contract related to Contextualizable. A component receives
>> a Context object which is holder a keyed values. Adding behaviour
>> breaks potential for component portability.
>
>
> BlockContext extending Context is a 'mistake' we have made and not
> noticed for mutiple years. Given that the current advice for PhoenixAPI
> compatible containers is to include the phoenix-client.jar in their CVS
> and distribution, there is only a small amount of additional work to
> code implemetation of requestShutdown().
>
>> There are alternative solutions such a component requesting a
>> depedency on a shutdown request handler which would be totally
>> consistent eith the component model. Another less portable solution
>> would be expose a shutdown request handler object via a context key -
>> the component that requires this functionality would get the handler
>> and invoke a shutdown request against the handler.
>
>
> It could be that there is such a key to another interface called say
> ShutdownHandler (in the same package as BlockContext?),
This is an improvement in that it seperates the behaviour out of the
context object. An even better solution would be for component to
declare a service dependency on a shutdown handler.
> this ain't much
> different to requestShutdown() in BlockContext though.
There isn't much difference from the point of view of a programmer.
There is a lot of difference from the point of view of consitency with
respect to the Avalon Component Model. Within the model we have
declared a series of objects types that communication information
between a container and a component. There include the Logger, Context,
Parameters, Configuration and ServiceManger/ComponentManager, etc.
Each of these resources provide defined semantics (some better than
others). In the case of the Context type, the semantics are about access
to a keyed value. If the key does not exist, a ContextException if
thrown. There is perhaps a missing declaration of an incompatible type.
> This I guess is tied up in the late but long argument on whether there
> should be a BlockContext at all for enterprise level Avalon containers.
Exactly - the very existence of BlockContext defined a specilization of
the Avalon component model for Phoenix. Phoenix blocks assume that
casting to BlockContext is part of the contract. Within the scope of an
application/block written and dedicated to execution in the Phoenix
environment - this is a reasonable assumption. If a component is
written in accordance with the Avalon component model it will deal with
the supplied context object in accordance with the Avalon component
model specification - i.e. strict key lookup and no narrowing of a
context argument to something outside of the framework set of interaces.
The introduction of a more complete meta-info model at the framework
level would change this. The benefits of including a meta-info model
are that we introduce more explicit defintion of these resources that
are supplied between the container and the component it is managing.
For example, in the case of a Context depedendency, the ability for a
component to declare the keys and the type of object associated with the
key.
In the absence of a framework meta-info model the fallback position is
the Avalon framework component model + container specific adornments.
For example, Phoenix supplies the blockinfo definition in order to
establish available services and dependecies, Merlin provides similar
functionality that also addresses component context and other criteria.
Where we are today:
1. The base line is the Avalon Framework Component Model.
An interim solution is:
2. Defintion of a set of Avalon level common context keys
and the associated specification of the object type and
related semantics.
But keep in mind that this is verging on the modification
of the Avalon component model - what it implies is that
the we are modifying the semantics associated with the
contextualization phase of an Avalon component - should
every invocation of contextualize include common keys and
values?
The answer to that is no!
What the interim solution does provide is a mechanism
enabling better management of interoperability between
containers in the absense of a common meta-info model.
And the longer term solution is:
3. Defintion of a Avalon meta-info model that enables a
component to more completely declare its depedencies
and capabilities
Cheers, Steve.
> Regards,
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: shutdown phoenix gracefully
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> requestShutdown();
>
> As noted in the thread over phoenix-dev, the addition of the operation
> requestShutdown to BlockContext (as currently proposed) breaks the
> component contract related to Contextualizable. A component receives
> a Context object which is holder a keyed values. Adding behaviour
> breaks potential for component portability.
BlockContext extending Context is a 'mistake' we have made and not
noticed for mutiple years. Given that the current advice for PhoenixAPI
compatible containers is to include the phoenix-client.jar in their CVS
and distribution, there is only a small amount of additional work to
code implemetation of requestShutdown().
> There are alternative solutions such a component requesting a
> depedency on a shutdown request handler which would be totally
> consistent eith the component model. Another less portable solution
> would be expose a shutdown request handler object via a context key -
> the component that requires this functionality would get the handler
> and invoke a shutdown request against the handler.
It could be that there is such a key to another interface called say
ShutdownHandler (in the same package as BlockContext?), this ain't much
different to requestShutdown() in BlockContext though.
This I guess is tied up in the late but long argument on whether there
should be a BlockContext at all for enterprise level Avalon containers.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>
>
> On Mon, 26 Feb 2002 07:17, Peter Donald wrote:
>
>> On Mon, 25 Feb 2002 21:00, Paul Hammant wrote:
>>
>>
>>> Peter,
>>>
>>>
>>>
>>>>> There is some JMX management stuff that I honestly don't know much
>>>>> about
>>>>> (don't even know if its working or not). In principal it would provide
>>>>> management access to Phoenix. Personally I would like to see a
>>>>> pluggable
>>>>> controller so I can do things like remote CORBA based
>>>>> start-up/shutdown.
>>>>> Umm, Pete .. we spoke about something like this a couple of months
>>>>> back.
>>>>> Maybe its time to put it in place ?
>>>>>
>>>>
>>>> Maybe. It may be that the best thing to do for the moment is to add a
>>>>
>>>> void requestShutdown()
>>>>
>>>
>>> +1
>>>
>>> Could we have some params for that?
>>>
>>> Immediately | Delayed | Server App Only
>>
>>
>> I see no need for delayed but Immediate + Server App Only ==
>> requestShutdown()
>>
>>
>>
>>
>>> All Server Apps
>>>
>>
>>
>> -1 One app should not be able to effect another app except via a
>> management interface.
>>
>>
>>
>>> Also should it throw ShutdownVetoedException ? Should we have a segment
>>> in environment.xml to indicate whether a server app plans to and is
>>> allowed to use requestShutdown()?
>>>
>>
>>
>> That may be an idea. Though it may be best to declare that the block
>> is capable of calling requestShutdown(). I have contemplated having a
>> similar thing for other services on BlockContext.
>> For instance if no Block in application ever calls getBaseDirectory()
>> then there is no need to install it to a directory.
>>
> requestShutdown();
>
> --> we can't be accused of not thinking about this one carefully
> (conversation started in Feb).
>
> How difficult will it be to fit permissions (environment.xml) onto this
> given multiple containers?
>
> <revoke code-base="sar:SAR-INF/lib/*">
> <permission
> class="org.apache.avalon.somepackage.AppShutdownViaBlockPermission" />
> </revoke>
>
> I've poked through examples in the JDK and it looks like things should
> be OK.
>
> Any other opinions?
Yep!
As noted in the thread over phoenix-dev, the addition of the operation
requestShutdown to BlockContext (as currently proposed) breaks the
component contract related to Contextualizable. A component receives a
Context object which is holder a keyed values. Adding behaviour breaks
potential for component portability.
There are alternative solutions such a component requesting a depedency
on a shutdown request handler which would be totally consistent eith the
component model. Another less portable solution would be expose a
shutdown request handler object via a context key - the component that
requires this functionality would get the handler and invoke a shutdown
request against the handler.
Cheers, Steve.
> - Paul
>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: shutdown phoenix gracefully
Posted by Paul Hammant <Pa...@yahoo.com>.
On Mon, 26 Feb 2002 07:17, Peter Donald wrote:
>On Mon, 25 Feb 2002 21:00, Paul Hammant wrote:
>
>
>>Peter,
>>
>>
>>
>>>>There is some JMX management stuff that I honestly don't know much about
>>>>(don't even know if its working or not). In principal it would provide
>>>>management access to Phoenix. Personally I would like to see a pluggable
>>>>controller so I can do things like remote CORBA based start-up/shutdown.
>>>>Umm, Pete .. we spoke about something like this a couple of months back.
>>>>Maybe its time to put it in place ?
>>>>
>>>>
>>>Maybe. It may be that the best thing to do for the moment is to add a
>>>
>>>void requestShutdown()
>>>
>>>
>>+1
>>
>>Could we have some params for that?
>>
>> Immediately | Delayed | Server App Only
>>
>>
>
>I see no need for delayed but Immediate + Server App Only == requestShutdown()
>
>
>
>
>>All Server Apps
>>
>>
>
>-1 One app should not be able to effect another app except via a management
>interface.
>
>
>
>>Also should it throw ShutdownVetoedException ? Should we have a segment
>>in environment.xml to indicate whether a server app plans to and is
>>allowed to use requestShutdown()?
>>
>>
>
>That may be an idea. Though it may be best to declare that the block is
>capable of calling requestShutdown(). I have contemplated having a similar
>thing for other services on BlockContext.
>
>For instance if no Block in application ever calls getBaseDirectory() then
>there is no need to install it to a directory.
>
requestShutdown();
--> we can't be accused of not thinking about this one carefully
(conversation started in Feb).
How difficult will it be to fit permissions (environment.xml) onto this
given multiple containers?
<revoke code-base="sar:SAR-INF/lib/*">
<permission
class="org.apache.avalon.somepackage.AppShutdownViaBlockPermission" />
</revoke>
I've poked through examples in the JDK and it looks like things should
be OK.
Any other opinions?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Peter Donald <pe...@apache.org>.
On Mon, 25 Feb 2002 21:00, Paul Hammant wrote:
> Peter,
>
> >>There is some JMX management stuff that I honestly don't know much about
> >>(don't even know if its working or not). In principal it would provide
> >>management access to Phoenix. Personally I would like to see a pluggable
> >>controller so I can do things like remote CORBA based start-up/shutdown.
> >>Umm, Pete .. we spoke about something like this a couple of months back.
> >>Maybe its time to put it in place ?
> >
> >Maybe. It may be that the best thing to do for the moment is to add a
> >
> >void requestShutdown()
>
> +1
>
> Could we have some params for that?
>
> Immediately | Delayed | Server App Only
I see no need for delayed but Immediate + Server App Only == requestShutdown()
> All Server Apps
-1 One app should not be able to effect another app except via a management
interface.
> Also should it throw ShutdownVetoedException ? Should we have a segment
> in environment.xml to indicate whether a server app plans to and is
> allowed to use requestShutdown()?
That may be an idea. Though it may be best to declare that the block is
capable of calling requestShutdown(). I have contemplated having a similar
thing for other services on BlockContext.
For instance if no Block in application ever calls getBaseDirectory() then
there is no need to install it to a directory.
--
Cheers,
Pete
------------------------------
Kitsch never goes out of style
------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>There is some JMX management stuff that I honestly don't know much about
>>(don't even know if its working or not). In principal it would provide
>>management access to Phoenix. Personally I would like to see a pluggable
>>controller so I can do things like remote CORBA based start-up/shutdown.
>>Umm, Pete .. we spoke about something like this a couple of months back.
>>Maybe its time to put it in place ?
>>
>
>Maybe. It may be that the best thing to do for the moment is to add a
>
>void requestShutdown()
>
+1
Could we have some params for that?
Immediately | Delayed | Server App Only | All Server Apps
Seem valid choices.
Also should it throw ShutdownVetoedException ? Should we have a segment
in environment.xml to indicate whether a server app plans to and is
allowed to use requestShutdown()?
>method to BlockContext which would request for that particular application to
>be shutdown. If there was no applications left in container then by default
>the whole container would shutdown.
>
>Alternatively you could expose the MBeanServer directly in the context and
>make it possible to get it via
>
>MBeanServer server = (MBeanServer)getBlockContext().get( "mbean.server" );
>
-0
>Both of these features should be marked experimental until further tested
>though.
>
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shutdown phoenix gracefully
Posted by Peter Donald <pe...@apache.org>.
On Mon, 25 Feb 2002 09:11, Stephen McConnell wrote:
> There is some JMX management stuff that I honestly don't know much about
> (don't even know if its working or not). In principal it would provide
> management access to Phoenix. Personally I would like to see a pluggable
> controller so I can do things like remote CORBA based start-up/shutdown.
> Umm, Pete .. we spoke about something like this a couple of months back.
> Maybe its time to put it in place ?
Maybe. It may be that the best thing to do for the moment is to add a
void requestShutdown()
method to BlockContext which would request for that particular application to
be shutdown. If there was no applications left in container then by default
the whole container would shutdown.
Alternatively you could expose the MBeanServer directly in the context and
make it possible to get it via
MBeanServer server = (MBeanServer)getBlockContext().get( "mbean.server" );
Both of these features should be marked experimental until further tested
though.
--
Cheers,
Pete
------------------------------------------------------
"If people are good only because they fear punishment,
and hope for reward, then we are a sorry lot indeed."
-Albert Einstein
------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: shutdown phoenix gracefully
Posted by Emperor <Da...@gmx.net>.
Hmmm...
>
> > And now another question. How can I shutdown phoenix from within a
> > block?
>
> Not possible (but read on).
>
But we need it in order to provide clean and flexible management.
> > How do I get the embeddor instance I need to shutdown?
>
> Check out the ApplicationListener. This provides access to
> SarMetaData and related BlockInfo structures. You can do
> some level of playing around here but only at the block and
> application level. Basically, you only have access to the
> block or application context so your application cannot
> interfere in another applications space.
>
> There is some JMX management stuff that I honestly don't know
> much about (don't even know if its working or not). In
> principal it would provide
> management access to Phoenix. Personally I would like to see
> a pluggable controller so I can do things like remote CORBA
> based start-up/shutdown. Umm, Pete .. we spoke about
> something like this a couple of months back.
> Maybe its time to put it in place ?
>
> Cheers, Steve.
>
Why don't extend the attempt made by the manager's release method? I
think it is a kind of reference counted self destruction of blocks,
isn't it? And thats all we need. When all blocks in a manager are
disposed it could notify the embeddor (or whatever else), which
shutdowns itself. So you could shutdown your app simply by calling
dispose on your apps top level component (clean), or by disposing the
component manager (dirty ;).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: shutdown phoenix gracefully
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Emperor [mailto:DarkEmperor@gmx.net]
> Sent: Sunday, 24 February, 2002 20:58
> To: avalon-dev@jakarta.apache.org
> Subject: shutdown phoenix gracefully
>
>
>
> Steve: thx for your very very useful posts!
No problem. But I think I'm going to let you down on the question
concerning phoenix shutdown.
> And now another question. How can I shutdown phoenix from within a
> block?
Not possible (but read on).
> How do I get the embeddor instance I need to shutdown?
Check out the ApplicationListener. This provides access to SarMetaData
and related BlockInfo structures. You can do some level of playing around
here but only at the block and application level. Basically, you only
have access to the block or application context so your application cannot
interfere in another applications space.
There is some JMX management stuff that I honestly don't know much about
(don't even know if its working or not). In principal it would provide
management access to Phoenix. Personally I would like to see a pluggable
controller so I can do things like remote CORBA based start-up/shutdown.
Umm, Pete .. we spoke about something like this a couple of months back.
Maybe its time to put it in place ?
Cheers, Steve.
> Each time I get deeper involved in avalon I could ask 10 more questions
> ;)
>
> Nils
>
>
>
> --
> 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>