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 getPackageNames();
> public Set getClassNames();
> public Set 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Discovering/configuring package-info
Trying to upgrade to 4.3-SNAPSHOT, the
EntityManagerFactoryBuilderImpl.indexResource() is failing for my
persistence.xml configuration in Java SE with
Persistence.createEntityManagerFactory():
myDS
org.jpwh.model
org.jpwh.model.simple.Item
org.jpwh.model.simple.User
org.jpwh.model.simple.Bid
org.jpwh.model.simple.Address
org.jpwh.model.simple.Category
true
The org.jpwh.model was necessary in 4.1 to get the
package-info.java of that package included, it contains my @GenericGenerators.
[main] TRACE - 13:57:28,926 - nternal.ClassLoaderServiceImpl:
trying via [new URL("org/jpwh/model.class")]
[main] TRACE - 13:57:28,926 - nternal.ClassLoaderServiceImpl:
trying via [ClassLoader.getResourceAsStream("org/jpwh/model.class")]
Exception in thread "main" javax.persistence.PersistenceException:
[PersistenceUnit: SimplePU] Unable to open input stream for resource
org/jpwh/model.class
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:1133)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:337)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildJandexIndex(EntityManagerFactoryBuilderImpl.java:315)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.locateOrBuildJandexIndex(EntityManagerFactoryBuilderImpl.java:306)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:205)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:169)
at
org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:43)
at
org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:135)
at
org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:81)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:55)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:39)
at org.jpwh.env.JPA21Setup.(JPA21Setup.java:19)
at org.jpwh.test.Test.main(Test.java:12)
Caused by: java.io.IOException: Stream closed
at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at java.io.DataInputStream.readFully(DataInputStream.java:195)
at java.io.DataInputStream.readFully(DataInputStream.java:169)
at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:387)
at org.jboss.jandex.Indexer.index(Indexer.java:630)
at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:334)
It looks like the only way to currently get package-info picked up is with
automatic scanning. But in my case scanningContext.isDetectClasses() is false…
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Discovering/configuring package-info
The spec does not say anything about explicitly specifying packages. I
was not aware of handling for that in the old code which I have been
trying to de-spaghetti for some time, I can add that capability back in.
On 03/18/2013 08:22 AM, Christian Bauer wrote:
> Trying to upgrade to 4.3-SNAPSHOT, the
> EntityManagerFactoryBuilderImpl.indexResource() is failing for my
> persistence.xml configuration in Java SE with
> Persistence.createEntityManagerFactory():
>
>
> myDS
> org.jpwh.model
> org.jpwh.model.simple.Item
> org.jpwh.model.simple.User
> org.jpwh.model.simple.Bid
> org.jpwh.model.simple.Address
> org.jpwh.model.simple.Category
> true
>
>
> The org.jpwh.model was necessary in 4.1 to get the
> package-info.java of that package included, it contains my @GenericGenerators.
>
> [main] TRACE - 13:57:28,926 - nternal.ClassLoaderServiceImpl:
> trying via [new URL("org/jpwh/model.class")]
> [main] TRACE - 13:57:28,926 - nternal.ClassLoaderServiceImpl:
> trying via [ClassLoader.getResourceAsStream("org/jpwh/model.class")]
> Exception in thread "main" javax.persistence.PersistenceException:
> [PersistenceUnit: SimplePU] Unable to open input stream for resource
> org/jpwh/model.class
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:1133)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:337)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildJandexIndex(EntityManagerFactoryBuilderImpl.java:315)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.locateOrBuildJandexIndex(EntityManagerFactoryBuilderImpl.java:306)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:205)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:169)
> at
> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:43)
> at
> org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:135)
> at
> org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:81)
> at
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:55)
> at
> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:39)
> at org.jpwh.env.JPA21Setup.(JPA21Setup.java:19)
> at org.jpwh.test.Test.main(Test.java:12)
> Caused by: java.io.IOException: Stream closed
> at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:387)
> at org.jboss.jandex.Indexer.index(Indexer.java:630)
> at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:334)
>
> It looks like the only way to currently get package-info picked up is with
> automatic scanning. But in my case scanningContext.isDetectClasses() is false…
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Scanner contract
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 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. 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. > > > >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? The previous implementation of Scanner was returning the resource streams so you had to take PUI.getMappingFileNames() into account. I got confused. > > >- 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*. No that's what the JPA spec says (or intended), additional jars are to be scanned to find the entity classes. Otherwise the additional jar feature becomes very limited or even useless. You would only need it otherwise to retrieve the XML DD which was considered a second class citizen on JPA 1.0. > > >- 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". Understanding and implementing all these rules took me a while :) > > >- 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. I gave you my opinion, if you think that implementing Scanner will remain simple enough the
[hibernate-dev] Fwd: [infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8 is here (ISPN-2281)
Galder's work could very well be an interesting solution where we use IdentityMap. I know ORM has be using it less with the bytecode rework but I think we still use it in particular in Hibernate Validator. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fwd: [infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8 is here (ISPN-2281)
I don't know about Validator, but in the ORM case at least we didn't need all the overhead of a concurrent / threadsafe implementation. On 18 March 2013 14:21, Emmanuel Bernard wrote: > Galder's work could very well be an interesting solution where we use > IdentityMap. > > I know ORM has be using it less with the bytecode rework but I think we > still use it in particular in Hibernate Validator. > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Fwd: [infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8 is here (ISPN-2281)
ORM called it "concurrent" but its really not. Its just "mutation safe". Talking about its usage of IdentityMap. And we do actually have a few uses of IdentityMap still left. The problem with IdentityMap was always its use to store entities because we could not rely on their equals/hashcode, so we ended up having to wrap them. Thats what the bytecode stuff gets around; in fact with that stuff we don't even use a collection of any kind anymore, just a hand-maintained linked graph. On 03/18/2013 09:30 AM, Sanne Grinovero wrote: > I don't know about Validator, but in the ORM case at least we didn't > need all the overhead of a concurrent / threadsafe implementation. > > On 18 March 2013 14:21, Emmanuel Bernard wrote: >> Galder's work could very well be an interesting solution where we use >> IdentityMap. >> >> I know ORM has be using it less with the bytecode rework but I think we >> still use it in particular in Hibernate Validator. >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Scanner contract
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, but the decision to ask the Scanner these questions for each jar is
inadvertently requiring Hibernate to be sensitive to these protocols.
In fact the current standard Scanner impl has explicit handling for VFS
protocol schemes. And for OSGi, it would require that the single root
URL (because again thats all we get) actually encompasses the root jar
*and* any other specified jars. Aka, `if ( "bundle".equals( urlProtocol
) ) { doSomethingDrasticallyDifferent(); }...`.
So take the EE case, which I know is true of JBoss. JBoss is the one
handing us the PersistenceUnitInfo (which is the thing that backs the
PersistenceUnitDescriptor we pass back to it in this Scanner proposal).
I don't think it is unreasonable that JBoss understands the difference
between PersistenceUnitInfo#getPersistenceUnitRootUrl and
PersistenceUnitInfo#getJarFileUrls intrinsically (after all, it is the
one that gave us the PUI). By intrinsically I mean that it already
understands that there is a difference/distinction between the root and
any non-roots. So from there the question really is whether expecting
the Scanner to apply different scanning rules to root versus not-root
URLs constitutes "deep JPA knowledge". And maybe that is different for
each type of thing for which we scan.
For classes e.g. nothing stops us from saying the the Scanner just
returns us everything it finds and that we then filter or weed through
it. For example, if it returns us descriptors for all the classes it
finds, we can apply the "only use that class if it (a) came from a
specified jar or (b) came from the root and #excludeUnlistedClasses
allows us to use them" logic ourselves. Thats a trivial matter of us
defining the ClassDescriptor contract to tell us whether the class was
found in the root or not:
interface ClassDescriptor {
public String getClassName();
public NamedInputStream getNamedInputStream();
public boolean foundInRoot();
}
But again, I dont think that the Scanner applying that simple logic is
really "deep JPA knowledge". But if everyone else agrees it is, we can
easily alleviate that via the above pattern.
As for resources (orm.xml and hbm.xml files), I'd have to look a little
closer maybe. To be honest that is some of the code that uses the "Map
as an API" approach that makes me want to rip out my hair, gouge out my
eyes and leap off the nearest bridge :) It is code like this code that
has made me want to re-write what was EJB3Configuration from scratch
ever since I first started looking at it. That and the fact that any
time I ask anyone that had a hand in writing that code anything about
that code they simply throw up their hands and say they don't know ;)
Maybe it is more complicated than I am making it out to be. But I don't
think the way this is then presented to the rest of the code needs to be
complex. At the end of the day, there should be a scan and the results
of that scan should be a nice easy-to-understand contract.
> The previous implementation of Scanner was returning the resource
> streams so you had to take PUI.getMappingFileNames() into account. I got
> confused.
Still not following. The proposed Scanner contract is returning
NamedInputStreams, which is exactly what the current Scanner returns for
these.
> No that's what the JPA spec says (or intended), additional jars are to
> be scanned to
> find the entity classes. Otherwise the additional jar feature becomes
> very limited or even useless. You would only need it otherwise to
> retrieve the XML DD which was considered a second class citizen on JPA
> 1.0.
Ok, but is that "deep JPA knowledge" beyond what a typical JPA container
developer would generally know?
>>> - 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".
>
>
> Understanding and implementing all these rules took me a while :)
Ok, don't include duplicates.. check. ;) Not saying the rules are
simplistic. Just questioning whether they are only known to those with
"deep JPA knowledge". Not so sure that is true.
> I gave you my opinion, if you think that implementing Scanner will
> remain simple enough then most of my remarks are moot.
Considering I will implement the 3 main Scanner impls... ;) But
seriously, I don't think delegating to Scanner just once per persistence
unit puts undue difficulty on the Scanner impl.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hib
Re: [hibernate-dev] Scanner contract
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.
Depending on how much responsibility we push to the Scanner, this might
need to be altered slightly.
On 03/17/2013 04:04 PM, Steve Ebersole wrote:
> 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 getPackagesInJar and a
>> static
>> set of values to getClassesInJar. So, to me it is questionable
>> whether that is really needed. The scanner could just do
>> these since
>> the code calling scanner never varies these.
>>
>> Now, for getResourceStreams[1] if we drop the notion of any
>> options
>> for getPackageNames and getClassNames I can see the param
>> being just a
>> varargs/array of "scan option" objects. But to me, this
>> highlights
>> the niceness of "parameter objects".
>>
>>
>> I didn't mean that ScanOption should not be a parameter object, I was
>> just wondering why it is one ScanOption*s* object instead of a
>> list/var-args of option objects.
>
> Because you want different filters for different types of look ups.
> So if you have scan(PersistenceUnitDescriptor pud, ScanOption...
> options) how do you make the link between, say, the first option
> applies to class lookups but no other lookups? Or that the options 1
> and 2 apply to hbm.xml lookups, option 1 applies to orm.xml lookups?
> Etc? You can't. At least not without some form of implicitness.
>
> I need to run but later I will post an example of ScanOptions as I
> intended. Maybe that will help...
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Discovering/configuring package-info
Out of curiosity, where is this documented as being supported?
On Mon 18 Mar 2013 08:34:29 AM CDT, Steve Ebersole wrote:
> The spec does not say anything about explicitly specifying packages.
> I was not aware of handling for that in the old code which I have been
> trying to de-spaghetti for some time, I can add that capability back in.
>
> On 03/18/2013 08:22 AM, Christian Bauer wrote:
>> Trying to upgrade to 4.3-SNAPSHOT, the
>> EntityManagerFactoryBuilderImpl.indexResource() is failing for my
>> persistence.xml configuration in Java SE with
>> Persistence.createEntityManagerFactory():
>>
>>
>> myDS
>> org.jpwh.model
>> org.jpwh.model.simple.Item
>> org.jpwh.model.simple.User
>> org.jpwh.model.simple.Bid
>> org.jpwh.model.simple.Address
>> org.jpwh.model.simple.Category
>> true
>>
>>
>> The org.jpwh.model was necessary in 4.1 to get the
>> package-info.java of that package included, it contains my
>> @GenericGenerators.
>>
>> [main] TRACE - 13:57:28,926 -
>> nternal.ClassLoaderServiceImpl: trying via [new
>> URL("org/jpwh/model.class")]
>> [main] TRACE - 13:57:28,926 -
>> nternal.ClassLoaderServiceImpl: trying via
>> [ClassLoader.getResourceAsStream("org/jpwh/model.class")]
>> Exception in thread "main" javax.persistence.PersistenceException:
>> [PersistenceUnit: SimplePU] Unable to open input stream for resource
>> org/jpwh/model.class
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:1133)
>>
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:337)
>>
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildJandexIndex(EntityManagerFactoryBuilderImpl.java:315)
>>
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.locateOrBuildJandexIndex(EntityManagerFactoryBuilderImpl.java:306)
>>
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:205)
>>
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:169)
>>
>> at
>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:43)
>>
>> at
>> org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:135)
>>
>> at
>> org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:81)
>>
>> at
>> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:55)
>>
>> at
>> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:39)
>>
>> at org.jpwh.env.JPA21Setup.(JPA21Setup.java:19)
>> at org.jpwh.test.Test.main(Test.java:12)
>> Caused by: java.io.IOException: Stream closed
>> at
>> java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151)
>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
>> at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
>> at java.io.DataInputStream.readFully(DataInputStream.java:195)
>> at java.io.DataInputStream.readFully(DataInputStream.java:169)
>> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:387)
>> at org.jboss.jandex.Indexer.index(Indexer.java:630)
>> at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:334)
>>
>>
>> It looks like the only way to currently get package-info picked up is
>> with automatic scanning. But in my case
>> scanningContext.isDetectClasses() is false…
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Discovering/configuring package-info
On 18.03.2013, at 17:09, Steve Ebersole wrote: > Out of curiosity, where is this documented as being supported? http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/configuration.html The class element specifies a fully qualified class name that you will map. By default all properly annotated classes and all hbm.xml files found inside the archive are added to the persistence unit configuration. You can add some external entity through the class element though. As an extension to the specification, you can add a package name in the element (eg org.hibernate.eg). Caution, the package will include the metadata defined at the package level (ie in package-info.java), it will not include all the classes of a given package. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Discovering/configuring package-info
https://hibernate.atlassian.net/browse/HHH-8086
But I will change that from Bug to New Feature if it was not previously
documented anywhere.
To be honest, little nervous doing this as it effects provider
portability.
On Mon 18 Mar 2013 11:09:22 AM CDT, Steve Ebersole wrote:
> Out of curiosity, where is this documented as being supported?
>
>
> On Mon 18 Mar 2013 08:34:29 AM CDT, Steve Ebersole wrote:
>> The spec does not say anything about explicitly specifying packages.
>> I was not aware of handling for that in the old code which I have been
>> trying to de-spaghetti for some time, I can add that capability back in.
>>
>> On 03/18/2013 08:22 AM, Christian Bauer wrote:
>>> Trying to upgrade to 4.3-SNAPSHOT, the
>>> EntityManagerFactoryBuilderImpl.indexResource() is failing for my
>>> persistence.xml configuration in Java SE with
>>> Persistence.createEntityManagerFactory():
>>>
>>>
>>> myDS
>>> org.jpwh.model
>>> org.jpwh.model.simple.Item
>>> org.jpwh.model.simple.User
>>> org.jpwh.model.simple.Bid
>>> org.jpwh.model.simple.Address
>>> org.jpwh.model.simple.Category
>>> true
>>>
>>>
>>> The org.jpwh.model was necessary in 4.1 to get the
>>> package-info.java of that package included, it contains my
>>> @GenericGenerators.
>>>
>>> [main] TRACE - 13:57:28,926 -
>>> nternal.ClassLoaderServiceImpl: trying via [new
>>> URL("org/jpwh/model.class")]
>>> [main] TRACE - 13:57:28,926 -
>>> nternal.ClassLoaderServiceImpl: trying via
>>> [ClassLoader.getResourceAsStream("org/jpwh/model.class")]
>>> Exception in thread "main" javax.persistence.PersistenceException:
>>> [PersistenceUnit: SimplePU] Unable to open input stream for resource
>>> org/jpwh/model.class
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:1133)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:337)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildJandexIndex(EntityManagerFactoryBuilderImpl.java:315)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.locateOrBuildJandexIndex(EntityManagerFactoryBuilderImpl.java:306)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:205)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.(EntityManagerFactoryBuilderImpl.java:169)
>>>
>>>
>>> at
>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:43)
>>>
>>>
>>> at
>>> org.hibernate.jpa.HibernatePersistenceProvider.getEntityManagerFactoryBuilderOrNull(HibernatePersistenceProvider.java:135)
>>>
>>>
>>> at
>>> org.hibernate.jpa.HibernatePersistenceProvider.createEntityManagerFactory(HibernatePersistenceProvider.java:81)
>>>
>>>
>>> at
>>> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:55)
>>>
>>>
>>> at
>>> javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:39)
>>>
>>>
>>> at org.jpwh.env.JPA21Setup.(JPA21Setup.java:19)
>>> at org.jpwh.test.Test.main(Test.java:12)
>>> Caused by: java.io.IOException: Stream closed
>>> at
>>> java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151)
>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
>>> at java.io.DataInputStream.readFully(DataInputStream.java:195)
>>> at java.io.DataInputStream.readFully(DataInputStream.java:169)
>>> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:387)
>>> at org.jboss.jandex.Indexer.index(Indexer.java:630)
>>> at
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.indexResource(EntityManagerFactoryBuilderImpl.java:334)
>>>
>>>
>>>
>>> It looks like the only way to currently get package-info picked up is
>>> with automatic scanning. But in my case
>>> scanningContext.isDetectClasses() is false…
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Scanner contract
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 delegate this resolution to the
environment. In fact delegating the resolution to the environment is
probably the best way to avoid the duplicate results. The reason it is
complicated as is, is that the resolution of named mappings is done
implicitly, rather than explicitly. So we call off to scan for mapping
files,
That complication, to me, is based on the understanding that "scanning"
is all about finding additional stuff. But what we have is that
scanning for classes and packages is all about finding additional,
non-named things while it is the exact opposite in terms of scanning for
mapping files where we do both: we find (and resolve) additional,
non-named things *and* we resolve named things.
At least that is how I read the code.
On 03/18/2013 10:40 AM, Steve Ebersole wrote:
> 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, but the decision to ask the Scanner these questions for each jar
> is inadvertently requiring Hibernate to be sensitive to these
> protocols. In fact the current standard Scanner impl has explicit
> handling for VFS protocol schemes. And for OSGi, it would require
> that the single root URL (because again thats all we get) actually
> encompasses the root jar *and* any other specified jars. Aka, `if (
> "bundle".equals( urlProtocol ) ) { doSomethingDrasticallyDifferent();
> }...`.
>
> So take the EE case, which I know is true of JBoss. JBoss is the one
> handing us the PersistenceUnitInfo (which is the thing that backs the
> PersistenceUnitDescriptor we pass back to it in this Scanner
> proposal). I don't think it is unreasonable that JBoss understands
> the difference between PersistenceUnitInfo#getPersistenceUnitRootUrl
> and PersistenceUnitInfo#getJarFileUrls intrinsically (after all, it is
> the one that gave us the PUI). By intrinsically I mean that it
> already understands that there is a difference/distinction between the
> root and any non-roots. So from there the question really is whether
> expecting the Scanner to apply different scanning rules to root versus
> not-root URLs constitutes "deep JPA knowledge". And maybe that is
> different for each type of thing for which we scan.
>
> For classes e.g. nothing stops us from saying the the Scanner just
> returns us everything it finds and that we then filter or weed through
> it. For example, if it returns us descriptors for all the classes it
> finds, we can apply the "only use that class if it (a) came from a
> specified jar or (b) came from the root and #excludeUnlistedClasses
> allows us to use them" logic ourselves. Thats a trivial matter of us
> defining the ClassDescriptor contract to tell us whether the class was
> found in the root or not:
>
> interface ClassDescriptor {
> public String getClassName();
> public NamedInputStream getNamedInputStream();
> public boolean foundInRoot();
> }
>
> But again, I dont think that the Scanner applying that simple logic is
> really "deep JPA knowledge". But if everyone else agrees it is, we
> can easily alleviate that via the above pattern.
>
> As for resources (orm.xml and hbm.xml files), I'd have to look a
> little closer maybe. To be honest that is some of the code that uses
> the "Map as an API" approach that makes me want to rip out my hair,
> gouge out my eyes and leap off the nearest bridge :) It is code like
> this code that has made me want to re-write what was EJB3Configuration
> from scratch ever since I first started looking at it. That and the
> fact that any time I ask anyone that had a hand in writing that code
> anything about that code they simply throw up their hands and say they
> don't know ;)
>
> Maybe it is more complicated than I am making it out to be. But I
> don't think the way this is then presented to the rest of the code
> needs to be complex. At the end of the day, there should be a scan
> and the results of that scan should be a nice easy-to-understand
> contract.
>
>> The previous implementation of Scanner was returning the resource
>> streams so you had to take PUI.getMappingFileNames() into account. I got
>> confused.
>
> Still not following. The proposed Scanner contract is returning
> NamedInputStreams, which is exactly what the current Scanner returns
> for these.
>
>> No that's what the JPA spec says (or intended), additional jars are
>> to be scanned to
>> find the entity classes. Otherwise the additional j
[hibernate-dev] Hibernate ORM 4.2.0.Final and 4.1.11.Final released
Hibernate ORM 4.2.0.Final and 4.1.11.Final were just released. The full changelogs can be viewed here: https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=12753 https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=12752 Note that this is the *final* release for 4.1.x. All development efforts and commits will now move to 4.2.x and 4.3.0 alpha. As usual, thank you to the community for all the support and hard work! JBoss Nexus: https://repository.jboss.org/nexus/content/groups/public/org/hibernate Maven Central: http://repo1.maven.org/maven2/org/hibernate/hibernate-core SourceForge: https://sourceforge.net/projects/hibernate/files/hibernate4 4.2.0.Final ZIP: http://sourceforge.net/projects/hibernate/files/hibernate4/4.2.0.Final/hibernate-release-4.2.0.Final.zip/download 4.2.0.Final TGZ: http://sourceforge.net/projects/hibernate/files/hibernate4/4.2.0.Final/hibernate-release-4.2.0.Final.tgz/download 4.1.11.Final ZIP: http://sourceforge.net/projects/hibernate/files/hibernate4/4.1.11.Final/hibernate-release-4.1.11.Final.zip/download 4.1.11.Final TGZ: http://sourceforge.net/projects/hibernate/files/hibernate4/4.1.11.Final/hibernate-release-4.1.11.Final.tgz/download Brett Meyer Red Hat Software Engineer, Hibernate ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Scanner contract
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 complicated, it works out of the box on many environment.
We AS came up with the virtual file I blew up and we decided to abstract
the contract away for JBoss AS. Then you guys worked on OSGi.
The idea behind getFilesInJar is that while we are scanning, we better
offer the stream instead of having to redo the IO (esp in the SE case).
Emmanuel
On Mon 2013-03-18 11:32, Steve Ebersole wrote:
> 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 delegate this resolution to the
> environment. In fact delegating the resolution to the environment
> is probably the best way to avoid the duplicate results. The reason
> it is complicated as is, is that the resolution of named mappings is
> done implicitly, rather than explicitly. So we call off to scan for
> mapping files,
>
> That complication, to me, is based on the understanding that
> "scanning" is all about finding additional stuff. But what we have
> is that scanning for classes and packages is all about finding
> additional, non-named things while it is the exact opposite in terms
> of scanning for mapping files where we do both: we find (and
> resolve) additional, non-named things *and* we resolve named things.
>
> At least that is how I read the code.
>
>
> On 03/18/2013 10:40 AM, Steve Ebersole wrote:
> >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, but the decision to ask the Scanner these questions for each
> >jar is inadvertently requiring Hibernate to be sensitive to these
> >protocols. In fact the current standard Scanner impl has explicit
> >handling for VFS protocol schemes. And for OSGi, it would require
> >that the single root URL (because again thats all we get) actually
> >encompasses the root jar *and* any other specified jars. Aka, `if
> >( "bundle".equals( urlProtocol ) ) {
> >doSomethingDrasticallyDifferent(); }...`.
> >
> >So take the EE case, which I know is true of JBoss. JBoss is the
> >one handing us the PersistenceUnitInfo (which is the thing that
> >backs the PersistenceUnitDescriptor we pass back to it in this
> >Scanner proposal). I don't think it is unreasonable that JBoss
> >understands the difference between
> >PersistenceUnitInfo#getPersistenceUnitRootUrl and
> >PersistenceUnitInfo#getJarFileUrls intrinsically (after all, it is
> >the one that gave us the PUI). By intrinsically I mean that it
> >already understands that there is a difference/distinction between
> >the root and any non-roots. So from there the question really is
> >whether expecting the Scanner to apply different scanning rules to
> >root versus not-root URLs constitutes "deep JPA knowledge". And
> >maybe that is different for each type of thing for which we scan.
> >
> >For classes e.g. nothing stops us from saying the the Scanner just
> >returns us everything it finds and that we then filter or weed
> >through it. For example, if it returns us descriptors for all the
> >classes it finds, we can apply the "only use that class if it (a)
> >came from a specified jar or (b) came from the root and
> >#excludeUnlistedClasses allows us to use them" logic ourselves.
> >Thats a trivial matter of us defining the ClassDescriptor contract
> >to tell us whether the class was found in the root or not:
> >
> >interface ClassDescriptor {
> >public String getClassName();
> >public NamedInputStream getNamedInputStream();
> >public boolean foundInRoot();
> >}
> >
> >But again, I dont think that the Scanner applying that simple
> >logic is really "deep JPA knowledge". But if everyone else agrees
> >it is, we can easily alleviate that via the above pattern.
> >
> >As for resources (orm.xml and hbm.xml files), I'd have to look a
> >little closer maybe. To be honest that is some of the code that
> >uses the "Map as an API" approach that makes me want to rip out my
> >hair, gouge out my eyes and leap off the nearest bridge :) It is
> >code like this code that has made me want to re-write what was
> >EJB3Configuration from scratch ever since I first started looking
> >at it. That and the fact that any time I ask anyone that had a
> >hand in writing that code anything about that code they simply
> >throw up their hands and say they don't know ;)
> >
>
