Then not sure which place you have in mind to fail? An alternative could have been to do exclusions on the url.tostring but it would break current existing apps which is not an option for this thing IMHO. Do you have anything in mind?
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:41, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > No, we did have File in OWB-1.0 and 1.1. And killed that because we got > problems because not all classpath elemts are file based. > Examples are some app servers which have even some internal protocols. > like webjar for example in EARs in WebLogic (yes, there are some peeps who > use OWB in weblogic, because it's so much faster than the default CDI > container!). It also might happen in Arquillian for example, or other > purely memory based scenarios where the JAR never exists on disk.. > This was the reason we switched for URL. Anything file based is > counterproductive in this location. > > LieGrue, > strub > > > > Am 13.06.2020 um 20:32 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > 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 > >
