[hibernate-dev] Scanner contract

[Gunnar Morling]

Hi,

2013/3/16 Steve Ebersole <steve at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>