[jira] [Updated] (OWB-1179) OWB-Arquillian scanner doesn't ignore classes with ClassNotFound and NoClassDefFound

[ https://issues.apache.org/jira/browse/OWB-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OWB-1179: --- Fix Version/s: 2.0.0 > OWB-Arquillian scanner doesn't ignore classes with ClassNotFound and >

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

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...

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

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"

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

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

Re: VOTE Release Apache Meecrowave-1.0.0

+1 Thank you Le dim. 9 juil. 2017 à 00:19, Jean-Louis MONTEIRO a écrit : > It's already late. I'll have a look to this one tomorrow if not too late. > > Le sam. 8 juil. 2017 à 22:20, Romain Manni-Bucau > a écrit : > >> +1 >> >> Le 8 juil. 2017 19:43,

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"

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

Re: OWB-2.0.0 to be released soon

Hi John! I've now found a bit time to investigate OWB-2 behaviour in DeltaSpike. I'm now down to just a few tests and they all seems to be caused by different behaviour of arquillian. There is a test which checks that a resource must only be served a single time from the ClassPath. In this