[hibernate-dev] Scanner contract

[Emmanuel Bernard]

JBoss AS does use this contract so if you break it, we will need some
kind of compatibility matrix between Hibernate and JBoss AS and EAP.
Not unsurmountable but always a small annoyance.
Maybe other environments also make use of this interface but I am not
aware of them.

I'm surprised getUnqualifiedJarName is no longer needed. I thought we
used it as the default PU name but the current code does not use getUnqualifiedJarName
anymore.

We initially designed the Scanner interface to minimize the work the
Scanner implementor has to do and keep as much of the JPA knowledge to
HEM's code. Your design seems to require the Scanner to understand more of
JPA including the notion of root jar and additional jar files.
Things around:

- getMappingFileNames to return the stream for these files, 
- isExcludeUnlistedClasses to not scan classes in the root JAR,
- getJarFileUrls
- look for META-INF/orm.xml in the root JAr (only) and exclude it if it
  is already listed explicitly in the getMappingFileNames to not process
  it twice.
- getManagedClassNames depending on how much you delegate to the scanner

That makes me concerned about code duplication and bugs unless someone
deep in JPA immplement all of these Scanner implementations.

Emmanuel

On Fri 2013-03-15 20:01, Steve Ebersole wrote:
> 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();
> }
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev