7:32 a.m.
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by
annotations. We would appreciate if this mapping could be done by hbm xml files. Using
this approach the POJO won't be bound to Envers annotations. They simply would be
left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client
tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see
only two options objects may leave the server tier. First by a copy to an annotation less
value object, which is consuming performance and resources. Second by coping / using
Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach
Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in
client server communication model transformations like coping objects or transforming them
to other formats like XML, e.g. like web services does. The easiest way would be to just
serialize the Java POJO objects. But never then less the client should only depend
(logically) on the server API. It is not intended to rely on a specific server
implementation.
--
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
3:55 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3887) Envers hbm xml based configuration
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887?page=c...
]
Anthony DePalma commented on HHH-3887:
--------------------------------------
This would be an excellent addition and is currently the only reason why we are unable to
use Envers in our applications.
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5.0.Beta-1
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by
annotations. We would appreciate if this mapping could be done by hbm xml files. Using
this approach the POJO won't be bound to Envers annotations. They simply would be
left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client
tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see
only two options objects may leave the server tier. First by a copy to an annotation less
value object, which is consuming performance and resources. Second by coping / using
Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach
Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in
client server communication model transformations like coping objects or transforming them
to other formats like XML, e.g. like web services does. The easiest way would be to just
serialize the Java POJO objects. But never then less the client should only depend
(logically) on the server API. It is not intended to rely on a specific server
implementation.
--
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
8:31 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3887) Envers hbm xml based configuration
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887?page=c...
]
Helmut Pasch commented on HHH-3887:
-----------------------------------
Yes, it would be. The approach Envers uses to audit entities is a good one.
I lately explored Spring DATA JPA.This Spring Project also aims to auditing entities. I
was indeed a little bit surprised they announced this feature being implemented by AOP.
Looking a bit closer I discovered that every entity must inherit from a generic Class
called Persistable<ID>. Well, I couldn't bring this together AOP and inheritance
are still two different things.
I would categorize Envers as a technology based on AOP technologies. The good thing about
this is, that AOP technologies enable us to extract (mainly technical) aspects out of the
plain POJOs. The POJOs will stay as much complex as your problem domain demands it. Coming
back to the Spring approach, especially inheritance is a feature, we only want use for
abstractions within our problem domain, not for technical problems.
To emphasise this we are very happy with Hibernate and we also adapted Envers. We are
still looking forward to having sometimes this xml based configuration feature.
To point that out, XML based configuration is very well suited for ORM. This way we could
cleanly extract the technically aspects, the persistent aspect and (more or less
technical) the auditing aspect, from our POJOs. To explain our our understanding:
"JSR 303: Bean Validation" is a feature were we appreciate the annotation based
approach. In this case the capabilities of the domain model (the POJOs) to build better
comprehensive abstractions are really improved. Looking back to the annotation based
approach of Envers, we see it more like a burden to handle the aspect within the code.
In some project this burden evolve to a real show stopper. We are still interested in
(programmatically) manipulation and reconfiguration of the auditing aspect, in XML it
would be very fine and easy to do this.
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5.0.Beta-1
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by
annotations. We would appreciate if this mapping could be done by hbm xml files. Using
this approach the POJO won't be bound to Envers annotations. They simply would be
left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client
tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see
only two options objects may leave the server tier. First by a copy to an annotation less
value object, which is consuming performance and resources. Second by coping / using
Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach
Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in
client server communication model transformations like coping objects or transforming them
to other formats like XML, e.g. like web services does. The easiest way would be to just
serialize the Java POJO objects. But never then less the client should only depend
(logically) on the server API. It is not intended to rely on a specific server
implementation.
--
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
7:01 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3887) Envers hbm xml based configuration
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887?page=c...
]
Wölfle commented on HHH-3887:
-----------------------------
This feature would be great since we are using the Hibernate XML mapping only for the same
reasens as Helmut Pasch described. Thus it is currently not possible for us to use
Envers.
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5.0.Beta-1
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by
annotations. We would appreciate if this mapping could be done by hbm xml files. Using
this approach the POJO won't be bound to Envers annotations. They simply would be
left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client
tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see
only two options objects may leave the server tier. First by a copy to an annotation less
value object, which is consuming performance and resources. Second by coping / using
Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach
Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in
client server communication model transformations like coping objects or transforming them
to other formats like XML, e.g. like web services does. The easiest way would be to just
serialize the Java POJO objects. But never then less the client should only depend
(logically) on the server API. It is not intended to rely on a specific server
implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4578
days inactive
5500
days old
hibernate-issues@lists.jboss.org
3 comments
3 participants
participants (3)
-
Anthony DePalma (JIRA) -
Helmut Pasch (JIRA)
-
Wölfle (JIRA)