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 Steve Osselton <st...@prismtechnologies.com> on 2002/07/18 08:21:51 UTC

Architectural Question

Hi Guys,

We're starting to use Avalon and have components that require persistent
initialization (creation of table/entries) and destruction (removal of said
tables/entries). I was wondering why this is not supported as a framework
activity interface? I was expecting so see something like a 'Persistent' interface
with 'create' and 'destroy' operations.

Cheers Steve.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Steve Osselton <st...@prismtechnologies.com>.
Hi Leo,

Leo Simons wrote:

>>We're starting to use Avalon
> 
> 
> you like it so far?

Yes. It is the sort of thing we have done with our own framework, but more
advanced and formalized. I like the general model and separation of concerns and
belive it to be well suited for supporting a CORBA server framework

> 
>>and have components that require persistent
>>initialization (creation of table/entries) and destruction (removal of said
>>tables/entries). I was wondering why this is not supported as a framework
>>activity interface?
> 
> 
> there hasn't been enough need, I guess...besides it would make the
> framework considerably more complex. Everything specified as an
> 'official' lifecycle interface is something that needs to work in every
> application. Since database portability is JNP (just not possible), we'd
> have to include a database activation/passivation abstraction layer
> within the framework as well.

I wasn't actually thinking of how a component actually did it's own persistence,
simply of modelling state transition operations in a simple interface. I was
assuming that a persistent component would itself uses another configured component
for persistence but that this mechanism would still in effect be coded within
the persistent component (typically calls to a database via JDBC).

You've given me a few more things to look at. I'm still coming up to speed on
some of this stuff :-)

Thanks Steve.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Steve Osselton <st...@prismtechnologies.com>.
Hi Leo,

Leo Simons wrote:

>>We're starting to use Avalon
> 
> 
> you like it so far?

Yes. It is the sort of thing we have done with our own framework, but more
advanced and formalized. I like the general model and separation of concerns and
belive it to be well suited for supporting a CORBA server framework

> 
>>and have components that require persistent
>>initialization (creation of table/entries) and destruction (removal of said
>>tables/entries). I was wondering why this is not supported as a framework
>>activity interface?
> 
> 
> there hasn't been enough need, I guess...besides it would make the
> framework considerably more complex. Everything specified as an
> 'official' lifecycle interface is something that needs to work in every
> application. Since database portability is JNP (just not possible), we'd
> have to include a database activation/passivation abstraction layer
> within the framework as well.

I wasn't actually thinking of how a component actually did it's own persistence,
simply of modelling state transition operations in a simple interface. I was
assuming that a persistent component would itself uses another configured component
for persistence but that this mechanism would still in effect be coded within
the persistent component (typically calls to a database via JDBC).

You've given me a few more things to look at. I'm still coming up to speed on
some of this stuff :-)

Thanks Steve.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Leo Simons <le...@apache.org>.
On Thu, 2002-07-18 at 08:21, Steve Osselton wrote:
> Hi Guys,

hi!

> We're starting to use Avalon

you like it so far?

> and have components that require persistent
> initialization (creation of table/entries) and destruction (removal of said
> tables/entries). I was wondering why this is not supported as a framework
> activity interface?

there hasn't been enough need, I guess...besides it would make the
framework considerably more complex. Everything specified as an
'official' lifecycle interface is something that needs to work in every
application. Since database portability is JNP (just not possible), we'd
have to include a database activation/passivation abstraction layer
within the framework as well.

Also, your persistence needs may exceed the scope of your avalon
container. The idea of the lifecycle is that its methods are all called
during a single container 'run'.

I would suggest you make your persistence layer/service into a
block/component which all your other components (that need persistence)
depend on:

service( ServiceManager sm )
{
	m_store = (PersistenceStore)sm.lookup( PersistenceStore.ROLE );
}

initialize()
{
	m_store.create( this );
}

dispose()
{
	m_store.destroy( this );
}

that's "the easiest thing that could possibly work".

- There has been talk of adding a Persistable interface (Berin Loritsch
took a stab at it, it is in the jakarta-avalon CVS under /src/proposal),
but that code is still pre-alpha.

- Fortress has been recently modified to support an extensible lifecycle
(you can basically add the Persistable interface yourself as a
'framework extension'), this is still alpha code

- there is some Persistence code in both cornerstone and excalibur (I
think); I'm not sure what the status of that code is; haven't use it
myself.

I'm forwarding this to the general avalon-dev list as this discussion
pertains to more than just phoenix.

regards,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Peter Royal <pr...@apache.org>.
On Thursday 18 July 2002 12:58 pm, Steve Osselton wrote:
> developers guide which seemed very big on the separation of concerns which
> is why I though a new activity interface might be appropriate.

Very understandable :)

> Currently we are moving to use the framework classes with our own CORBA
> container. We are doing this as we are in effect migrating an existing
> system which we will probably complete in a number of stages. I'll have a
> look at Fortress to see what it offers.

Also check out
http://marc.theaimsgroup.com/?l=avalon-dev&m=102615784630191&w=2

Which was a proposal by Berin for a "Persistable" lifecycle interface.
-pete


-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Steve Osselton <st...@prismtechnologies.com>.
Hi Peter,

I agree that Initializable are Disposable are currently the places where this
functionality can be bolted in. However I think that conceptually these are different
to persistent creation/destruction. I was reading the developers guide which seemed
very big on the separation of concerns which is why I though a new activity
interface might be appropriate.

Currently we are moving to use the framework classes with our own CORBA container.
We are doing this as we are in effect migrating an existing system which we will
probably complete in a number of stages. I'll have a look at Fortress to see what
it offers.

Cheers Steve.

Peter Royal wrote:
> On Thursday 18 July 2002 02:21 am, Steve Osselton wrote:
> 
>>We're starting to use Avalon and have components that require persistent
>>initialization (creation of table/entries) and destruction (removal of said
>>tables/entries). I was wondering why this is not supported as a framework
>>activity interface? I was expecting so see something like a 'Persistent'
>>interface with 'create' and 'destroy' operations.
> 
> 
> Unfortunately I haven't been around long enough to give a good answer on why 
> there is nothing akin to 'Persistent', other than it was never needed by 
> everyone and thus never included in the core framework.
> 
> With that said, I would recommend using Initializable and Disposable to handle 
> your persistent needs.
> 
> Also, what container are you using? Fortress now has support for an extensible 
> lifecycle, http://jakarta.apache.org/avalon/excalibur/fortress/features.html 
> and 
> http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/fortress/src/xdocs/lifecycle-extensions.xml?rev=1.2&content-type=text/vnd.viewcvs-markup 
> (I don't think its made it to the site yet).
> -pete
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Peter Royal <pr...@apache.org>.
On Thursday 18 July 2002 02:21 am, Steve Osselton wrote:
> We're starting to use Avalon and have components that require persistent
> initialization (creation of table/entries) and destruction (removal of said
> tables/entries). I was wondering why this is not supported as a framework
> activity interface? I was expecting so see something like a 'Persistent'
> interface with 'create' and 'destroy' operations.

Unfortunately I haven't been around long enough to give a good answer on why 
there is nothing akin to 'Persistent', other than it was never needed by 
everyone and thus never included in the core framework.

With that said, I would recommend using Initializable and Disposable to handle 
your persistent needs.

Also, what container are you using? Fortress now has support for an extensible 
lifecycle, http://jakarta.apache.org/avalon/excalibur/fortress/features.html 
and 
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/fortress/src/xdocs/lifecycle-extensions.xml?rev=1.2&content-type=text/vnd.viewcvs-markup 
(I don't think its made it to the site yet).
-pete

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Architectural Question

Posted by Leo Simons <le...@apache.org>.
On Thu, 2002-07-18 at 08:21, Steve Osselton wrote:
> Hi Guys,

hi!

> We're starting to use Avalon

you like it so far?

> and have components that require persistent
> initialization (creation of table/entries) and destruction (removal of said
> tables/entries). I was wondering why this is not supported as a framework
> activity interface?

there hasn't been enough need, I guess...besides it would make the
framework considerably more complex. Everything specified as an
'official' lifecycle interface is something that needs to work in every
application. Since database portability is JNP (just not possible), we'd
have to include a database activation/passivation abstraction layer
within the framework as well.

Also, your persistence needs may exceed the scope of your avalon
container. The idea of the lifecycle is that its methods are all called
during a single container 'run'.

I would suggest you make your persistence layer/service into a
block/component which all your other components (that need persistence)
depend on:

service( ServiceManager sm )
{
	m_store = (PersistenceStore)sm.lookup( PersistenceStore.ROLE );
}

initialize()
{
	m_store.create( this );
}

dispose()
{
	m_store.destroy( this );
}

that's "the easiest thing that could possibly work".

- There has been talk of adding a Persistable interface (Berin Loritsch
took a stab at it, it is in the jakarta-avalon CVS under /src/proposal),
but that code is still pre-alpha.

- Fortress has been recently modified to support an extensible lifecycle
(you can basically add the Persistable interface yourself as a
'framework extension'), this is still alpha code

- there is some Persistence code in both cornerstone and excalibur (I
think); I'm not sure what the status of that code is; haven't use it
myself.

I'm forwarding this to the general avalon-dev list as this discussion
pertains to more than just phoenix.

regards,

- Leo



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>