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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
