Re: behaviour of URLClassLoader#findResources
After 2 days of debugging and side by side comparison between old OWB versions and OWB-2 I now likely found the problem. Test is NoNavigationParameterWarFileTest. In OWB-1.2.x and 1.7.x we did _only_ scan jars with a beans.xml. For OWB-2.0 I added the full implicit bda handling due to some TCK tests. That means we now pick up every damn class. And there is a funny jar called DefaultBeanArchiveInformation{bdaUrl='archive://deltaspikeUtils.jar//', beanDiscoveryMode=ANNOTATED} which contains things like org.openqa.selenium.lift.match.SelectionMatcher etc. Those damn classes not only create NoClassDefFound but also LinkingErrors, as they try to load native DLLs (which of course fail on my Mac)... And this crazy jar contains 1300 classes... The damn guy who added this to DeltaSpike back then in early 2012 calls himself 'struberg' ;) The test now passes. Running the full suite right now. LieGrue, strub > Am 09.07.2017 um 22:20 schrieb Romain Manni-Bucau: > > 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" 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 >> : >>> >>> 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" 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 : > > 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 < >> rmannibu...@gmail.com > > 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" 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 >> >> >>
Re: behaviour of URLClassLoader#findResources
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"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 >: > > > > 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" 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 : > >>> > >>> 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 < > rmannibu...@gmail.com > >>> > >>> 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" 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 > > >> > >> > >
Re: behaviour of URLClassLoader#findResources
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: > > 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" 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 : >>> >>> 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 >> >>> 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" 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 >> >>
Re: behaviour of URLClassLoader#findResources
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"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 : > > > > 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 > > > 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" 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 > >> > >
Re: behaviour of URLClassLoader#findResources
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: > > 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 > 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" 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 >>
Re: behaviour of URLClassLoader#findResources
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-Bucauwrote: > 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" 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 >
Re: behaviour of URLClassLoader#findResources
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"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
behaviour of URLClassLoader#findResources
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