On 03/16/2013 04:54 PM, Gunnar Morling wrote: > > Set<Package> getPackagesInJar(URL jartoScan, Set<Class<? extends > Annotation>> annotationsToLookFor); > Set<Class<?>> getClassesInJar(URL jartoScan, Set<Class<? extends > Annotation>> annotationsToLookFor); > > but currently we always pass empty to getPackagesInJar and a > static > set of values to getClassesInJar. So, to me it is questionable > whether that is really needed. The scanner could just do > these since > the code calling scanner never varies these. > > Now, for getResourceStreams[1] if we drop the notion of any > options > for getPackageNames and getClassNames I can see the param > being just a > varargs/array of "scan option" objects. But to me, this > highlights > the niceness of "parameter objects". > > > I didn't mean that ScanOption should not be a parameter object, I was > just wondering why it is one ScanOption*s* object instead of a > list/var-args of option objects.
Because you want different filters for different types of look ups. So if you have scan(PersistenceUnitDescriptor pud, ScanOption... options) how do you make the link between, say, the first option applies to class lookups but no other lookups? Or that the options 1 and 2 apply to hbm.xml lookups, option 1 applies to orm.xml lookups? Etc? You can't. At least not without some form of implicitness. I need to run but later I will post an example of ScanOptions as I intended. Maybe that will help... _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
