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
>>>>
>>>
tInfo#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 -
>>> Fr
eUrls 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
re 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
&g
e 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 reasoni
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 wi
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 an
Well, Scanner and the code using it is I think isolated from the URL
protocols. But our default implementation that uses the JarVisitor code
is our attempt at supporting most environments. We managed to amke it
work for Websphere, Weblogic, Tomcat, plain SE etc. That's why this part
is so complicat
Also, I think another reason that the current scanning code is so
complicated in the mapping file case is because we are not "just
scanning". If I understand correctly, we also use the
Scanner#getFilesInJar call as an opportunity to resolve named mappings
files.
Not saying its a bad thing to
What would ScanOptions look like? What about this:
interface ScanOptions {
public boolean scanRootUrlForClasses();
public boolean scanNonRootUrlsForClasses();
public boolean detectHibernateMappingFiles();
}
I think that is the bare minimum amount of information needed to scan.
D
On Mon 18 Mar 2013 09:10:40 AM CDT, Emmanuel Bernard wrote:
>
> That was the point of the Scanning API in the first place: not to depend
> on specific APIs like the VirtualFile. That and the fact that JBoss AS
> had Jandex and we did not were the reason for Ales and me to have this
> interface.
Ok,
On Mon 2013-03-18 8:15, 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
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
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 getUnqualif
On 03/16/2013 04:54 PM, Gunnar Morling wrote:
>
> Set getPackagesInJar(URL jartoScan, Set Annotation>> annotationsToLookFor);
> Set> getClassesInJar(URL jartoScan, Set Annotation>> annotationsToLookFor);
>
> but currently we always pass empty to getPackagesIn
Not saying the use of platform/environemtn specific url protocols is
bad in any way. Just saying that I think it is unreasonable to code in
Hibernate handling for all these protocols. JBoss VFS, for example, is
much better handled using JBoss VirtualFile API. OSGi protocols will
require very
> I should point out this is based on what we saw when Brett initially worked
> with Karaf, especially in the Enterprise OSGi use cases. The incoming
> PersistenceUnitInfo contained no urls other than the root url, which happened
> to be an osgi bundle url (the protocol was "bundle"). To me, i
2013/3/16 Steve Ebersole
> I should clarify why I did not necessarily like the ClassDescriptor and
> PackageDescriptor (or whatever we name them) to "encapsulate which class
> loader to use". At least based on the JBoss AS usage (and I can envision
> other environments being similar) we do not n
I should point out this is based on what we saw when Brett initially
worked with Karaf, especially in the Enterprise OSGi use cases. The
incoming PersistenceUnitInfo contained no urls other than the root url,
which happened to be an osgi bundle url (the protocol was "bundle").
To me, interpre
No guessing involved. The PersistenceUnitDescriptor passed in to scan()
tells exactly which deployment we are talking about. And if the
container does not know the ClassLoader how do you expect HIbernate to? ;)
On 03/16/2013 03:09 PM, Ales Justin wrote:
> It's probably best if the SPI would ta
It's probably best if the SPI would take the ClassLoader as parameter,
instead of having to guess it, or depend on proper TCCL (think OSGi ;-)).
e.g. for this reason Infinispan introduced AdvancedCache::withClassLoader.
-Ales
On Mar 16, 2013, at 8:48 PM, Steve Ebersole wrote:
> I should clarif
I should clarify why I did not necessarily like the ClassDescriptor and
PackageDescriptor (or whatever we name them) to "encapsulate which
class loader to use". At least based on the JBoss AS usage (and I can
envision other environments being similar) we do not necessarily know
the ultimate Cl
On Sat 16 Mar 2013 03:29:22 AM CDT, Gunnar Morling wrote:
>
> interface ScanResult {
> public Set getPackageNames();
> public Set getClassNames();
> public Set getResourceStreams();
> }
>
>
> Is there missing one method? Or is it 4 methods in the original design
> and one is not required with the n
Hi,
2013/3/16 Steve Ebersole
> 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 propos
Should have mentioned that PersistenceUnitDescriptor[1] is an
abstraction I introduced in 4.3 codebase to insulate processing from
whether the PU come to use via persistence.xml parsing (SE) or being
handed a PersistenceUnitInfo (EE).
[1]
https://github.com/hibernate/hibernate-orm/blob/master/
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 t
26 matches
Mail list logo
