[phoenix] classloaders in environment.xml

[Adam Murdoch <ad...@apache.org>]

Hi,

I'm just writing up some docs for environment.xml, and had a few questions 
about the <classloaders> element (an excellent feature, btw).

- <entry> and <fileset> can't refer to locations outside the sar, whereas 
<policy> entries can.  Is this intentional, or just not implemented?  Or is 
this only really meaningful when deploying from, say, an xml descriptor (a 
todo item), instead of a sar?

- There's no property expansion for <entry> and <fileset>, like there is for 
<policy> entries.  Is this because of the above, or just not implemented?

- Order is lost across <entry>, <fileset>, and <extension> elements.  The 
classloader builder handles all the <entry>s, then all the <fileset>s, and 
then all the <extension>s.  Would it not be better to preserve the ordering 
of these elements?

- Why bother declaring predefined classloaders?

- Why bother with <join> elements?  Why not allow <classloader> to take 
multiple parents?

- Is it too late to change any of this stuff, wrt backwards compat?

-- 
Adam

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] classloaders in environment.xml

[Peter Donald <pe...@realityforge.org>]

On Fri, 20 Dec 2002 12:49, Adam Murdoch wrote:
> > partially intentional. The fact that <policy> can refer to things outside
> > the .sar file is purely a historical artefact. It should not be able to
> > but it can atm so we leave it as is.
>
> Ok.  Is this worth adding to the docs as a suggestion?

yep.

> Let me just clarify:
>
> - When deploying from sar, <policy> and <classloader> should only refer to
> contents of sar (but due to backwards compat, <policy> has to be able to
> refer to anything).
> - When deploying from xml, <policy> and <classloader> can refer to
> anything.

yep.

> A fantastic idea.  Sounds like heaps more fun than writing up
> environment.xml docs :)

:)

> Sure, but it's certainly not context-free to the user. 
> It's a phoenix config file.  Phoenix provides a fixed set 
> of predefineds.  

atm - not in the future.

> All the classloader stuff is in a single XML
> element with a handful of entries - the user doesn't need any more info
> than where the bad name is, and what the set of available predefineds are. 
> Tell them that in the error message.

that was in the original design/implementation which we moved away from.

-- 
Cheers,

Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of, 
he always declares that it is his duty.
					George Bernard Shaw 
-----------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] classloaders in environment.xml

[Adam Murdoch <ad...@apache.org>]

On Thu, 19 Dec 2002 03:53 pm, Peter Donald wrote:
> On Thu, 19 Dec 2002 15:45, Adam Murdoch wrote:
> > - <entry> and <fileset> can't refer to locations outside the sar, whereas
> > <policy> entries can.  Is this intentional, or just not implemented?
>
> partially intentional. The fact that <policy> can refer to things outside
> the .sar file is purely a historical artefact. It should not be able to but
> it can atm so we leave it as is.

Ok.  Is this worth adding to the docs as a suggestion?

> >  Or is
> > this only really meaningful when deploying from, say, an xml descriptor
> > (a todo item), instead of a sar?
>
> Once xml descriptors are deployable from then both <policy> and
> <classloader> should be able to refer to anything defined anywhere in
> deployment.

Let me just clarify:

- When deploying from sar, <policy> and <classloader> should only refer to 
contents of sar (but due to backwards compat, <policy> has to be able to 
refer to anything).
- When deploying from xml, <policy> and <classloader> can refer to anything.

> > - There's no property expansion for <entry> and <fileset>, like there is
> > for <policy> entries.  Is this because of the above, or just not
> > implemented?
>
> <policy/> expansion is a historical artefact. Eventually I think we should
> "interpret" the whole set of configuration files using jelly or something
> similar and thus evaluate all properties. It has been suggested a few times
> but no one has coded up.

A fantastic idea.  Sounds like heaps more fun than writing up environment.xml 
docs :)

> > - Order is lost across <entry>, <fileset>, and <extension> elements.  The
> > classloader builder handles all the <entry>s, then all the <fileset>s,
> > and then all the <extension>s.  Would it not be better to preserve the
> > ordering of these elements?
>
> Partially intentional. Order should not be used in this way as every
> element in classloader should be exclusive and non-overlapping.

Should be.  It's not a big deal, but I'd like to be able to provide a 
defensive classpath - ie, put the <extension>s and <entry>s early in the 
classpath, and the <fileset>s later.  So that if someone plonks an 
incompatible duplicate in one of the <fileset> dirs, it's not going to cause 
weird classloader problems.

> > - Why bother declaring predefined classloaders?
>
> Because then you can validate the configuration in a context free manner.

Sure, but it's certainly not context-free to the user.  It's a phoenix config 
file.  Phoenix provides a fixed set of predefineds.  Why bother declaring 
them?

> The plan was to eventually refactor phoenix internals enough that
> alternative predefeind loaders could be added.

You still don't need to declare them.  If there's a reference a classloader 
that is not defined as part of <classloaders>, and is not a predefined, then 
tell the user that.  All the classloader stuff is in a single XML element 
with a handful of entries - the user doesn't need any more info than where 
the bad name is, and what the set of available predefineds are.  Tell them 
that in the error message.

-- 
Adam

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [phoenix] classloaders in environment.xml

[Peter Donald <pe...@realityforge.org>]

On Thu, 19 Dec 2002 15:45, Adam Murdoch wrote:
> - <entry> and <fileset> can't refer to locations outside the sar, whereas
> <policy> entries can.  Is this intentional, or just not implemented?

partially intentional. The fact that <policy> can refer to things outside the 
.sar file is purely a historical artefact. It should not be able to but it 
can atm so we leave it as is.

>  Or is
> this only really meaningful when deploying from, say, an xml descriptor (a
> todo item), instead of a sar?

Once xml descriptors are deployable from then both <policy> and <classloader> 
should be able to refer to anything defined anywhere in deployment.
>
> - There's no property expansion for <entry> and <fileset>, like there is
> for <policy> entries.  Is this because of the above, or just not
> implemented?

<policy/> expansion is a historical artefact. Eventually I think we should 
"interpret" the whole set of configuration files using jelly or something 
similar and thus evaluate all properties. It has been suggested a few times 
but no one has coded up.

> - Order is lost across <entry>, <fileset>, and <extension> elements.  The
> classloader builder handles all the <entry>s, then all the <fileset>s, and
> then all the <extension>s.  Would it not be better to preserve the ordering
> of these elements?

Partially intentional. Order should not be used in this way as every element 
in classloader should be exclusive and non-overlapping.

> - Why bother declaring predefined classloaders?

Because then you can validate the configuration in a context free manner. The 
plan was to eventually refactor phoenix internals enough that alternative 
predefeind loaders could be added.

> - Why bother with <join> elements?  Why not allow <classloader> to take
> multiple parents?

simplicity for user. May mean slightly more work but forces them to think 
about them specially which is important as they are special.

> - Is it too late to change any of this stuff, wrt backwards compat?

The policy stuff is fairly fixed and we can only deprecate or do forward 
compatible changes. Even if this means doing 

if( version="1.0" ) do old stuff
else if( version="1.1" ) do new stuff
else throw Error();

The ClassLoader stuff is open to changes in most cases. Fire away.

-- 
Cheers,

Peter Donald
--------------------------------------------------
 The fact that nobody understands you doesn't 
 mean you're an artist.
--------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>