You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2017/07/09 10:47:14 UTC
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
Re: behaviour of URLClassLoader#findResources
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> 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" <st...@yahoo.de.invalid> 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 <rmannibucau@gmail.com
>>> :
>>>
>>> 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" <st...@yahoo.de.invalid> 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 <jo...@apache.org>:
>>>>>
>>>>> 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 <
>> rmannibucau@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" <st...@yahoo.de.invalid> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@yahoo.de.invalid> 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 <rmannibucau@gmail.com
> >:
> >
> > 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" <st...@yahoo.de.invalid> 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 <jo...@apache.org>:
> >>>
> >>> 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 <
> rmannibucau@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" <st...@yahoo.de.invalid> 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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@gmail.com>:
>
> 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" <st...@yahoo.de.invalid> 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 <jo...@apache.org>:
>>>
>>> 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 <rmannibucau@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" <st...@yahoo.de.invalid> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@yahoo.de.invalid> 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 <jo...@apache.org>:
> >
> > 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 <rmannibucau@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" <st...@yahoo.de.invalid> 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
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@apache.org>:
>
> 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 <rm...@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" <st...@yahoo.de.invalid> 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
Posted by "John D. Ament" <jo...@apache.org>.
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 <rm...@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" <st...@yahoo.de.invalid> 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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <st...@yahoo.de.invalid> 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