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 t
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
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-Bu
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 :
> Usu
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 r
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
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!
>
> Sh
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 correc