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