Re: [hibernate-dev] Scanner contract
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev