On 23/09/2013 21:52, Romain Manni-Bucau wrote: > I already explained how t8 loader and WebResource breaks libs based on std > URLClassLoader
I've looked back through the dev list archives and can't find any specific information that describes the problem in any detail. I'm fairly confident that whatever is missing / broken can be provided/fixed but that isn't going to happen without a clear explanation of what the problem is. > Here is the class in xbean > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/main/java/org/apache/xbean/finder/ClassLoaders.java > > I know we can workaround it but then we miss classes in the loader (was the > reason to use getURLs). Another thing is getURLs is insanely fast compared > to the other algorithm. > > Here is the xbean case but a lot of libs do it cause that's the only real > way to find urls from loaders. > > Another thing is jar:war urls will totally break common scanners (all since > it was not existing, isnt it?). So tomee, spring, owb, weld, ... will be > broken Why? They will be valid URLs in that JVM because the appropriate handler will have been registered. I can certainly imagine some scenarios where TomcatURLStreamHandlerFactory needs some tweaks to get it to play nicely in a broader container environment. Let us know what those tweaks are and they can be implemented. > Finally getURLs still say it respects addURL which doesnt look right (sadly) I see what happened on this. addURL() was removed as part of the resources refactoring that removed addRepository(). It looks like addURL() and the associated plumbing needs to be added back. What is the use case for needing to call addURL() on this class loader? It adds complexity to the class loader that I'd be happy to avoid if I could. Is the use case is something that can/should be handled through the new resources implementation? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
