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/12/12 11:05:18 UTC
Proposed BlockContext
Folks,
(sorry if redundant, it's just that I have lost a weeks worth of list
mail upon return from Vacation)
//Object getProxy();
Like it. Mostly for use in a block for passing deeper to something that
is service aware, but that you want to hide impl from .
Like hosted components I guess. Maillets, FtpLets, but not servlets (as
Sun defined the interface for that one).
//Object getProxy( Object other );
Is there not an Excalibur DynProxy class for this?
//Object getProxy( Object other, Class[] interfaces );
Ditto.
//InputStream getResourceAsStream( String name );
This is for when we get the Not-unpacked SAR file working again?
//ClassLoader getClassLoader( String name );
We'd hint that coders should get their name from configuration and not
hard code, yes?
Could we extend this with a Veto type exception? I think that some apps
might be so dynamic that they might try get a classloader they should
not have.... (1) NamedClassLoaderException,
UnknownNamedClassLoaderException extends (1),
UnAuthorizedNamedClassLoaderException extends (1).
Maybe we also need String[] getClassLoaderNames() for those highly
adaptive "services explorer" blocks.
//MBeanServer getMBeanServer();
Not really an area I have a strong experience of.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposed BlockContext
Posted by Peter Donald <pe...@apache.org>.
On Thu, 13 Dec 2001 10:48, Paul Hammant wrote:
> Peter,
>
> >>>The problem is that means that the Block has to manage when to
> >>> invalidate the proxy. If it is done via BlockContext then Phoenix can
> >>> manage when the proxies are invalidated and thus force it to
> >>> invalidate at block shutdown.
> >>
> >>True, but if it is using the proxy internally, then GC will do yes?
> >
> >Not while it is still referenced somewhere else. The main reason I want to
> >use this is to stop people using objects after their creator has been
> >shutdown. These other people will still be referencing these objects and
> > thus wont be GCed
>
> But if the alternative was to ask the coder to nullify or undo proxy
> during stop() or destruct() methods for a block they it is just
> equivalet to a massice tree being GC'd?
They could do that if they wanted but it requires that the programmers be
fairly aware of the uses of these sorts of things. I would prefer that the
container automagically did it for them. Reduces the likelihood of errors
creeping in.
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposed BlockContext
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>>The problem is that means that the Block has to manage when to invalidate
>>>the proxy. If it is done via BlockContext then Phoenix can manage when
>>>the proxies are invalidated and thus force it to invalidate at block
>>>shutdown.
>>>
>>True, but if it is using the proxy internally, then GC will do yes?
>>
>
>Not while it is still referenced somewhere else. The main reason I want to
>use this is to stop people using objects after their creator has been
>shutdown. These other people will still be referencing these objects and thus
>wont be GCed
>
But if the alternative was to ask the coder to nullify or undo proxy
during stop() or destruct() methods for a block they it is just
equivalet to a massice tree being GC'd?
However if you are convinced.....
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposed BlockContext
Posted by Peter Donald <pe...@apache.org>.
On Thu, 13 Dec 2001 05:16, Paul Hammant wrote:
> Peter,
>
> >>//Object getProxy( Object other );
> >>
> >>Is there not an Excalibur DynProxy class for this?
> >
> >The problem is that means that the Block has to manage when to invalidate
> > the proxy. If it is done via BlockContext then Phoenix can manage when
> > the proxies are invalidated and thus force it to invalidate at block
> > shutdown.
>
> True, but if it is using the proxy internally, then GC will do yes?
Not while it is still referenced somewhere else. The main reason I want to
use this is to stop people using objects after their creator has been
shutdown. These other people will still be referencing these objects and thus
wont be GCed
> >Thats an idea ... need time to gestate.
>
> Phase 2 then.
>
> We also have to get rid of deprecations I think.
Well as soon as I get JMX closer to being finished ... ;)
--
Cheers,
Pete
-------------------------------------------------
We should take care not to make the intellect our
god; it has, of course, powerful muscles, but no
personality.
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposed BlockContext
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>//Object getProxy( Object other );
>>
>>Is there not an Excalibur DynProxy class for this?
>>
>
>The problem is that means that the Block has to manage when to invalidate the
>proxy. If it is done via BlockContext then Phoenix can manage when the
>proxies are invalidated and thus force it to invalidate at block shutdown.
>
True, but if it is using the proxy internally, then GC will do yes?
>> //InputStream getResourceAsStream( String name );
>>
>>This is for when we get the Not-unpacked SAR file working again?
>>
>
>partially. I have some other thoughts on doing this and have designed a
>fairly comprehensive system - Essentially you mark blocks as needing
>filesystem expanded (or at all) - if no blocks need filesystem expanded then
>can optionally not expand and can even run it without a home directory if no
>file access is needed..
>
Sounds good.
>> //ClassLoader getClassLoader( String name );
>>
>>We'd hint that coders should get their name from configuration and not
>>hard code, yes?
>>
>
>no idea. Still thinking about it.
>
I think it is OK, especially if the docs suggest some form of unique
namespace for the name.
>>Maybe we also need String[] getClassLoaderNames() for those highly
>>adaptive "services explorer" blocks.
>>
>
>Thats an idea ... need time to gestate.
>
Phase 2 then.
We also have to get rid of deprecations I think.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposed BlockContext
Posted by Peter Donald <pe...@apache.org>.
On Wed, 12 Dec 2001 21:05, Paul Hammant wrote:
> Folks,
>
> (sorry if redundant, it's just that I have lost a weeks worth of list
> mail upon return from Vacation)
>
> //Object getProxy();
>
> Like it. Mostly for use in a block for passing deeper to something that
> is service aware, but that you want to hide impl from .
> Like hosted components I guess. Maillets, FtpLets, but not servlets (as
> Sun defined the interface for that one).
>
> //Object getProxy( Object other );
>
> Is there not an Excalibur DynProxy class for this?
The problem is that means that the Block has to manage when to invalidate the
proxy. If it is done via BlockContext then Phoenix can manage when the
proxies are invalidated and thus force it to invalidate at block shutdown.
> //InputStream getResourceAsStream( String name );
>
> This is for when we get the Not-unpacked SAR file working again?
partially. I have some other thoughts on doing this and have designed a
fairly comprehensive system - Essentially you mark blocks as needing
filesystem expanded (or at all) - if no blocks need filesystem expanded then
can optionally not expand and can even run it without a home directory if no
file access is needed..
> //ClassLoader getClassLoader( String name );
>
> We'd hint that coders should get their name from configuration and not
> hard code, yes?
no idea. Still thinking about it.
> Maybe we also need String[] getClassLoaderNames() for those highly
> adaptive "services explorer" blocks.
Thats an idea ... need time to gestate.
--
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>