Re: [hibernate-dev] Scanner contract

On Mon 18 Mar 2013 05:14:01 AM CDT, Emmanuel Bernard wrote: > >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. As far as JBoss AS, Scott has been involved in this design from the beginning. >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. I have never seen that #getUnqualifiedJarName used aside from tests. >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. There is actually very very very little "JPA knowledge" being asked of the Scanner in my proposal. Keep in mind that in both the cases that have surfaced so far where we actually need "custom Scanner" both are cases where the Scanner provider is also the thing that is handing us the root/additional jars. For EE JPA thats actually part of the PersistenceUnitInfo contract; no magic there. So for JBoss AS (or another AS) to hand us both the PersistenceUnitInfo (with jar urls) and the Scanner (knowning how to scan said url protocols) is not unreasonable. In the case of Enterprise OSGi (at least based on our initial target environment), we have a PersistenceUnitInfo that only points us to the root url (#getJarFileUrls returns nothing), but this is the kind of "environment specifics" the current implementation forces Hibernate to understand. And then, in both cases it forces Hibernate to import and use non-standard APIs just to do the scanning (JBoss's VirtualFile contract and quite a few OSGi contracts). The important point I think you are missing is that it is far more difficult asking Hibernate to understand all the url protocol schemes in play then for the environments using those protocols to tell use how to scan them.

>Things around: > >- getMappingFileNames to return the stream for these files, Not at all following here. Do you mean getMappingFileNames on the PersistenceUnitInfo? Well that does *not* return streams, it returns Strings. And the spec specifically says that the Strings are supposed to be the resource names of the mapping files (aka, they should be loadable by that name through ClassLoader). So what exactly is the point here?

>- isExcludeUnlistedClasses to not scan classes in the root JAR, Exactly. This "option" only has bearing on the root jar. For all other jars Hibernate tries to be friendly and load everything. But, that is hardly "deep JPA knowledge". The option in terms of the root jars maps directly to an explicit JPA discussion. Nothing deep about the knowledge there. And for the non-root jars, there is nothing JPA specific in this option; its purely a Hibernate *choice*.

>- getJarFileUrls Again, I think you are missing the point that generally speaking the PersistenceUnitInfo provider and the Scanner provider are one-in-the-same. >- 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. Not sure how this is classified as "deep JPA knowledge".

>- getManagedClassNames depending on how much you delegate to the scanner Again, not sure how this is classified as "deep JPA knowledge". I assume you mean because of PUI#excludeUnlistedClasses, but see that discussion above. >That makes me concerned about code duplication and bugs unless someone >deep in JPA immplement all of these Scanner implementations. So, I am really not seeing this "need for deep knowledge of JPA" on the Scanner implementor in what I propose.