ci.hibernate resource locks configuration
by Sanne Grinovero
Hi all,
I am enabling the "resources lock exclusion" plugin: this allows to
specify - using a string - a resource that a specific build requires
for exclusive access, preventing parallel execution of multiple builds
using the same resource.
I'm enabling two resources specifically:
- JGROUPS
- JBOSSAS
(literally)
Please keep that in mind when
a) creating new jobs
b) adding new tests using any such resource in a project which doesn't have any
For example, Hibernate Search includes some tests which create a
JGroups communication channel - either explicitly or by using
Infinispan - and if another build was run at the same time they would
fail as JGroups would automatically connect to the other running test,
setting up an unpredictable state.
So by enabling "JGROUPS" as a required exclusive resource, if any
other project needing the same could declare the same resource usage
we can prevent them to be run in parallel.
JBOSSAS is defined by projects using Arquillian; I enabled it only on
OGM and Search: any more needing it?
The good aspect is that by doing so I can re-enable parallel execution
and Jenkins should figure out which builds it is allowed to run
instead, without wasting CI time.
Side effects: expects several fail reports in the coming hours, as I
*thought* I got it right but actually made a mistake, triggering many
parallel builds :-)
Sanne
12 years, 4 months
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.
12 years, 5 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
12 years, 5 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!
12 years, 5 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
12 years, 5 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
12 years, 5 months
