You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/06/01 14:24:57 UTC
LifeCycleHelper
Peter,
I'm trying to upgrade the Cornerstone connection package
(AbstractHandlerFactory & AbstractService) to be Serviceable as well as
Composable. Well actually I'm trying to upgrade JAMES to use
Serviceable instead of Composable. I felt I cannot ripple that
changeover into Cornerstone without knockon effects for other
Cornerstone using applications. So I am trying to make them dual mode.
In LifecycleHelper (Phoenix) there is the following block of code...
if( object instanceof Composable )
{
..
}
else if( object instanceof Serviceable )
.. meaning a thing cannot be both.
Could you offer some advice here ...?
Cheers,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Paul Hammant <Pa...@yahoo.com>.
Andrei,
>Hi,
>Paul, could you please post some example (or reference where to check for
>this) of how this can be done:
>
>
It is simple look for classes that use directory or extend
org.apache.avalon.cornerstone.services.connection.AbstractService.
Only JAMES has this concept. I am not sure why yet. With phoenix there
will be one impl of a 'thing' that could be got via compMgr. If James
requires multiple concurrent impls of the same thing, then it is
possibly right. James does this for IMAPServer, NNTPServer, POP3Server,
RemoteManager, SMTPServer. If they all have resitrations in
assembly.xml (they do), then it is possible (Ithink) to use conventional
phoenix driven (rather that home grown) compose() or service() resultion.
>>rather than letting Phoenix resolve things via assembly.xml
>>
>>
>
>i.e., if I understood you right, creating connection handler in other way
>than using cornerstone?
>
No, still use cornerstone, but let phoenix and assembly.xml do the
resultion of compsable, serviceable needs.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
Paul, could you please post some example (or reference where to check for
this) of how this can be done:
> rather than letting Phoenix resolve things via assembly.xml
i.e., if I understood you right, creating connection handler in other way
than using cornerstone?
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Paul Hammant" <Pa...@yahoo.com>
> Given that only James uses AbstractService direcly (rather than letting
> Phoenix resolve things via assembly.xml) could we switch over from
> Composable to Servicable it? I've checked all Avalon- prefixed depots
> as well as Cocoon, and there are no other uses of AbstractService in
> this way.
>
> I appreciate there might be external companies that do use Cornerstone
> in teh same way as James, but I think it is unlikely as it is a very
> specialized use that casuses this runtime bug.
AFAIK, Giacomo uses lots of Avalon stuff in his $ work.
I would suppose that he would be a good check for this or any other
important change...
just 2cents
--
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: LifeCycleHelper
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
Given that only James uses AbstractService direcly (rather than letting
Phoenix resolve things via assembly.xml) could we switch over from
Composable to Servicable it? I've checked all Avalon- prefixed depots
as well as Cocoon, and there are no other uses of AbstractService in
this way.
I appreciate there might be external companies that do use Cornerstone
in teh same way as James, but I think it is unlikely as it is a very
specialized use that casuses this runtime bug.
What do you think?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
Given that only James uses AbstractService direcly (rather than letting
Phoenix resolve things via assembly.xml) could we switch over from
Composable to Servicable it? I've checked all Avalon- prefixed depots
as well as Cocoon, and there are no other uses of AbstractService in
this way.
I appreciate there might be external companies that do use Cornerstone
in teh same way as James, but I think it is unlikely as it is a very
specialized use that casuses this runtime bug.
What do you think?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Peter Donald <pe...@apache.org>.
On Sat, 1 Jun 2002 23:56, Stephen McConnell wrote:
> Paul Hammant wrote:
> > Peter,
> >
> > I'm trying to upgrade the Cornerstone connection package
> > (AbstractHandlerFactory & AbstractService) to be Serviceable as well
> > as Composable. Well actually I'm trying to upgrade JAMES to use
> > Serviceable instead of Composable. I felt I cannot ripple that
> > changeover into Cornerstone without knockon effects for other
> > Cornerstone using applications. So I am trying to make them dual mode.
> >
> > In LifecycleHelper (Phoenix) there is the following block of code...
> >
> > if( object instanceof Composable )
> > {
> > ..
> > }
> > else if( object instanceof Serviceable )
> >
> > .. meaning a thing cannot be both.
> >
> > Could you offer some advice here ...?
>
> If the Phoenix LifecycleHelper reversed the order of assessment then you
> would be ok. Serviceable should take precedence over Composable. That
> would enable you to have an implementation that supports both
> Serviceable and Composable, but the following assemptions would be
> maintained - if an object implements Serviceable, then it will be
> serviced and will not be composed - but if it is not serviceable but
> supports composable, then it would be composed.
+1
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>
>> In LifecycleHelper (Phoenix) there is the following block of code...
>>
>> if( object instanceof Composable )
>> {
>> ..
>> }
>> else if( object instanceof Serviceable )
>>
>> .. meaning a thing cannot be both.
>>
>> Could you offer some advice here ...?
>
>
>
> If the Phoenix LifecycleHelper reversed the order of assessment then
> you would be ok. Serviceable should take precedence over Composable.
> That would enable you to have an implementation that supports both
> Serviceable and Composable, but the following assemptions would be
> maintained - if an object implements Serviceable, then it will be
> serviced and will not be composed - but if it is not serviceable but
> supports composable, then it would be composed.
Good suggestion. Then it is that or a non-backwards compatible switch
over to Serviceable from Composable for AbstractService. I've emailed
Giacomo as it has been suggested that he is a heavy user of such things.
The theory is that is Giacomo consents then there is no reason not to
just change it given there are no remaining direct usages in Apache CVS.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: LifeCycleHelper
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Peter,
>
> I'm trying to upgrade the Cornerstone connection package
> (AbstractHandlerFactory & AbstractService) to be Serviceable as well
> as Composable. Well actually I'm trying to upgrade JAMES to use
> Serviceable instead of Composable. I felt I cannot ripple that
> changeover into Cornerstone without knockon effects for other
> Cornerstone using applications. So I am trying to make them dual mode.
>
> In LifecycleHelper (Phoenix) there is the following block of code...
>
> if( object instanceof Composable )
> {
> ..
> }
> else if( object instanceof Serviceable )
>
> .. meaning a thing cannot be both.
>
> Could you offer some advice here ...?
If the Phoenix LifecycleHelper reversed the order of assessment then you
would be ok. Serviceable should take precedence over Composable. That
would enable you to have an implementation that supports both
Serviceable and Composable, but the following assemptions would be
maintained - if an object implements Serviceable, then it will be
serviced and will not be composed - but if it is not serviceable but
supports composable, then it would be composed.
Cheers, Steve.
--
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>