Re: [hibernate-dev] Scanner contract
Hi,
2013/3/16 Steve Ebersole <steve(a)hibernate.org>
I am proposing a change to the
org.hibernate.jpa.packaging.spi.Scanner
SPI. First I suggest we make the scanning happen in one call, and that
one call return a token of the result. Currently we have 4 "scan"
methods on the Scanner contract; I instead propose there be a ScanResult
that holds those 4 results:
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 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.
To get a ScanResult, we'd call the newly consolidated method on Scanner:
interface Scanner {
public ScanResult scan(PersistenceUnitDescriptor descriptor,
ScanOptions options);
}
or maybe:
interface Scanner {
public ScanResult scan(URL rootUrl, ScanOptions options);
}
though I definitely prefer the first option.
So the first thing to notice here is that there is one call to the
scanner for the entire persistence unit, not the multiple calls we do
today. So the onus of scanning sub-jars and "other jars" moves to the
Scanner. This is helpful in OSGi environments. It also allows easier
caching on the Scanner impl side for deployment walking. Lots of other
little wins here IMO too.
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?
I'd like to make this change in 4.3 (JPA 2.1 support), so please speak
up sooner rather than later if you have disagree with this proposal.
Comments, suggestions, improvements welcome.
--Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev