[Hibernate-JIRA] Created: (HHH-4797) Backref properties should be ignored when building the JPA 2 metamodel (leading atm to java.lang.IllegalArgumentException: Cannot determine java-type from given member [null])
by Emmanuel Bernard (JIRA)
Backref properties should be ignored when building the JPA 2 metamodel (leading atm to java.lang.IllegalArgumentException: Cannot determine java-type from given member [null])
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-4797
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4797
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.5.0-Beta-3
Reporter: Emmanuel Bernard
Assignee: Emmanuel Bernard
Fix For: 3.5.0-Beta-4
When I specifically run VersionsJoinTableRangeComponentNamingTest
I've got a
java.lang.IllegalArgumentException: Cannot determine java-type from given member [null]
at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:591)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:671)
at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:661)
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:542)
at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:81)
at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:177)
at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:79)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:752)
at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:94)
at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:82)
The member is null because the "property" has a backref getter and hence no member is returned by NORMAL_MEMBER_RESOLVER. I think we should ignore backref properties
Does that make sense? If we agree, I will go and apply a fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4803) Injecting target into proxy in org.hibernate.envers.tools.Tools#getTargetFromProxy can cause duplicate entities in session
by Gail Badner (JIRA)
Injecting target into proxy in org.hibernate.envers.tools.Tools#getTargetFromProxy can cause duplicate entities in session
--------------------------------------------------------------------------------------------------------------------------
Key: HHH-4803
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4803
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.0-Beta-3
Reporter: Gail Badner
I believe that problems can arise if Tools.getTargetFromProxy(...) injects the target into the proxy. It is possible that the target entity will be duplicated in the session and cause an exception to be thrown.
Here is a (very contrived) scenario where this can happen:
X has a lazy many-to-one association with Y with cascade="all"
Both X and Y have a non-lazy many-to-one association with Z with cascade == "all"
s: original session
sTemp: temporary session
The entities, x, y, and z have already been persisted with the following associations:
x.y == y
x.z == null
y.z == z
In a new session/transaction:
X x = ( X ) s.get( X.class, xId );
Y yProxy = x.getY();
Z z = ( Z ) s.get( Z.class, zId );
z.setName( "new name" );
x.setZ( z );
s.update( x );
When changes to x are audited, Tools.getTargetFromProxy(...) is called to get the entity target for yProxy from a temporary session (sTemp) and inject that target back into yProxy.
Because of the non-lazy association between Y and Z, yProxy.z is also initialized in the temporary session. yProxy.z should refer to the same instance as z, but they are different instances because they were loaded into different sessions. In addition, the two instances have different state:
- z has a non-flushed update
- yProxy.z has the same state as loaded (w/o the update)
In other words:
z != yProxy.z && ! z.equals( yProxy.z )
Later, when an operation cascades to yProxy.z (e.g., during flush) and it's added to the session, an exception will be thrown because an updated version of the same entity is already present.
The safest way to avoid subtle problems like this is for Tools.getTargetFromProxy(...) to leave the proxy uninitialized (instead of injecting the target).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4801) HeuristicMixedException detection/improvement + special case for PostgreSQL driver
by Maillefer Jean-David (JIRA)
HeuristicMixedException detection/improvement + special case for PostgreSQL driver
----------------------------------------------------------------------------------
Key: HHH-4801
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4801
Project: Hibernate Core
Issue Type: Improvement
Affects Versions: 3.3.1
Environment: hibernate-core: 3.3.1.GA
hibernate-annotations: 3.4.0.GA
Reporter: Maillefer Jean-David
Priority: Minor
Attachments: logs.txt
It would be nice to check, on new transaction's participant arrival, if it's XA-disabled and it's not the first XA-disabled participant. In which case, throw an Exception related to transaction atomicity non guaranteed (except if some config option in [com.arjuna.ats.arjuna.coordinator] allow it).
"XA-disabled" may means more than expected. For example, when the postgresql's parameter max_prepared_transactions is 0 (which is the default from version 8.4), the prepared transactions are disabled and all clients (including hibernate) will be unable to do prepared transactions (thus to participate in XA transactions). And this happens even when using the org.postgresql.xa.PGXADataSource as XA datasource class, since it's a server .
But in this case, it is very easy for the XA transaction coordinator to detect that postgresql can't participate in XA transactions (issuing a "show max_prepared_transactions" command, checking this value not 0, and displaying an explicit error message if it's not the case).
This feature (more accurate and earlier error report) could avoid (without being pessimistic) Hibernate transaction manager starting XA transaction that may be impossible to do atomically.
Sample scenario:
@Entity
public class MyEntity {
@Id
int id;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
}
@Stateless
public class MyStatelessBean {
@PersistenceContext
private EntityManager entityManager;
@Timeout
public void timeout(javax.ejb.Timer timer) {
// nothing needed
}
public void launchTest() {
// transaction involving first XA participant: the postgresql database (XA, but prepared transaction may be disabled on server. This means behaves like not-XA)
MyEntity myEntity = new MyEntity();
myEntity.setId(34);
entityManager.persist(myEntity);
// involve the second XA participant: the JBoss timer datastore (not XA [else everything would work since the coordinator allows at maximum one not-XA])
TimerService timerService = context.getTimerService();
timerService.createTimer(2500, );
}
}
Calling MyStatelessBean.runTest() in a transaction will cause many warnings from the arjuna coordinator, followed by a javax.transaction.HeuristicMixedException (see attachement for full logs + stacktrace).
There is an additional problem: this unended transaction is kept in the server waiting to be fixed and the coordinator logs a warning message very often about it. These transactions are impossible to abort and they must be removed from the JBoss datastore manually. If many such XA transaction happen, they add all their unended XA transaction's state in the datastore, filling this datastore and the logs.
The warning looks like this:
16:00:23,681 WARN [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 28, 26, 49454551102535510210110054585797485852985210099569748585157564551102535510210110054585797485852985210099569748585157100 >
Wouldn't it be better to not start such XA transactions at all since we cannot atomically rollback after the second non-XA participant has started it's transaction (and changes are done by the participants).
Note: this feature request follows my comment in the wiki http://community.jboss.org/wiki/TxNonSerializableXAResource.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4800) @Timeout method callbacks accessible only if public, against the EJB spec
by Maillefer Jean-David (JIRA)
@Timeout method callbacks accessible only if public, against the EJB spec
-------------------------------------------------------------------------
Key: HHH-4800
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4800
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.3.1
Environment: hibernate-core: 3.3.1.GA
hibernate-annotations: 3.4.0.GA
Reporter: Maillefer Jean-David
Priority: Minor
The EJB 3 spec says that a @Timeout method callbacks can have any level access, but hibernate find this method only if it's access is public.
What the spec says:
- "Enterprise JavaBeans 3.0, Final Release", 18.2.2 Timeout Callbacks, p 484: "A Timeout method can have public, private, protected, or package level access"
- "Enterprise JavaBeans 3.1, Final Release", 18.2.5.3 Timeout Callback Method Requirements, p. 520: "A timeout callback method can have public, private, protected, or package level access"
Sample stateless bean that will cause an error (at deployment time) :
@Stateless
public class MyBean {
@Timeout
// private should be ok, but a bug prevent it
private void timeout(Timer timer) {
// timeout code here
}
}
Workaround: use public access level.
The (abbreviated) stacktrace of the resulting error:
org.jboss.deployers.spi.DeploymentException: Error deploying SITEJB.jar: No method timeout(javax.ejb.Timer timer) found on bean MyBean
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: No method timeout(javax.ejb.Timer timer) found on bean FdsDAOBean
at org.jboss.ejb3.EJBContainer.getTimeoutCallback(EJBContainer.java:995)
at org.jboss.ejb3.stateless.StatelessContainer.initializeTimeout(StatelessContainer.java:184)
at org.jboss.ejb3.stateless.StatelessContainer.<init>(StatelessContainer.java:114)
at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
at org.jboss.ejb3.Ejb3DescriptorHandler.getStatelessContainer(Ejb3DescriptorHandler.java:499)
at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:203)
at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:718)
at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:669)
at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:651)
at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:614)
at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
... 29 more
Caused by: java.lang.NoSuchMethodException: ch.etc.sit.impl.service.FdsDAOBean.timeout(javax.ejb.Timer)
at java.lang.Class.getMethod(Unknown Source)
at org.jboss.ejb3.EJBContainer.getTimeoutCallback(EJBContainer.java:987)
... 40 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4625) Use of maven-injection-plugin intermittently leads to build failures
by Steve Ebersole (JIRA)
Use of maven-injection-plugin intermittently leads to build failures
--------------------------------------------------------------------
Key: HHH-4625
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4625
Project: Hibernate Core
Issue Type: Bug
Components: build
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.3.x, 3.5
Symptom is a failure like:
[INFO] Unable to replace method body
Embedded error: [source error] javassist.NotFoundException: java.lang.String
[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to replace method body
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to replace method body
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo$MethodBodyReturnReplacementTarget.inject(BytecodeInjectionMojo.java:206)
at org.jboss.maven.plugins.injection.AbstractInjectionMojo.execute(AbstractInjectionMojo.java:48)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: javassist.CannotCompileException: [source error] javassist.NotFoundException: java.lang.String
at javassist.CtBehavior.setBody(CtBehavior.java:368)
at javassist.CtBehavior.setBody(CtBehavior.java:334)
at org.jboss.maven.plugins.injection.BytecodeInjectionMojo$MethodBodyReturnReplacementTarget.inject(BytecodeInjectionMojo.java:203)
... 19 more
Caused by: compile error: javassist.NotFoundException: java.lang.String
at javassist.compiler.Javac.compileBody(Javac.java:228)
at javassist.CtBehavior.setBody(CtBehavior.java:360)
... 21 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[Hibernate-JIRA] Created: (HHH-4794) "is empty" with inner join generates invalid sql select and invalid results
by Ramon Casha (JIRA)
"is empty" with inner join generates invalid sql select and invalid results
---------------------------------------------------------------------------
Key: HHH-4794
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4794
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.3.2
Environment: Hibernate version as provided with Netbeans 6.8 (Hibernate EntityManager 3.3.2.GA, Hibernate Annotations 3.3.1.GA)
DBMS: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production; With the OLAP and Data Mining options
Reporter: Ramon Casha
Attachments: testcase.zip
Given two simple entities, Master and Detail which have a OneToMany relationship:
The following JPQL query...
Select T from Master T, in(T.details) D where D is empty
generates the following SQL:
[1] select master0_.id as id0_
[2] from Master master0_
[3] inner join Detail details1_ on master0_.id=details1_.master_id
[4] where not (exists (select details1_.id from Detail details1_));
Line 4 is incorrect! The alias created there (details1_) is DIFFERENT from details1_ on line 3, so the subquery runs over the entire table, not the inner-joined table in line 3.
Testcase included
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months