Discovering/configuring package-info
by Christian Bauer
Trying to upgrade to 4.3-SNAPSHOT, the EntityManagerFactoryBuilderImpl.indexResource() is failing for my persistence.xml configuration in Java SE with Persistence.createEntityManagerFactory():
<persistence-unit name="SimplePU">
<jta-data-source>myDS</jta-data-source>
<class>org.jpwh.model</class>
<class>org.jpwh.model.simple.Item</class>
<class>org.jpwh.model.simple.User</class>
<class>org.jpwh.model.simple.Bid</class>
<class>org.jpwh.model.simple.Address</class>
<class>org.jpwh.model.simple.Category</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
</persistence-unit>
The <class>org.jpwh.model</class> 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.<init>(EntityManagerFactoryBuilderImpl.java:205)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(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.<init>(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…
11 years, 1 month
Scanner contract
by 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 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.
11 years, 1 month
merge master onto metamodel regularly
by Strong Liu
Hi there,
I just finished the merge of master onto metamodel, and there were tons of conflicts :(
I'm suggesting we ( well, I'm voluntary to do this ) do the merge by weekly, to minimise the conflicts
I will do the merge in every monday ( my time ) if no objections, so, others living in U.S. and Europe can see the merged branch when starts the Monday work
WDYT?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
11 years, 1 month
[OGM] Ogm mass indexer, how to convert Tuple/EntityKey to Entity/Id?
by Davide D'Alto
Hello,
I'm trying to create a mass indexer that could work with OGM.
The idea is to have a way to scan all the element of a certain type in
the data store and index them, this way it would be possible to create
an index starting from an existing populated data store.
The first prototype idea is to add a method to the GridDialect, something like:
GridDialect#forEachTuple(Consumer consumer, String... tableName)
Where the Consumer is an interface with a method Consumer#consume(Tuple tuple)
The consumer will execute the indexing of the found tuple.
The problem that I have now is how to convert the Tuple to the
corresponding entity so that I can index it using hibernate search.
An alternative idea would be to use the EntityKey and obtain the id
instead of using the Tuple.
Is there a method somewhere that I can use to obtain an entity from a Tuple?
Thanks,
Davide
11 years, 1 month
Require OSGi 4.3 for ORM?
by Brett Meyer
During initial discussions about ORM in OSGi [1], we had targeted OSGi 4.2. However, in order to completely handle bundle scanning [2], we need an API that was not introduced until OSGi 4.3 (BundleWiring). There's nothing like it in 4.2 and it's not easily/reliably replaced. Although I believe 4.2 is still used in the community, most containers/runtimes (including JBoss OSGi) now support 4.3 and (very soon) 5.0.
We're obviously not interested in branching hibernate-osgi to support multiple OSGi versions. Although 4.2 is still used, should we require 4.3? Without the ability to exhaustively and reliably scan the bundles for resources, our capabilities are limited anyway. Further, if a user still requires 4.2, they can always wrap Hibernate as an OSGi bundle in any of the legacy methods.
[1] https://hibernate.atlassian.net/browse/HHH-7527
[2] https://hibernate.atlassian.net/browse/HHH-7993
Brett Meyer
Red Hat Software Engineer, Hibernate
11 years, 1 month
Search -> ORM lock -> WARN logged
by Sanne Grinovero
Hi all,
as these users are reporting:
https://forum.hibernate.org/viewtopic.php?f=1&t=1025404
apparently the MasIndexer in Hibernate Search triggers this log, but I
don't actually want it to lock I just want to re-attach objects to the
Session so I'm using Lock.NONE.
I'm not familiar with this, could someome tell if we should
a) lower the log severity in ORM
b) fix something we're not doing properly in Search
c) maybe make sure we log it only once?
d) add a filthy looking Lock.NONE_AND_QUIET :-P
Cheers,
Sanne
11 years, 1 month
