Re: [phoenix] classloaders in environment.xml

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