[hibernate-dev] Scanner contract

[Ales Justin]

It's probably best if the SPI would take the ClassLoader as parameter,
instead of having to guess it, or depend on proper TCCL (think OSGi ;-)).

e.g. for this reason Infinispan introduced AdvancedCache::withClassLoader.

-Ales

On Mar 16, 2013, at 8:48 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I should clarify why I did not necessarily like the ClassDescriptor and 
> PackageDescriptor (or whatever we name them) to "encapsulate which 
> class loader to use".  At least based on the JBoss AS usage (and I can 
> envision other environments being similar) we do not necessarily know 
> the ultimate ClassLoader for these things when we are doing the 
> scanning.  That ClassLoader instance gets built later.
> 
> On Sat 16 Mar 2013 09:53:19 AM CDT, Steve Ebersole wrote:
>> On Sat 16 Mar 2013 03:29:22 AM CDT, Gunnar Morling wrote:
>>> 
>>> interface ScanResult {
>>> public Set<String> getPackageNames();
>>> public Set<String> getClassNames();
>>> public Set<NamedInputStream> getResourceStreams();
>>> }
>>> 
>>> 
>>> Is there missing one method? Or is it 4 methods in the original design
>>> and one is not required with the new design?
>> 
>> The latter.  The current Scanner contract defined:
>> 
>> Set<NamedInputStream> getFilesInJar(URL jartoScan, Set<String>
>> filePatterns);
>> Set<NamedInputStream> getFilesInClasspath(Set<String> filePatterns);
>> 
>> I consolidated this into one return group.
>> 
>> 
>>> 
>>> The first thing to note is the move away from using
>>> java.lang.Class and
>>> java.lang.Package for returning the matching classes and packages.
>>> This
>>> facilitates the "late loading" of those on the classloader
>>> (jandex/classmate).
>>> 
>>> 
>>> Just a thought: would it make sense to return something like a
>>> ClassDescriptor or PackageDescriptor which would know how to
>>> materialize a given name into a Class or Package (by having methods
>>> such as asClass() etc.)? This might be helpful as it encapsulates
>>> which class loader to use and also avoids to accidentally use package
>>> names as class names etc.
>> 
>> I like that suggestion.  Not sure it makes sense have it encapsulate
>> the link back to the classloader for loading.  But either way I
>> definitely like the idea of the specific return type.
>> 
>> 
>>> 
>>> ScanOptions essentially just allows us a way to pass in the things we
>>> want to limit on; search filters if you will.
>>> 
>>> 
>>> Is ScanOptions available somewhere already? Based on the name I assume
>>> this can contain several options. Would it alternatively make sense to
>>> have something like ScanOption... options?
>> 
>> The problem is that the different options apply to each "bucket" of
>> returns.  So a simple list would certainly not work.  Now it is
>> questionable whether the options are needed for the package and class
>> name scanning.  The existing code essentially allows configurable set
>> of annotations to limit the search:
>> 
>> 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".  If we leave it as ScanOption and
>> initially leave off options for getPackageNames and getClassNames but
>> later decide to add it, the implementations of Scanner do not need to
>> change.
>> 
>> 
>> [1] changing my mind to calling that getNamedInputStreams instead.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev