A good test would be to upgrade bval tck module I think. It had some requirement "as a container" which can have leaked this behavior.
Le 9 juil. 2017 22:18, "Mark Struberg" <[email protected]> a écrit : > 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 > >>>> > >> > >> > >
