[hibernate-dev] Scanner contract
Steve Ebersole
steve at hibernate.org
Mon Mar 18 11:56:54 EDT 2013
What would ScanOptions look like? What about this:
interface ScanOptions {
public boolean scanRootUrlForClasses();
public boolean scanNonRootUrlsForClasses();
public boolean detectHibernateMappingFiles();
}
I think that is the bare minimum amount of information needed to scan.
Depending on how much responsibility we push to the Scanner, this might
need to be altered slightly.
On 03/17/2013 04:04 PM, Steve Ebersole wrote:
> 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...
More information about the hibernate-dev
mailing list