Peter,
>>How about an Interface PersistableBlock that implemented the following
>>methods :-
>>
>> Object persist();
>> void unPersist(Object persistedForm);
>>
>>Phoenix, on shutdown, could persist the block. If built-in, the
>>unPersist method would come just before initialize() in terms of lifecycle;
>>
>
>I would prefer it not to be a kernel service.
>
OK, Conceded.
>>As a slight alternative, it could be a Cornerstone interface and a
>>separate block (with defautl impl). That block could, on stop(), invoke
>>the persist() method it it's dependancy. It could similarly invoke
>>unPersist for on start(). That default block could take a number of
>>configurations, including one that had a cron based automatic
>>persistence scheme.
>>
>
>Instead of doing it as dependencies how about instead using the newly added
>BlockListener. In fact it was these application wide non-lifecycle "aspects"
>that led to creation of BlockListener. Your code would look something like
>
OK, I've had an itch about BlockListener for a while in that it is not a
block (as far as I can see). Can it avail of configuration and
component-manager services?
>
>
>blockAdded
>
>The logic would be something like the followin
>
>class PersistantListener
>{
> private Persistor m_persistor;
> private ArrayList m_persistants = new ArrayList();
>
> void blockAdded( BlockEvent event )
> {
> final Block block = event.getBlock();
>
> if( block instanceof Persistant )
> {
> m_persistants.add( block );
> }
>
> if( null == m_persistor && block instanceof Persistor )
> {
> m_persistor = (Persistor)block;
> int size = m_persistants.size();
> for( int i = 0; i < size; i++ )
> {
> final Block other = (Block)m_persistants.get( i );
> m_persistor.load( (Persistant)other );
> }
> }
> else if( null != _m_persistor )
> {
> m_persistor.load( (Persistant)block );
> }
> }
>
> void blockRemoved()
> {
> //reverse above
> }
>}
>
>So in this case you would have a Persistor Block that persists all the other
>blocks that want it. We also have Persistent Blocks who want to be persisted.
>The above code will tell the Persistor about all the persistents in the .sar
>
>That work for you ?
>
Yes it would work, It could be inside the SAR app or outside I presume,
given the concern above. An Assembler's duty.
- Paul H
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
