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