You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/11/08 15:39:55 UTC
[Phoenix] Could blocks be persistable?
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;
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.
Thoughts?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>
>>You'll have to coach me dude, as to how to get Fede's Store for use.
>>
>
>Im not sure I understand. The Listener doesn't need to reference the Store.
>The listener should not include any logic at all. All it should be doing is
>registering the PersistentClient blocks with the PersistentServer block. The
>PersistentServer would then have a dependency on Store if thats how you chose
>to persist Blocks.
>
OK, so the listener is a delegate. It interoperate with other blocks,
one of which could be its server.
>
>The snippet of code I sent yesterday should work .. in theory. I will test it
>out practically tomorrow night. If I haven't explained it well enough by then
>I will send my code and see if that makes it easier (or worse) to understand.
>
I'll look at it again.
To recap our needs: A block persistor, if so configured, could be
actioned at startup and shutdown. It could also be configured in such a
way that it, on a timed basis, persists the block. It could also
respond to the block's own request for persistance.
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Peter Donald <do...@apache.org>.
On Mon, 12 Nov 2001 22:24, Paul Hammant wrote:
> Peter,
>
> >>and
> >>component-manager services?
> >
> >no. It gets it components via listening to events.
>
> You'll have to coach me dude, as to how to get Fede's Store for use.
Im not sure I understand. The Listener doesn't need to reference the Store.
The listener should not include any logic at all. All it should be doing is
registering the PersistentClient blocks with the PersistentServer block. The
PersistentServer would then have a dependency on Store if thats how you chose
to persist Blocks.
The snippet of code I sent yesterday should work .. in theory. I will test it
out practically tomorrow night. If I haven't explained it well enough by then
I will send my code and see if that makes it easier (or worse) to understand.
> >>>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.
> >
> >Im not sure what you mean outside a .sar ?
>
> In another sar. Does it listen to all block events in the machine, or
> just those in the same server app?
just those inside the same app.
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>and
>>component-manager services?
>>
>
>no. It gets it components via listening to events.
>
You'll have to coach me dude, as to how to get Fede's Store for use.
>>>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.
>>
>
>Im not sure what you mean outside a .sar ?
>
In another sar. Does it listen to all block events in the machine, or
just those in the same server app?
- PAul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Peter Donald <do...@apache.org>.
On Mon, 12 Nov 2001 22:11, Paul Hammant wrote:
> 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
yes.
>and
> component-manager services?
no. It gets it components via listening to events.
>
> >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.
Im not sure what you mean outside a .sar ?
--
Cheers,
Pete
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Peter Donald <do...@apache.org>.
On Fri, 9 Nov 2001 01:39, Paul Hammant wrote:
> 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.
> 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
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 ?
--
Cheers,
Pete
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Phoenix] Could blocks be persistable?
Posted by Mircea Toma <mi...@home.com>.
Hi,
> 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;
-1 ... I don't see this functionality as a Kernel service! Do you really
need to persist Blocks or just Components?
> 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.
Once the access to Phoenix level services is implemented (Deployer,
ConfigurationRepository ...) then maybe you can use the ObjectStore to store
block instances and later on load & add them to the Kernel.
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>