I am integrating this into master at the moment.
On Wed 20 Mar 2013 10:27:31 PM CDT, Steve Ebersole wrote:
> I should point out that for most cases, writing a new Scanner should
> be as simple as extending
> org.hibernate.jpa.boot.scan.spi.AbstractScannerImpl and passing in a
> custom org.hibernate.jpa.boot.archive.spi.ArchiveDescriptorFactory
> that handles specific archive types (by URL protocol, etc).
>
> For OSGi, we will need a tiny bit more work for environments like we
> have seen that only give us the root url. There, assuming we extend
> AbstractScannerImpl, we will need the custom ArchiveDescriptorFactory
> and somehow it will need to account for the single url -> multiple
> artifacts deal (probably the ArchiveDescriptors it returns will need
> to do some delegation to sub-ArchiveDescriptors).
>
>
> On Wed 20 Mar 2013 07:39:51 PM CDT, Steve Ebersole wrote:
>> Here is the initial work I did on this.
>>
>> https://github.com/sebersole/hibernate-core/tree/HHH-8088
>>
>> Unfortunately it includes a lot of fixes to bad test code, especially
>> in org.hibernate.jpa.test.packaging.PackagingTestCase and children
>> (please no more relative file references in tests).
>>
>> At a high level, scanning involves mainly collaboration between stuff
>> in 2 packages:
>> 1) org.hibernate.jpa.boot.archive - essentially what used to be
>> JarVisitor and friends
>> 2) org.hibernate.jpa.boot.scan - uses the archive "walking" provided
>> by org.hibernate.jpa.boot.archive and applies filtering to the "entries"
>>
>> The ultimate goal of the scan is to build a
>> org.hibernate.jpa.boot.scan.spi.ScanResult which essentially collects
>> together the org.hibernate.jpa.boot.spi.ClassDescriptor,
>> org.hibernate.jpa.boot.spi.PackageDescriptor and
>> org.hibernate.jpa.boot.spi.MappingFileDescriptor references.
>>
>>
>> On Tue 19 Mar 2013 11:02:38 AM CDT, Steve Ebersole wrote:
>>> The problem is what Hibernate does once it returns from the Scanner
>>> calls. It applies filters. And the filters is applies are different
>>> based on whether the url being scanned is the PU root url or a
>>> non-root. You simply don't have that info; so I don't think it will
>>> work.
>>>
>>>
>>> On Tue 19 Mar 2013 10:49:56 AM CDT, Brett Meyer wrote:
It's probably too early in the process to know for sure, but I'm
already headed down the path of using the existing Scanner contract
for OSGi scanning in 4.2. I provide a custom Scanner that ignores
the "jar URL" completely -- all scans tap into the OSGi
BundleWiring. The scanning methods shouldn't be called repeatedly
since PersistenceUnitInfo#getJarFileUrls is empty (at least in the
Karaf container). Correct me if that won't work...
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
- Original Message -
From: "Steve Ebersole"
To: "Scott Marlow"
Cc: "Hibernate hibernate-dev"
Sent: Tuesday, March 19, 2013 11:19:09 AM
Subject: Re: [hibernate-dev] Scanner contract
Yes, part of the redesign was to return class names (and streams)
rather than Class instances, but thats just part of the reasoning.
The problem is that we really can't continue to use the Scanner
contract as-is; it is not great for OSGi environments. Could we hack
up the OSGi stuff to work with Scanner? I don't think so. When OSGi
PersistenceUnitInfo simply returns you a root URL, how can we possibly
apply different filters for root/non-root using the existing Scanner
contract?
Anyway, I am well down the path of implementing this. I'll push to my
fork when done and everyone can chime in their on real concrete code.
One thing I can tell you that will be a huge bugbear here in terms of
refactoring is that this existing Scanner and JarVisitor code has
*zero* unit tests.
On Tue 19 Mar 2013 10:06:42 AM CDT, Scott Marlow wrote:
> On 03/18/2013 09:15 AM, Steve Ebersole wrote:
>> 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.
>
> Given all of the discussion so far, and feedback from Ales/Emmanuel
> who originally created the Scanner, I want to back track and reassess
> before we get too far ahead on changing the scanner (from the point
> ofo view of the AS side, just to confirm that the new design would
> work). My initial observation was that the AS side is returning
> Class
> instances that we are only getting the name from. Just returning
