Yes I did hit the single CL case. We basically found it twice in the same CL... That was a clear bug and I fixed it. But I'm currently working on yet another weird issue with the DeltaSpike build and will commit all once I'm done.
LieGrue, strub > Am 09.07.2017 um 22:09 schrieb Romain Manni-Bucau <[email protected]>: > > This is another issue then if we have duplicates in the same loader and not > a hierarchy. Did we identify which one we hit? Set is not a solution for > hierarchy one normally and for single loader case the impl should be > revisited anyway. No? > > > > Le 9 juil. 2017 20:18, "Mark Struberg" <[email protected]> a écrit : > >> Usually a Set is a good idea. But in case of URLs it's pretty nasty due to >> the equals in URLs might be very expensive as it _might_ do a DNS resolving >> over the internet even ;) >> In OWB we have an own UrlSet for it which at least only does the equals on >> the toExternalForm(). Much better, but not really cheap neither. >> >> LieGrue, >> strub >> >> >>> Am 09.07.2017 um 20:04 schrieb John D. Ament <[email protected]>: >>> >>> If the same URL comes back from multiple classloaders, you may want to >> use >>> a Set instead of a List to ensure uniqueness. URLs delegate uniqueness >>> checks to the URLStreamHandler, which by default looks at the ref >> attribute >>> of the URL. >>> >>> I do think you need to delegate up to the parent classloader in case you >>> come across a resource that wasn't loaded by OWB's ClassLoader. >>> >>> John >>> >>> On Sun, Jul 9, 2017 at 1:17 PM Romain Manni-Bucau <[email protected] >>> >>> wrote: >>> >>>> Hi Mark >>>> >>>> Shouldnt delegate but if you add "arquillian context" we can need in >> some >>>> environment to fake it. If so we can revisit our classloader config to >> makt >>>> it assumed and not just a best effort exception (which came from tck >> needs) >>>> >>>> Le 9 juil. 2017 12:47, "Mark Struberg" <[email protected]> a >>>> écrit : >>>> >>>>> Hi! >>>>> >>>>> Should the URLClassLoader#findResources really delegate back to it's >>>>> parent? >>>>> >>>>> It looks like getResources() should give all the resources found for >> the >>>>> CL + it's parent chain and findResources should only return the >> resources >>>>> from the 'local' path of the current CL. >>>>> Is this assumption correct? The ClassLoader JavaDoc is pretty sparse on >>>>> this :( >>>>> >>>>> With delegating to the parent in findResources we essentially picked >> the >>>>> resources up twice. >>>>> >>>>> LieGrue, >>>>> strub >>>> >> >>
