The main issue of t8 is it breaks some scanning features when relying on
URLClassLoader (getURLs()), not perfect but common in libs...
Le 23 sept. 2013 19:00, "Mark Thomas" <ma...@apache.org> a écrit :

> On 23/09/2013 09:08, Rainer Jung wrote:
> > On 23.09.2013 17:27, Mark Thomas wrote:
> >> I've mentioned on a couple of different threads that refactoring how the
> >> class loader accesses resources was on my TODO list. I haven't done any
> >> implementation yet but I have some ideas that I wanted to get some
> >> feedback on before I start work.
> >>
> >> The things I have in mind at this point are:
> >> - Extracting anything into the work directory feels like a hack
> >> - The class loader should use the same API as every other component
> >> - The class loader needs URLs that actually work
> >> - The anti-locking options are responsible for a number of the hacks in
> >>   the class loader
> >>
> >> The solution I have in mind is along the following lines:
> >> - Add a new getClassLoaderResource() to the WebResources interfaces.
> >>   This will implement the standard WEB-INF/classes then JARs in
> >>   WEB-INF/lib search order. It should be able to do this without any
> >>   extraction into the work directory.
> >
> > A useful feature in TC 6/7 was to add search paths outside of the war to
> > look for config files in order to provide config options special to
> > deployment environments without working with individual war files (via
> > VirtualWebappLoader).
> >
> > I know it is possible with the current resource implementation in TC 8,
> > but will it also be possible after this change, i.e. if the webapp
> > retrieves a config file as a resource via the webapp class loader, can
> > we still configure additional directories to be searched for the
> resource?
>
> Yes (assuming I don't mess up the implementation).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to