Hi about the handler: a lot of container (i particularly know tomee but not only) use string representation of URL to find file to then work on the file (either during scanning or sometimes for some more advanced "hack"). If you introduce something not known by these framework it will just fail. That's the reason why scanning is not really portable and why vfs (for JBoss for instance) exists. You are doing the same in tomcat (which is sad since tomcat was until today simple on this aspect).
About addURL: we use it in tomee to enrich the classloader in multiple places (but i saw some tomcat extensions doing it too). Our needs are: 1) add container jar in a particular deployment mode (tomee as a webapp) 2) add container jar for some particular features (jsf, jpa, ... - some classes needs to be loaded from the webapp) 3) use a descriptor to define the container (typically jars.txt lists all jar of the loader with mvn/file/http/... syntax). Then our scanning just reuse getURLs(). If you want to discuss of it a bit more dynamically i'm still on IRC (freenode #openejb) for some hours. *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/24 Mark Thomas <ma...@apache.org> > 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 > >
