Pinaki,
I've been on vacation again for a week which is why I'm late replying.
I think there must be a way to get hold of the original object since
that's the object I need to audit log. An unmanaged POJO is fine for my
purposes since I just want to serialize it. I will then persist it to a
Hi Bengt,
It is possible (with some effort :) to offer a different POJO y that holds
the original state of a managed POJO x *when* x entered a persistence
context. But y can not be managed by the same context, because x is already
present in that context. So y will be essentially an unmanaged
perhaps http://jpasecurity.sourceforge.net/
can help you to control access as JPA xxtension, but it's more for security
auditing than just logging
regards
Frank
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Audit-log-with-OpenJPA-tp6557932p6632956.html
Sent from the
Interesting - will definitely take a look.
/Bengt
Den 29 jul 2011 19:24 skrev pif frank.pien...@googlemail.com:
perhaps http://jpasecurity.sourceforge.net/
can help you to control access as JPA xxtension, but it's more for
security
auditing than just logging
regards
Frank
--
View this
into the StateManager stuff a big time and am ready to
help out once we know how we'd like to solve this.
LieGrue,
strub
--- On Tue, 7/26/11, Bengt Rodehav be...@rodehav.com wrote:
From: Bengt Rodehav be...@rodehav.com
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Tuesday
Hello Pinaki,
Thanks for looking into this. What you are suggesting seems useful and it
would be really nice if this functionality is supported in the future.
However, I can't see how it directly solves my problem. What I'm trying to
do in my audit log is to save a serialized form of my entity -
Hi Bengt,
This thread has grown too lengthy for me to find where was the @PreUpdate
code.
For better convergence, please create a JUnit test and post it to
OPENJPA-2030 [1]
[1] https://issues.apache.org/jira/browse/OPENJPA-2030
-
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this
Yes, you're right Pinaki.
I've attached a test case to the JIRA now. I'm very interested in your
verdict...
/Bengt
2011/7/26 Pinaki Poddar ppod...@apache.org
Hi Bengt,
This thread has grown too lengthy for me to find where was the @PreUpdate
code.
For better convergence, please create a
Hi Bengt,
I find that accessing the old state is possible using internal mechanics
-- but could not find a way to do it from the current API unless I expose
some internals. After a bit of deliberation, I am suggesting that we add the
following method to SaveFieldManager.
/**
* Gets the
Hello again Mark and Pinaki,
I've tried with the properties you mentioned Mark (and the one you mentioned
in your blog Pinaki). B ut I can see no difference. I also switched from
OpenJPA 2.0.1 to 2.1.1 but still no difference. My persistence.xml looks
like this:
*?xml version=1.0
I'm currently in Turkey on vacation but will try when I get back to Sweden.
/Bengt
Den 19 jul 2011 17:48 skrev Pinaki Poddar ppod...@apache.org:
Hi Bengt,
It is not obvious to me how DetachState related options will impact
in-transaction entities. But I am interested to know the result of your
committed (got
my time eaten up by a few other Apache projects lately).
LieGrue,
stru
--- On Sat, 7/16/11, Bengt Rodehav be...@rodehav.com wrote:
From: Bengt Rodehav be...@rodehav.com
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Saturday, July 16, 2011, 8:40 PM
Hi Bengt,
It is not obvious to me how DetachState related options will impact
in-transaction entities. But I am interested to know the result of your
experiment with the options Mark has suggested.
I will recommend you make sure the following
1. Enhance at build time
2. Set
working
in a cluster or load balancer scenario.
LieGrue,
strub
--- On Tue, 7/19/11, Pinaki Poddar ppod...@apache.org wrote:
From: Pinaki Poddar ppod...@apache.org
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Tuesday, July 19, 2011, 2:47 PM
Hi Bengt
working
in a cluster or load balancer scenario.
LieGrue,
strub
--- On Tue, 7/19/11, Pinaki Poddar ppod...@apache.org wrote:
From: Pinaki Poddar ppod...@apache.org
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Tuesday, July 19, 2011, 2:47 PM
Hi Bengt
Bengt,
I had been busy with other things not to address your question.
Did you read the very two last lines of the blog? They have the right
configuration options required for the restorable state. Let me know if
things do not work even after you have used those two directives.
-
Pinaki
Did you have a suggestion regarding this Pinaki - or does OpenJPA only keep
track of changed values - not the whole original object?
/Bengt
2011/7/15 Bengt Rodehav be...@rodehav.com
I don't understand Pinaki.
The this pointer is the current version of the object (the one that is
about to be
to get the correct state in
OPENJPA-1873. Not sure how much of this patch got already committed (got my
time eaten up by a few other Apache projects lately).
LieGrue,
stru
--- On Sat, 7/16/11, Bengt Rodehav be...@rodehav.com wrote:
From: Bengt Rodehav be...@rodehav.com
Subject: Re: Audit log
I don't understand Pinaki.
The this pointer is the current version of the object (the one that is
about to be persisted) right? I want the previous version of the object. I
have used your code from the blog (and added some of course) like this:
*
PersistenceCapable currentState =
Hi again Jim,
2011/7/14 Jim Talbut jtal...@spudsoft.co.uk
On 13/07/2011 21:14, Pinaki Poddar wrote:
Yes. Any audit facility needs to have a snapshot of the entity when it
entered a persistence context, so at @PreUpdate or at any other time
points,
it can figure out what has essentially
Jim,
I was making generic statements about audit and was not meant to address
the specific approach you might have taken to suit your needs. I will take a
closer look at the approach you have come up with.
About 'delta computation', however, I find OpenJPA provides strong feature
via its
Pinaki,
Thanks for your very insightful post. It feels like this is the way to go
then. I'll stick with this approach for now and try to follow the
development of JPA and OpenJPA.
Thanks for your help,
/Bengt
2011/7/14 Pinaki Poddar ppod...@apache.org
Jim,
I was making generic statements
Sorry Pinaki - not done with me yet
My intention was to audit log the whole object (serialized though) but the
method:
*SaveFieldManager.getState()*
returns an object where only the changed fields are initialized (seems like
it anyway). Is there a way I can get hold of the whole object
Hi,
On PreUpdate I save an audit log entry describing the current entity.
However, I guess I should
audit log the object in its previous state not its current state -
otherwise I need to audit log in the PreCreate as well - right? I think
I'll have to use your solution, Pinaki, to get the
Pinaki,
I agree with all your statements. I would like to keep the audit logging
out of my business domain (separating of concerns). I just hadn't found a
good way of doing this with JPA yet. Jim's approach gave me a way of being
able to create new entities in @PreUpdate however with the
Just tried your suggestion Pinaki - it works fine and I can keep the audit
logging completely separate from my domain model. I even get rid of the join
table.
Now if this were clearly supported by OpenJPA (and by JPA in the future) I
think we have a clear winner...
/Bengt
2011/7/14 Bengt
On 13/07/2011 21:14, Pinaki Poddar wrote:
Yes. Any audit facility needs to have a snapshot of the entity when it
entered a persistence context, so at @PreUpdate or at any other time points,
it can figure out what has essentially been changed about that entity in a
transaction. Now either one can
On 07/07/2011 12:05, Bengt Rodehav wrote:
I'm using OpenJPA for persistence and would like to audit log any changes
made to my entities. I serialize the objects to JSON (with Gson) and store
them in a separate table in the database. Since the audit log needs to have
the correct id's, the audit
Thanks for your post Jim,
In the past (when we rolled our own O/R mapping) we also generated the id's
ourselves via sequences stored in a dedicated table. Come to think of it,
one of the reasons was exactly what you are talking about - one can
reference the id even before the object is persisted.
Jim,
Why do you think that your approach is not supported by JPA? From other
posts on this list I've seen that you are allowed to add/enrich your entity
in the PreUpdate/PreCreate callbacks. That's all you are doing right. Then
JPA persists your enriched entities.
What do you violate?
/Bengt
On 12/07/2011 09:33, Bengt Rodehav wrote:
Why do you think that your approach is not supported by JPA? From other
posts on this list I've seen that you are allowed to add/enrich your entity
in the PreUpdate/PreCreate callbacks. That's all you are doing right. Then
JPA persists your enriched
Jim,
I tried your approach (I think) but got the following exception:
*openjpa-2.0.1-r422266:989424 nonfatal user error
org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged
object in persistent field
se.digia.maia.common.persistence.EntityBase.auditLogelement:class
Indeed very interesting stuff (JEST). I'm not sure whether I want straight
lines from the client to the persistence layer though. Normally you would
want a layer in between for adding business logic, security etc. What is
interesting is to send general queries from the client to the server and
Pinaki,
Can you point me to where I can find documentation about acessing the entity
manager from the life cycle callbacks? Will it be supported in OpenJPA in
the future? Can I rely on it?
/Bengt
2011/7/8 Pinaki Poddar ppod...@apache.org
you actually store it in the object itself.
That's
7.7.2011 14:05, Bengt Rodehav kirjoitti:
I'm using OpenJPA for persistence and would like to audit log any changes
made to my entities. I serialize the objects to JSON (with Gson) and store
them in a separate table in the database. Since the audit log needs to have
the correct id's, the audit
On Thursday 07 Jul 2011, Bengt Rodehav wrote:
I'm using OpenJPA for persistence and would like to audit log any changes
made to my entities. I serialize the objects to JSON (with Gson) and store
them in a separate table in the database. Since the audit log needs to have
the correct id's, the
You might take a look at how hades
(http://hades.synyx.org/static/2.x/site/org.synyx.hades/reference/html/auditing.html)
does something close to what you're describing. Or http://www.jboss.org/envers
-Andy
On Thu, 2011-07-07 at 15:35 +0100, David Goodenough wrote:
On Thursday 07 Jul 2011,
Jari,
Yes an asynchronous queue is definitely an option. I've actually used that
approach before. It makes a lot of sense when trying to achieve high
throughput since the audit logging can then be done on lower priority.
I was however hoping to be able to use JPA for this since a queue increases
Thanks for your reply David,
I wouldn't rule out cheating although I'd rather not. I have no experience
in mixing JDBC and JPA. What would happen transaction wise? Can they both be
part of the same transaction?
/Bengt
2011/7/7 David Goodenough david.goodeno...@btconnect.com
On Thursday 07 Jul
Perhaps you could use a separate PU for your audit logging? That should be
safe to use inside of a lifecycle callback.
On Thu, Jul 7, 2011 at 11:36 AM, Bengt Rodehav be...@rodehav.com wrote:
Jari,
Yes an asynchronous queue is definitely an option. I've actually used that
approach before. It
I actually use the same approach as Hades for createdBy, updatedBy,
createdWhen and updatedWhen. In addition to this basic audit logging I also
want to log all historical versions together with information about who
updated the object.
I've read a little bit about Envers. I didn't want to bring
Interesting suggestion. Can I still share the same transaction between the
original update and my audit log insert?
/Bengt
2011/7/7 Rick Curtis curti...@gmail.com
Perhaps you could use a separate PU for your audit logging? That should be
safe to use inside of a lifecycle callback.
On Thu,
How is your JPA accessed? I have done JPA, and Audit logging on top of
it, but it was into XML files, and performed in a EJB3 Session Bean. The
JPA objects were plain simple, but they were all accessed via a Session
Bean Facade. I did it with XML because boss wanted so, but could have
been
Bengt:
I'm enjoying this discussion because of the gymnastics that were required for
my solutions. There is no easy way that I am aware of -- but I would LOVE to
be wrong.
Here's what I did (and, no, I'm not particularly proud of the solution):
(1) For the primary entities, add tracking data
Hi,
Good to see lot of new ideas about auditing.
Here is one more [1] that uses OpenJPA specific internals of accessing the
original state of an entity.
The comparison of the current state and original state to decide upon the
audit message is provided trivially in this example -- but at the
submitted
since we didn't quite agree if it is spec conform.
LieGrue,
strub
--- On Thu, 7/7/11, Pinaki Poddar ppod...@apache.org wrote:
From: Pinaki Poddar ppod...@apache.org
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Thursday, July 7, 2011, 7:58 PM
Hi,
Good
Jarl,
In production I run my application in OSGi (Apache Karaf). I use Apache
Aries JPA support to publish entity manager factories and to enlist into JTA
transactions. I've abandoned JEE since a while now - am even moving away
from Spring
I've also used XML before but I've recently moved
Wow - lots of discussion here. I must have hit a good topic for once...
I don't see why you shouldn't be proud of your solution. Storing all
versions is a well known idiom for preserving your history. Basically you
don't allow updates but create new versions all the time instead. I have
Again an interesting approach. It's very similar to the way we did it in the
old days (before O/R mappers were abundant). We rolled our own O/R mapping
and also compared the previous state with the new state and saved the
difference (XML in the database). I guess the same approach can be taken if
:
From: Pinaki Poddar ppod...@apache.org
Subject: Re: Audit log with OpenJPA
To: users@openjpa.apache.org
Date: Thursday, July 7, 2011, 7:58 PM
Hi,
Good to see lot of new ideas about auditing.
Here is one more [1] that uses OpenJPA specific
internals of accessing the
original
you actually store it in the object itself.
That's right. This allows in-memory rollback.
Given that the entire 'clean' or 'original' state is available in the
technique I described, the application can make several decisions on
a) what should be logged in an audit trail -- the entire object
However, I store the JSON in a database and I was hoping to use JPA for
this
Actually, storing JSON in relational database would not permit query based
on property values. But OpenJPA can provide JSON formatted-data for any web
UI.
To more about t, following references can help
[1]
52 matches
Mail list logo
