Yes and no IMHO. Strictly speaking you are perfectly right, org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#registerBeanArchives should handle File and not URL and do the filtering there (and fail if needed) but org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#filterExcludedJars is protected and therefore we should respect this signature so sounds like we must do it in the registerBeanArchives and keep a map File -> URL to reserve it in filter method. Is it your proposal Mark?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 13 juin 2020 à 20:13, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > > > > Am 13.06.2020 um 19:37 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > >> e.2) > >> if (file == null) { > >> throw new IllegalArgumentException( > >> Why? Let's log a WARN, but why blow up? xbean only supports jar: and > file: > >> protocols. Anything other will just not be excluded. So what? > >> > > > > Blow up cause we don't know how to handle it and it is unexpected - until > > we refine the exact protocol like jrt:// (but this particular one must > not > > happen here). > > Typically if you silently ignore it then you don't do what is expected at > > 100% so better fail when we don't know since it is not a supported case > so > > behavior will be undefined. > > To give you an example: you use jpms to make your app "pseudo native" > then > > scanning is no more done and the app is broken so IMHO best we can do is > > fail and point on the two solutions: exclude if ok or use another impl > > (shrinkwrap for the referenced jira). > > But this is totally the wrong location to stop handling this case. > > This method is just for filtering out classpath entries we know must NOT > be scanned. > So the default is to _not_ remove classpath entries if we are unsure. > > IF it turns out that the app cannot handle it, then we will handle this in > the Deployer anyway. > I'd rather be really defensive here: the method is for removing classpath > entries it KNOWS must not be handled. If it is unsure, then not remove > anything. > Wrong location to complain about any bad protocol! > > LieGrue, > strub
