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 2002/02/24 14:39:14 UTC
BlockContext.getBaseDirectory();
Folks, Peter,
The following BlockContext method..
File getBaseDirectory();
..is in wide use.
I am thinking of something similar for EOB, in a similar class called
BeanContext (extends Context). In retrospect are we happy with this or
would a separate IoC interface been a good idea for blocks requiring
access to their root directory?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockContext.getBaseDirectory();
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Monday, 25 February, 2002 15:34
> To: Avalon Developers List
> Subject: Re: BlockContext.getBaseDirectory();
>
>
> Stephen,
>
> >>>>>>2) File dir = (File) context.get("phoenix-dir:server-app");
> >>>>>>
> >>>>>try using the string "app.dir" or something and it should work ;)
> >>>>>
> >>>>Doh!
> >>>>
> >>>But its nasty - anyone can change "app.dir" because its the value of
> >>>a constant. A better solution is needed!
> >>>
> >>But it is defined in an interface, and therefore immutable?
> >>
> >
> >The constant APP_HOME_DIR is defined in the interface - I can change
> >the "app.dir" string value to anything I want without breaking the
> >interface.
> >
> Not quite sure what you are talking about here. Trying to modify it
> gives the following at compile time:
>
> "cannot assign a value to final variable APP_HOME_DIR"
Sure.
> Are you trying to say that ....
>
> Object o = get("dsjhsfhlhjdsflkahjdsf");
>
> could happen? If yes, then how is the exception unpalatable?
What I'm saying is that the string "app.dir" is not exposed in the
interface. The string could change (by someone changing the source
code a year from now and everyone has forgotten about external
references to the implementation string. The interface would still
be good, but your reference to "app.dir" would break - because the
usage of the "app.dir" key circumvents the interface and any compile
time checking. The only way you can safely use the string "app.dir"
is if there is an Avalon wide directory of reserved names that is
actively maintained.
Steve.
> - Paul
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>>>>>2) File dir = (File) context.get("phoenix-dir:server-app");
>>>>>>
>>>>>try using the string "app.dir" or something and it should work ;)
>>>>>
>>>>Doh!
>>>>
>>>But its nasty - anyone can change "app.dir" because its the value of
>>>a constant. A better solution is needed!
>>>
>>But it is defined in an interface, and therefore immutable?
>>
>
>The constant APP_HOME_DIR is defined in the interface - I can change
>the "app.dir" string value to anything I want without breaking the
>interface.
>
Not quite sure what you are talking about here. Trying to modify it
gives the following at compile time:
"cannot assign a value to final variable APP_HOME_DIR"
Are you trying to say that ....
Object o = get("dsjhsfhlhjdsflkahjdsf");
could happen? If yes, then how is the exception unpalatable?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockContext.getBaseDirectory();
Posted by Stephen McConnell <mc...@apache.org>.
> Stephen,
>
> >>>>2) File dir = (File) context.get("phoenix-dir:server-app");
> >>>>
> >>>try using the string "app.dir" or something and it should work ;)
> >>>
> >>Doh!
> >>
> >
> >But its nasty - anyone can change "app.dir" because its the value of
> >a constant. A better solution is needed!
> >
> But it is defined in an interface, and therefore immutable?
>
The constant APP_HOME_DIR is defined in the interface - I can change
the "app.dir" string value to anything I want without breaking the
interface.
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>>>2) File dir = (File) context.get("phoenix-dir:server-app");
>>>>
>>>try using the string "app.dir" or something and it should work ;)
>>>
>>Doh!
>>
>
>But its nasty - anyone can change "app.dir" because its the value of
>a constant. A better solution is needed!
>
But it is defined in an interface, and therefore immutable?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Peter Donald <pe...@apache.org>.
On Mon, 25 Feb 2002 23:37, Stephen McConnell wrote:
> > -----Original Message-----
> > From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> > Sent: Sunday, 24 February, 2002 23:10
> > To: Avalon Developers List
> > Subject: Re: BlockContext.getBaseDirectory();
> >
> >
> > Peter,
> >
> > >>2) File dir = (File) context.get("phoenix-dir:server-app");
> > >
> > >try using the string "app.dir" or something and it should work ;)
> >
> > Doh!
>
> But its nasty - anyone can change "app.dir" because its the value of
> a constant. A better solution is needed!
I have no idea what you mean?
--
Cheers,
Pete
--------------------------------------------------------------
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it" -- Richard Feynman
--------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockContext.getBaseDirectory();
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Sunday, 24 February, 2002 23:10
> To: Avalon Developers List
> Subject: Re: BlockContext.getBaseDirectory();
>
>
> Peter,
>
> >>
> >>2) File dir = (File) context.get("phoenix-dir:server-app");
> >>
> >
> >try using the string "app.dir" or something and it should work ;)
> >
> Doh!
>
But its nasty - anyone can change "app.dir" because its the value of
a constant. A better solution is needed!
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>
>>2) File dir = (File) context.get("phoenix-dir:server-app");
>>
>
>try using the string "app.dir" or something and it should work ;)
>
Doh!
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Peter Donald <pe...@apache.org>.
On Mon, 25 Feb 2002 01:47, Paul Hammant wrote:
> I wonder if there are not several distict needs for directory pointers:
>
> 1) True temp dir for block
> 2) True temp dir shared for all blocks in sar (like now)
> 3) Some provision for hosted comps to have their own dir space.
Thats an interesting idea.
> Given that Context has 'Object get(String name)' could we superceed with
> something like :
>
> 1) File dir = (File) context.get("phoenix-dir:block");
> 2) File dir = (File) context.get("phoenix-dir:server-app");
> 3) File dir = (File) context.get("phoenix-hostedcomp-dir:" +
> hc.getID().getString());
try using the string "app.dir" or something and it should work ;)
--
Cheers,
Pete
----------------------------------
"Don't play dumb with me.
I happen to be an expert at that"
- Maxwell Smart
----------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>I am not so sure. Look at the source for BlockContext and it looks like
>>the only non deprecated method.
>>
>
>I've been doing a bunch of stuff to do with Serviceable meta-info and
>related stuff. I'm accessing Xxxxx.getBaseDirectory() as the means
>to establish the base directory from which relative file references in
>configurations can be resolved.
>
Me too.
>>Thh reason I ask is that for full security a policy should be set for
>>each classloader that may access the file system. A hacker block (bean
>>in my case) could navigate from there to predictable points in the
>>system without a security policy.
>>
>>I wonder if there are not several distict needs for directory pointers:
>>
>>1) True temp dir for block
>>2) True temp dir shared for all blocks in sar (like now)
>>3) Some provision for hosted comps to have their own dir space.
>>
>>Given that Context has 'Object get(String name)' could we superceed with
>>something like :
>>
>>1) File dir = (File) context.get("phoenix-dir:block");
>>2) File dir = (File) context.get("phoenix-dir:server-app");
>>3) File dir = (File) context.get("phoenix-hostedcomp-dir:" +
>>hc.getID().getString());
>>
>
>I would prefer something like:
>
> public DirectoryContext extends Context
> {
> File getDirectory() throws ContextException
> }
>
> public BlockContext extends DirectoryContext
> {
> ...
> }
>
>BlockContext then makes sense under the Phoenix package.
>DirectoryContext is a general utility interface.
>
Maybe, but would it fail the backwards compatability rules?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockContext.getBaseDirectory();
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>
> Stephen,
>
> >Interesting that you mentioned this. In some of the code we
> >are using reflection to access this method so that we don't
> >create a dependency on the Phoenix client package. I would
> >really like to see this inside something like a framework
> >utility package.
> >
> I am not so sure. Look at the source for BlockContext and it looks like
> the only non deprecated method.
I've been doing a bunch of stuff to do with Serviceable meta-info and
related stuff. I'm accessing Xxxxx.getBaseDirectory() as the means
to establish the base directory from which relative file references in
configurations can be resolved.
> Th reason I ask is that for full security a policy should be set for
> each classloader that may access the file system. A hacker block (bean
> in my case) could navigate from there to predictable points in the
> system without a security policy.
>
> I wonder if there are not several distict needs for directory pointers:
>
> 1) True temp dir for block
> 2) True temp dir shared for all blocks in sar (like now)
> 3) Some provision for hosted comps to have their own dir space.
>
> Given that Context has 'Object get(String name)' could we superceed with
> something like :
>
> 1) File dir = (File) context.get("phoenix-dir:block");
> 2) File dir = (File) context.get("phoenix-dir:server-app");
> 3) File dir = (File) context.get("phoenix-hostedcomp-dir:" +
> hc.getID().getString());
I would prefer something like:
public DirectoryContext extends Context
{
File getDirectory() throws ContextException
}
public BlockContext extends DirectoryContext
{
...
}
BlockContext then makes sense under the Phoenix package.
DirectoryContext is a general utility interface.
Steve.
> With a design like that you have no dependancy on Phoenix-client. (2)
> would of course be mapped to getBaseDirectory() as at present.
>
> - Paul
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: BlockContext.getBaseDirectory();
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>Interesting that you mentioned this. In some of the code we
>are using reflection to access this method so that we don't
>create a dependency on the Phoenix client package. I would
>really like to see this inside something like a framework
>utility package.
>
I am not so sure. Look at the source for BlockContext and it looks like
the only non deprecated method.
Th reason I ask is that for full security a policy should be set for
each classloader that may access the file system. A hacker block (bean
in my case) could navigate from there to predictable points in the
system without a security policy.
I wonder if there are not several distict needs for directory pointers:
1) True temp dir for block
2) True temp dir shared for all blocks in sar (like now)
3) Some provision for hosted comps to have their own dir space.
Given that Context has 'Object get(String name)' could we superceed with
something like :
1) File dir = (File) context.get("phoenix-dir:block");
2) File dir = (File) context.get("phoenix-dir:server-app");
3) File dir = (File) context.get("phoenix-hostedcomp-dir:" +
hc.getID().getString());
With a design like that you have no dependancy on Phoenix-client. (2)
would of course be mapped to getBaseDirectory() as at present.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: BlockContext.getBaseDirectory();
Posted by Stephen McConnell <mc...@apache.org>.
Paul:
Interesting that you mentioned this. In some of the code we
are using reflection to access this method so that we don't
create a dependency on the Phoenix client package. I would
really like to see this inside something like a framework
utility package.
Cheers, Steve.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Sunday, 24 February, 2002 14:39
> To: Avalon Development
> Subject: BlockContext.getBaseDirectory();
>
>
> Folks, Peter,
>
> The following BlockContext method..
> File getBaseDirectory();
> ..is in wide use.
>
> I am thinking of something similar for EOB, in a similar class called
> BeanContext (extends Context). In retrospect are we happy with this or
> would a separate IoC interface been a good idea for blocks requiring
> access to their root directory?
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>