Re: Architectural Question

[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

[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

[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>