JPA API jar
by Steve Ebersole
I just released the "Final" JPA API jar. It is still using the old
naming scheme in terms of repo artifacts; so this one is:
groupId : org.hibernate.javax.persistence
artifactId : hibernate-jpa-2.1-api
version : 1.0.0.Final
I think moving forward we will move to a slightly different scheme. The
group will stay the same, but:
artifactId : hibernate-jpa-api
version : {jpaVersion}.0.Final
Also, rather than naming the non-final releases after the draft they
come from (because often they span Drafts or partially include Drafts,
etc) we'll just go to a straight Alpha/Beta/CR scheme.
I went ahead and use the new scheme for the tag, because it is more
concise. So the tag is under 2.1.0.Final.
10 years, 9 months
OGM at Soft Shake
by Guillaume SCHEIBEL
Hi guys,
I'm glad to announce/let you know I'll be presenting OGM at Soft Shake
(Geneva, Switzerland) in October.
Cheers
Guillaume
10 years, 9 months
JBCRA Voting
by Steve Ebersole
Just a reminder that the JBoss Community Recognition Awards voting is
still open through Friday the 26th. Please take the time to go and vote
for your favorite Hibernate community contributors if you have not yet
had the chance: https://www.jboss.org/jbcra/vote.html
Thanks!
10 years, 9 months
report of a WildFly memory leak that may come from hibernate service loader...
by Scott Marlow
http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html
contains the details about deployment level classes are leaking (CDI
beanmanager passed into deployment, bean validation factory, others...).
In WildFly 8, We do have a
META-INF/services/org.hibernate.engine.transaction.jta.platform.spi.JtaPlatformProvider
file that contains org.jboss.as.jpa.hibernate4.DefaultJtaPlatform
The org.jboss.as.jpa.hibernate4.DefaultJtaPlatform is a system module
class but could also be an application deployment class.
Question: Do we have a way to unload services that have been loaded
when the original classloader (deployment) is no longer needed (e.g.
when SessionFactory is closed)?
I'm not sure that would help for the leak that I am reproducing which
could be a different problem.
By the way, this is with Hibernate ORM 4.3.0.Beta3.
Scott
10 years, 9 months
the usage scope of Integrator
by Strong Liu
see org.hibernate.test.annotations.embeddables.EmbeddableIntegratorTest
this test is using Integrator to registerTypeOverride, in the middle of SF initializing, after Configuration / Metadata built.
so, firstly I want to confirm if this is an expected use case of Integrator, since at this time, the metadata is supposed to resolved, and no way to apply the new overrided types.
( This test passes w/ Configuration, since the attribute type is delayed to the persister initialize time, and the Value holds a reference of org.hibernate.cfg.Configuration.MappingsImpl, which holds a reference to the Configuration#typeResolver.
but this also doesn't sound right, since SF also has a typeResolver, which is a copy of Configuration#typeResolver, and it is copied before the Integrator applied. )
the process looks like:
1. Configuration creates a new instance of TypeResolver and load default types ( including dialect overrided types and org.hibernate.metamodel.spi.TypeContributions )
2. SF create a new instance of TypeResolver and copy all types from Configuration.typeResolver
3. apply integrator and add/override new types to the Configuration.typeResolver, here we get mismatch between SF.typeResolver and Configuration.typeResolver
I checked the git history / JIRA and trying to find the background of this test, but nothing.
if you guys confirm this is not a valid use case, then I'd suggest:
1. give Integrator a better name and clearly add something to the (java) doc say the expect usage of this Integrator ( maybe DO NOT TRY TO CHANGE THE STATE OF METADATA / CONFIGURATION AT THIS SATGE?)
2. move the IntegratorService to the SessionFactoryServiceRegistry?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
10 years, 9 months
