[Hibernate-JIRA] Commented: (EJB-46) PrePersist callback method not called if entity's primary key is null
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=com... ]
Emmanuel Bernard commented on EJB-46:
-------------------------------------
Note that I still consider such a usage hacky and is not considered a supported behavior (mainly becasue it highly depend on the Hibernate state discovery mechanism).
> PrePersist callback method not called if entity's primary key is null
> ----------------------------------------------------------------------
>
> Key: EJB-46
> URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-46
> Project: Hibernate Entity Manager
> Type: Bug
> Components: EntityManager
> Versions: 3.1beta1, 3.1beta2
> Environment: MySQL4, Sun JRE5, WinXP
> Reporter: Johan Steiner
> Assignee: Emmanuel Bernard
> Fix For: 3.2.2
> Attachments: EJB3EventListener.patch, EJB3EventListener_v2.patch
>
>
> Hi,
> the description is from http://forum.hibernate.org/viewtopic.php?t=944964 but I'm experiencing the exact same issue.
> *********************
> Hibernate does property validation such as not null checking before it does the EJB3 callback to prepersist/preupdate. I'm not sure if there's a good reason for this, but I think it would be particularly convenient if this behavior was reversed. IMHO it seems to better fit the semantics of the PRE callbacks, and it would allow callbacks to make modifications to the objects before they are persisted or updated -- modifications that might in turn effect the property validation Hibernate is doing.
> The "audit" example in the entity manager documentation does make changes to the object. What if these changes had effected the property validation done before the callback occurred? What if the object was in an invalid state before the callback, but a valid state after the callback? The latter case is what I think would be conveniently handled if hibernate did its property validation after prepersist/preupdate.
> Just two cents worth, obviously there are workarounds. This EJB3 stuff is looking great.
> Ryan
> P.S. This might also allow those of us who assign our own IDs to objects to do so automatically within a callback.
> *********************
> In my case I'm working with an entity like:
> public class MyEntity
> {
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$createdOn", insertable = true, updatable = false, nullable = false)
> private Date firstPersistedOn = null;
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$modifiedOn", insertable = true, updatable = false, nullable = true)
> private Date lastPersistedOn = null;
> @PrePersist
> public void onPrePersist()
> {
> firstPersistedOn = new Date();
> }
> @PreUpdate
> public void onPreUpdate()
> {
> lastPersistedOn = new Date();
> }
> }
> Hibernate throws:
> org.hibernate.PropertyValueException: not-null property references a null or transient value: MyEntity.firstPersistedOn
> at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:262)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:164)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114)
> at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:167)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:113)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:60)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540)
> at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:139)
> Regards,
> Johan
--
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
17 years, 10 months
[Hibernate-JIRA] Resolved: (EJB-46) PrePersist callback method not called if entity's primary key is null
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=all ]
Emmanuel Bernard resolved EJB-46:
---------------------------------
Resolution: Fixed
> PrePersist callback method not called if entity's primary key is null
> ----------------------------------------------------------------------
>
> Key: EJB-46
> URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-46
> Project: Hibernate Entity Manager
> Type: Bug
> Components: EntityManager
> Versions: 3.1beta1, 3.1beta2
> Environment: MySQL4, Sun JRE5, WinXP
> Reporter: Johan Steiner
> Assignee: Emmanuel Bernard
> Fix For: 3.2.2
> Attachments: EJB3EventListener.patch, EJB3EventListener_v2.patch
>
>
> Hi,
> the description is from http://forum.hibernate.org/viewtopic.php?t=944964 but I'm experiencing the exact same issue.
> *********************
> Hibernate does property validation such as not null checking before it does the EJB3 callback to prepersist/preupdate. I'm not sure if there's a good reason for this, but I think it would be particularly convenient if this behavior was reversed. IMHO it seems to better fit the semantics of the PRE callbacks, and it would allow callbacks to make modifications to the objects before they are persisted or updated -- modifications that might in turn effect the property validation Hibernate is doing.
> The "audit" example in the entity manager documentation does make changes to the object. What if these changes had effected the property validation done before the callback occurred? What if the object was in an invalid state before the callback, but a valid state after the callback? The latter case is what I think would be conveniently handled if hibernate did its property validation after prepersist/preupdate.
> Just two cents worth, obviously there are workarounds. This EJB3 stuff is looking great.
> Ryan
> P.S. This might also allow those of us who assign our own IDs to objects to do so automatically within a callback.
> *********************
> In my case I'm working with an entity like:
> public class MyEntity
> {
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$createdOn", insertable = true, updatable = false, nullable = false)
> private Date firstPersistedOn = null;
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$modifiedOn", insertable = true, updatable = false, nullable = true)
> private Date lastPersistedOn = null;
> @PrePersist
> public void onPrePersist()
> {
> firstPersistedOn = new Date();
> }
> @PreUpdate
> public void onPreUpdate()
> {
> lastPersistedOn = new Date();
> }
> }
> Hibernate throws:
> org.hibernate.PropertyValueException: not-null property references a null or transient value: MyEntity.firstPersistedOn
> at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:262)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:164)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114)
> at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:167)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:113)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:60)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540)
> at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:139)
> Regards,
> Johan
--
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
17 years, 10 months
[Hibernate-JIRA] Updated: (EJB-46) PrePersist callback method not called if entity's primary key is null
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/EJB-46?page=all ]
Emmanuel Bernard updated EJB-46:
--------------------------------
Summary: PrePersist callback method not called if entity's primary key is null (was: Property Validation should happen after PrePersist/PreUpdate)
Assign To: Emmanuel Bernard
Rename case, since the initial description has been fixed a long time ago and the discussion have slipped.
> PrePersist callback method not called if entity's primary key is null
> ----------------------------------------------------------------------
>
> Key: EJB-46
> URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-46
> Project: Hibernate Entity Manager
> Type: Bug
> Components: EntityManager
> Versions: 3.1beta1, 3.1beta2
> Environment: MySQL4, Sun JRE5, WinXP
> Reporter: Johan Steiner
> Assignee: Emmanuel Bernard
> Fix For: 3.2.2
> Attachments: EJB3EventListener.patch, EJB3EventListener_v2.patch
>
>
> Hi,
> the description is from http://forum.hibernate.org/viewtopic.php?t=944964 but I'm experiencing the exact same issue.
> *********************
> Hibernate does property validation such as not null checking before it does the EJB3 callback to prepersist/preupdate. I'm not sure if there's a good reason for this, but I think it would be particularly convenient if this behavior was reversed. IMHO it seems to better fit the semantics of the PRE callbacks, and it would allow callbacks to make modifications to the objects before they are persisted or updated -- modifications that might in turn effect the property validation Hibernate is doing.
> The "audit" example in the entity manager documentation does make changes to the object. What if these changes had effected the property validation done before the callback occurred? What if the object was in an invalid state before the callback, but a valid state after the callback? The latter case is what I think would be conveniently handled if hibernate did its property validation after prepersist/preupdate.
> Just two cents worth, obviously there are workarounds. This EJB3 stuff is looking great.
> Ryan
> P.S. This might also allow those of us who assign our own IDs to objects to do so automatically within a callback.
> *********************
> In my case I'm working with an entity like:
> public class MyEntity
> {
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$createdOn", insertable = true, updatable = false, nullable = false)
> private Date firstPersistedOn = null;
> @Basic(temporalType = TemporalType.TIMESTAMP)
> @Column(name = "$modifiedOn", insertable = true, updatable = false, nullable = true)
> private Date lastPersistedOn = null;
> @PrePersist
> public void onPrePersist()
> {
> firstPersistedOn = new Date();
> }
> @PreUpdate
> public void onPreUpdate()
> {
> lastPersistedOn = new Date();
> }
> }
> Hibernate throws:
> org.hibernate.PropertyValueException: not-null property references a null or transient value: MyEntity.firstPersistedOn
> at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:262)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:164)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114)
> at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:167)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:113)
> at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:60)
> at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:540)
> at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:139)
> Regards,
> Johan
--
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
17 years, 10 months
LocalOnlyContextFactory -- Local server is not initialized
by kal stevens
Could someone help me out with what this might mean?
I am trying to setup an EJB3 project, and I get this.
Caused by: javax.naming.NamingException: Local server is not initialized
at org.jnp.interfaces.LocalOnlyContextFactory.getInitialContext(
LocalOnlyContextFactory.java:45)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java
:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java
:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:175)
at org.hibernate.util.NamingHelper.getInitialContext(NamingHelper.java
:28)
at org.hibernate.transaction.JTATransactionFactory.configure(
JTATransactionFactory.java:38)
... 27 more
Right now I am running it through intellij.
Is there a prerequisit for setting this up or is it dependent on JBoss or
Seam?
Thanks
Kal
17 years, 10 months
[Hibernate-JIRA] Created: (HBX-871) Publishing to JBoss broken
by Olivier Roth (JIRA)
Publishing to JBoss broken
--------------------------
Key: HBX-871
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-871
Project: Hibernate Tools
Type: Bug
Components: eclipse
Versions: 3.2beta9
Environment: eclipse 3.2.1, wst 1.5.2, jdk5
Reporter: Olivier Roth
After upgrading from Hibernate Tools-3.2.0.beta8 to Hibernate Tools-3.2.0.beta9a I can't publish ear Files to JBoss Server anymore.
Logfile says:
java.lang.IllegalAccessError: tried to access method
org.eclipse.wst.server.core.util.ProjectModule.getModuleResources(Lorg/eclipse/core/runtime/IPath;Lorg/eclipse/core/resources/IContainer
;)[Lorg/eclipse/wst/server/core/model/IModuleResource; from class org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable
at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.getOptimizedMembers(J2EEFlexProjDeployable.java:746)
at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.members(J2EEFlexProjDeployable.java:162)
at org.eclipse.wst.server.core.internal.ModulePublishInfo.fillCache(ModulePublishInfo.java:212)
at org.eclipse.wst.server.core.internal.ModulePublishInfo.getDelta(ModulePublishInfo.java:261)
at org.eclipse.wst.server.core.internal.ServerPublishInfo.getDelta(ServerPublishInfo.java:274)
at org.eclipse.wst.server.core.internal.Server.getPublishedResourceDelta(Server.java:1026)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.getPublishedResourceDelta(ServerBehaviourDelegate.java:491)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:555)
at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:862)
at org.eclipse.wst.server.core.internal.Server.publish(Server.java:850)
at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:142)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
--
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
17 years, 10 months
[Hibernate-JIRA] Created: (ANN-513) Multiple class validators of the same annotationtype
by Edwin van der Elst (JIRA)
Multiple class validators of the same annotationtype
----------------------------------------------------
Key: ANN-513
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-513
Project: Hibernate Annotations
Type: Improvement
Components: validator
Versions: 3.2.1
Reporter: Edwin van der Elst
Priority: Minor
I have a suggestion for the following problem:
I created an Validator to check if a 'date'> 'another date'
The annotation looks like this:
@After(property="endDate", after="beginDate", message="End should be after begin")
Since it involves 2 properties, it is a class-level validation.
Now....
I want multiple 'after' validations on a single bean.
But that is not possible (you can only place an annotation once on a class).
My proposal is to add an annotation 'Validations':
@Validations( {@After(...), @After(..)} )
I could do the multiple validations in a single validatorclass, but I want all the messages added to the invalidValues array, not a single message.
This change would also require changes in the ClassValidator class.
What do you think of this proposal? Should I add it to Jira (I can propably implement it if there are no objections to the required changes)
--
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
17 years, 10 months
