You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Mike Kienenberger <mk...@gmail.com> on 2006/10/02 16:33:53 UTC
Re: How to use TransactionDelegate to do audit logging?
Hey Jeff, it's generally better to post questions to the mailing list
as others may have better ideas than my own, so I'm replying to this
on the mailing list as well.
1) Yes
2) Yes
3) Yes, I collect schema, table, column, and new value for the
inserted record (You can delete the code that handles the update and
delete cases). . I also want a relationship from my audit record to
the record being audited. So I retrieve the primary key(s) for the
record and store that as well. This is what
setForeignKeyRepresentation does. If it's a single INTEGER primary
key, then I store it as FOREIGN_KEY. Otherwise, I store string
representation of the keys as FKEY_CONDITION.
So I build up a list of audit log information (in map form) to be
subsequently written out later. ProcessAuditRecordMapList() is what
writes out the records. I create an InsertQuery, and because all
audit records look the same, I simply bind every set of audit
information to the InsertQuery and then manually execute it. Most of
the code in processAuditRecordMapList simply deals with manually
generating a unique primary key for each audit record. Because my
database fields match the Map fields, I can directly assign the audit
records to the insert query without any translation of the map keys
and database table field names.
You can use insertBatchQuery.getObjectId().getEntityName() to get the
name of the ObjEntity and use that to filter out all by Alert objects
if you don't want to use the table name.
To iterate through the database table field values, you would use the
same code that's already there:
=====
List dbAttributes = insertBatchQuery.getDbAttributes();
while(insertBatchQuery.next()) {
for(int i = 0; i < dbAttributes.size(); i++) {
Map auditRecordMap = new HashMap();
DbAttribute dbAttribute = (DbAttribute) dbAttributes.get(i);
Object value = insertBatchQuery.getValue(i);
=====
dbAttribute.getName() is the field name, and value is the value.
Don't know the answer to your validateForSave() question as I haven't
used it. However, this finishedRunQueries() hook is the only place
available where your insert statements have been committed to the
database (and thus have primary keys assigned) and yet is before the
transaction has been committed so you can get your audit logging in on
the same transaction.
The easiest way I've found to understand how all of this stuff works
together and what's available
(ObjEntity/ObjAttribute/DbEntity/DbAttribute) is to set a breakpoint
and look at the values in the debugger. It's the same stuff you see
in the modeler, but for myself, it didn't all come together until I
saw it with my actual data in the debugger.
On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
> Hi, sorry to bother you again. I have a few questions on how to use the
> audit logging stuff ...
>
> 1) To use your AuditLoggingDataContextFactory to create data contexts
> (we're using thread-bound data-contexts in a web app), we set the
> "DataContext Factory" property using CayenneModeler for our domain,
> correct? This will cause the data-contexts that are created and bound
> to our webapp threads to be wrapped by the AuditLoggingDataContextDelegate?
>
> 2) Your patch adds the method finishedRunQueries(DataContext
> dataContext, List queryList) to DataContextDelegate, correct?
>
> 3) I'm still trying to figure out the example finishedRunQueries() in
> AuditLoggingDataContextFactory ... (sorry, I'm not a Cayenne expert!).
> It looks like queryList is a list of queries, where a query can be an
> insert, update, or delete. For an insert (the only case I'm interested
> in), it looks like you get a set of Schema/Table/Column/Value tuples?
> And then do some stuff with primary keys or something? To be honest,
> I'm pretty lost at this point with InsertQueries, dbAttributes, and
> pkAttributes, etc! I think you're building up a list of audit log
> objects (in map form) to be subsequently written out later? And I have
> no idea what processAuditRecordMapList() is doing ...
>
> All I need is: If we're going to Insert an object into the db, check to
> see if the object is an Alert (one of our classes), and if it is, pull
> some fields out of it, and conditionally (i.e. not every Alert gets an
> audit record, depending on the value of the fields) create a new object
> with those fields and write that object to the database as well. I
> think I can check the class of the object (indirectly) by looking at
> dbEntity.getName() and seeing if it is "alert" (i.e. the table name),
> but I don't see how to pick out the values of the other fields from the
> object.
>
> If I'm asking too many questions, or the time required to answer the
> questions is too much, just say so!
>
> Could I get the same affect by just overloading validateForSave() on the
> Alert objects?
>
> What I'm *really* trying to do is that we have about 15-20 different
> types of alerts, and a bunch of rules that specify some additional
> processing that needs to take place when certain types of alerts are
> generated. Rather than scatter the rules around the umpteen different
> places alerts are created, I thought I'd be "clever" and put all the
> rule processing stuff in one place, looking at the alerts as they get
> written out. So, as a complete workaround, I could just go add the
> rules to the umpteen different places the alerts are getting generated.
> Or, if there was a convenient place to hook some "aspect-oriented"
> programming stuff (which is what I guess I'm doing), like a
> Alert.onSave(), that would work too.
>
> Anyway, any help or suggestions would be greatly appreciated!
>
> Thanks again,
> Jeff
>
>
> Mike Kienenberger wrote:
> > Yes, I'll be adding it to 2.0/3.0 "soon" where soon will depend on
> > what time I have available over the next month. But we are committed
> > to getting audit support into Cayenne. The only discussion left is
> > whether this will be a DataContextDelegate method or an Event, but
> > switching between the two should be a trivial change.
> >
> > Another option is I can send you my own patched Cayenne 1.2 jars, but
> > you'll have to take outer join support along with it :-)
> >
> >
> > On 9/15/06, Jeff de Vries <jd...@pfrog.com> wrote:
> >> This looks good, but I'm a little nervous about patching Cayenne. Will
> >> this patch make it into 1.3 (or 2.0 or whatever is next), or will I be
> >> stuck using 1.2 if I use this? Also, to apply the patch I assume I need
> >> to check Cayenne 1.2 from svn or cvs and then apply the patch?
> >>
> >> Thanks again!!
> >> Jeff
> >>
> >> Mike Kienenberger wrote:
> >> > Jeff,
> >> >
> >> > In my opinion, this will not do what you want.
> >> >
> >> > Please see this jira issue for an example of how to solve this problem
> >> > (currently, it requires a patch to Cayenne 1.2).
> >> >
> >> > http://issues.apache.org/cayenne/browse/CAY-414
> >> >
> >> > On 9/14/06, Jeff de Vries <jd...@pfrog.com> wrote:
> >> >> I want to add a record to an audit table whenever certain objects are
> >> >> saved to the database. Based on earlier posts, I think I need to
> >> create
> >> >> a custom TransactionDelegate, and override didCommit() (or
> >> >> willCommit()). What I don't understand is how to access the objects
> >> >> that are going to be saved for this transaction so I can pull
> >> relevant
> >> >> information out for the audit record. Are there any examples of
> >> >> doing this?
> >> >>
> >> >> Thanks,
> >> >> Jeff de Vries
> >> >>
> >> >>
> >>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Mike Kienenberger <mk...@gmail.com>.
On 10/3/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> In Cayenne I would still use a separate peer DataContext to commit
> changes from within callbacks. And use explicit transactions so that
> multiple DataContexts commit atomically.
>
> > 4) JPA states that a new+update event and an update+delete event may
> > not execute the update event listener.
I think no update event for update+delete is a great idea.
I think new+update is undefined. If I get the "new+update" values in
the new event, that's perfect. If I only get the "new" event values
and not the "update" event values, then I'm thinking it's pretty lame
:-)
RE: Database Generated Ids
Posted by DOMINGUEZ Felipe <Fe...@eurocontrol.int>.
Hi Andrés.
Thanks for your help.
I will test it tonight at home.
Cheers
Felipe
-----Original Message-----
From: Andrus Adamchik [mailto:andrus@objectstyle.org]
Sent: Wednesday 04 October 2006 16:48
To: cayenne-user@incubator.apache.org
Subject: Re: Database Generated Ids
Hi Felipe,
Here is a docs page on auto-incremented keys:
http://cwiki.apache.org/confluence/display/CAYDOC/Generated+Columns
Also see my comments below...
On Oct 4, 2006, at 3:13 AM, DOMINGUEZ Felipe wrote:
> Hello every body.
>
>
> I am using Cayenne to query hsqldb.
>
> On HSQLDB I have a few tables with an auto-increment primary key.
> When
> I manually enter data onto those tables the key generation works fine.
>
> On the other hand cayenne always uses its own key generation,
> generating
> PK with the support of table AUTO_PK_SUPPORT.
>
> I did some research last night and I found out that I must set the
> database custom adapter in the DomainNode adapter panel, so I set
> it to
> org.objectstyle.cayenne.dba.hsqldb.HSQLDBAdapter
No, in 1.2 and newer this is optional. But you still want to do that
if you are to follow the advice below.
> But still, Cayenne uses AUTO_PK_SUPPORT
True, there are two things involved in making auto-increment work.
First you must select "Database-Generated" for "PK Generation
Strategy" for each table in question. Second - Cayenne DbAdapter must
support it. HSQLDB adapter thinks that it doesn't (although in fact
it does), so you'll need to manually flip Auto PK flag:
DataNode node = ...
JdbcAdapter adapter = (JdbcAdapter) node.getAdapter();
adapter.setSupportsGeneratedKeys(true);
(I'll log an issue in Jira to make sure Cayenne does the right thing
in the future).
Andrus
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
Re: Database Generated Ids
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Felipe,
Here is a docs page on auto-incremented keys:
http://cwiki.apache.org/confluence/display/CAYDOC/Generated+Columns
Also see my comments below...
On Oct 4, 2006, at 3:13 AM, DOMINGUEZ Felipe wrote:
> Hello every body.
>
>
> I am using Cayenne to query hsqldb.
>
> On HSQLDB I have a few tables with an auto-increment primary key.
> When
> I manually enter data onto those tables the key generation works fine.
>
> On the other hand cayenne always uses its own key generation,
> generating
> PK with the support of table AUTO_PK_SUPPORT.
>
> I did some research last night and I found out that I must set the
> database custom adapter in the DomainNode adapter panel, so I set
> it to
> org.objectstyle.cayenne.dba.hsqldb.HSQLDBAdapter
No, in 1.2 and newer this is optional. But you still want to do that
if you are to follow the advice below.
> But still, Cayenne uses AUTO_PK_SUPPORT
True, there are two things involved in making auto-increment work.
First you must select "Database-Generated" for "PK Generation
Strategy" for each table in question. Second - Cayenne DbAdapter must
support it. HSQLDB adapter thinks that it doesn't (although in fact
it does), so you'll need to manually flip Auto PK flag:
DataNode node = ...
JdbcAdapter adapter = (JdbcAdapter) node.getAdapter();
adapter.setSupportsGeneratedKeys(true);
(I'll log an issue in Jira to make sure Cayenne does the right thing
in the future).
Andrus
Database Generated Ids
Posted by DOMINGUEZ Felipe <Fe...@eurocontrol.int>.
Hello every body.
I am using Cayenne to query hsqldb.
On HSQLDB I have a few tables with an auto-increment primary key. When
I manually enter data onto those tables the key generation works fine.
On the other hand cayenne always uses its own key generation, generating
PK with the support of table AUTO_PK_SUPPORT.
I did some research last night and I found out that I must set the
database custom adapter in the DomainNode adapter panel, so I set it to
org.objectstyle.cayenne.dba.hsqldb.HSQLDBAdapter
But still, Cayenne uses AUTO_PK_SUPPORT
To use AUTO_PK_SUPPORT is not a bad idea, since it will keep it db
independent ( I believe) but still, I would really like to know how to
do it.
Could you please give a hint on what is going on?
Cheers
Felipe
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
Re: How to use TransactionDelegate to do audit logging?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Oct 3, 2006, at 12:31 PM, Mike Kienenberger wrote:
> 1) These events are per-object and provide no reference to the current
> persistent unit (DataContext). Your entity instance might get events
> from all persistent units committing a change. You won't know what
> persistent unit to append new audit log inserts.
True - in Cayenne you'd simply do [this|object].getObjectContext()...
In JPA you'd have use threadlocals.
> 2) Because they are per-event, there is a much greater performance hit
> -- several callbacks per entity instance.
Since you can register listeners for a single event type, this is not
as bad as it looks (there won't be many noop calls).
> If you need both old
> values and new values, you will have to monitor both the pre- and
> post- events.
True.
> 3) JPA states that no queries can be executed at this point. So if
> you want to create audit logs in the same transaction, you'll have to
> figure out a way to delay those inserts until after the current commit
> finishes but before the transaction commits.
In Cayenne I would still use a separate peer DataContext to commit
changes from within callbacks. And use explicit transactions so that
multiple DataContexts commit atomically.
> 4) JPA states that a new+update event and an update+delete event may
> not execute the update event listener.
I used Cayenne callbacks on two different projects, and I actually
find this behavior to be a good thing.
Andrus
Re: How to use TransactionDelegate to do audit logging?
Posted by Mike Kienenberger <mk...@gmail.com>.
I read up on the JPA lifecycle events last week. In my opinion, they
have some shortcomings. Some of these may not apply to the specific
Cayenne implementation of JPA listeners. (In fact, I'd hope none of
these would be insurmountable using Cayenne.)
1) These events are per-object and provide no reference to the current
persistent unit (DataContext). Your entity instance might get events
from all persistent units committing a change. You won't know what
persistent unit to append new audit log inserts.
2) Because they are per-event, there is a much greater performance hit
-- several callbacks per entity instance. If you need both old
values and new values, you will have to monitor both the pre- and
post- events.
3) JPA states that no queries can be executed at this point. So if
you want to create audit logs in the same transaction, you'll have to
figure out a way to delay those inserts until after the current commit
finishes but before the transaction commits.
4) JPA states that a new+update event and an update+delete event may
not execute the update event listener.
On 10/2/06, Aristedes Maniatis <ar...@ish.com.au> wrote:
> On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
>
> >> What I'm *really* trying to do is that we have about 15-20 different
> >> types of alerts, and a bunch of rules that specify some additional
> >> processing that needs to take place when certain types of alerts are
> >> generated. Rather than scatter the rules around the umpteen
> >> different
> >> places alerts are created, I thought I'd be "clever" and put all the
> >> rule processing stuff in one place, looking at the alerts as they get
> >> written out. So, as a complete workaround, I could just go add the
> >> rules to the umpteen different places the alerts are getting
> >> generated.
> >> Or, if there was a convenient place to hook some "aspect-oriented"
> >> programming stuff (which is what I guess I'm doing), like a
> >> Alert.onSave(), that would work too.
>
> Actually support to do exactly this is now built into Cayenne 3.0 and
> we are using it in production. It was added only in the last
> fortnight, but is working really well.
>
> http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
>
> I think it will do exactly what you need.
>
>
> As for auditing, I wonder whether this callback work now makes the
> auditing approach redundant? It appears that the callbacks are a more
> general implementation of what Mike has done and might be able to be
> used for his auditing requirements.
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, 3.0 builds are still in a bit of a disarray, so use it at your
own risk. The code IMO is in a good shape though - FWIW myself and
other people are running it in production :-)
You can grab a nightly build here (last 3-4 builds are pretty stable):
http://objectstyle.org/downloads/cayenne/nightly/
The file "lib/cayenne-jdk1.4-3.0-incubating-SNAPSHOT.jar" is analog
of 1.2.1 "cayenne-nodeps.jar". Modeler included in the nightly build
is still broken, so grab the Modeler from here (I just posted
manually built snapshots, see a previous message on this list):
http://people.apache.org/~aadamchik/modeler-snapshot-10032006/
Andrus
On Oct 3, 2006, at 1:49 AM, Aristedes Maniatis wrote:
> On 03/10/2006, at 3:00 PM, Jeff de Vries wrote:
>
>> Thanks! Couple more questions ...
>>
>> 1) Where do I get 3.0? Nightly snapshot? Is any one more stable
>> than any other? Any installation instructions? Or things to watch
>> out for?
>
> Use svn to get a local checkout of the source. Then install maven
> on your computer and:
>
> # mvn install
>
> The product gets put in the world's longest path, somewhere inside
> ~/.m2/ Just look at the last couple of messages in the maven build.
>
>
>> 2) Is the "handleCallback" argument actually the name of the
>> method to call as the callback, aka "myPostPersist"?
>
> That's the idea. We have methods like this in the entities:
>
> protected void prePersist() {
> // do something
> }
>
>
>> 3) Where is the proper place to set up the callbacks? In a custom
>> data context factory (assuming you always want the callbacks)?
>> This is for a web app using thread data contexts.
>
> Where you initialise Cayenne.
>
>
>> 4) Where do I get the domain object?
>
>
> Configuration.initializeSharedConfiguration();
> Configuration conf = Configuration.getSharedConfiguration();
> dataDomain = conf.getDomain();
>
> LifecycleEventCallbackMap aCallback = dataDomain.getEntityResolver
> ().getCallbacks( LifecycleEventCallback.PRE_PERSIST );
> aCallback.addListener( Foo.class, "prePersist" );
>
>
>
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 03/10/2006, at 3:00 PM, Jeff de Vries wrote:
> Thanks! Couple more questions ...
>
> 1) Where do I get 3.0? Nightly snapshot? Is any one more stable
> than any other? Any installation instructions? Or things to watch
> out for?
Use svn to get a local checkout of the source. Then install maven on
your computer and:
# mvn install
The product gets put in the world's longest path, somewhere inside
~/.m2/ Just look at the last couple of messages in the maven build.
> 2) Is the "handleCallback" argument actually the name of the method
> to call as the callback, aka "myPostPersist"?
That's the idea. We have methods like this in the entities:
protected void prePersist() {
// do something
}
> 3) Where is the proper place to set up the callbacks? In a custom
> data context factory (assuming you always want the callbacks)?
> This is for a web app using thread data contexts.
Where you initialise Cayenne.
> 4) Where do I get the domain object?
Configuration.initializeSharedConfiguration();
Configuration conf = Configuration.getSharedConfiguration();
dataDomain = conf.getDomain();
LifecycleEventCallbackMap aCallback = dataDomain.getEntityResolver
().getCallbacks( LifecycleEventCallback.PRE_PERSIST );
aCallback.addListener( Foo.class, "prePersist" );
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: How to use TransactionDelegate to do audit logging?
Posted by Jeff de Vries <jd...@pfrog.com>.
Thanks! Couple more questions ...
1) Where do I get 3.0? Nightly snapshot? Is any one more stable than
any other? Any installation instructions? Or things to watch out for?
2) Is the "handleCallback" argument actually the name of the method to
call as the callback, aka "myPostPersist"?
3) Where is the proper place to set up the callbacks? In a custom data
context factory (assuming you always want the callbacks)? This is for a
web app using thread data contexts.
4) Where do I get the domain object?
Thanks again!
Jeff
Andrus Adamchik wrote:
>
> Yeah, need to write the docs. Here is a short example:
>
> DataDomain domain;
> int callbackType; // types are defined in
> 'org.apache.cayenne.map.LifecycleEventCallback' interface
>
> domain.getEntityResolver().getCallbacks(callbackType).addListener(
> MyClass.class, listener, "handleCallback");
>
> or
>
> domain.getEntityResolver().getCallbacks(callbackType).addListener(
> MyClass.class, "handleCallback");
>
> Andrus
>
>
>
>
> On Oct 2, 2006, at 10:31 PM, Jeff de Vries wrote:
>
>> Yes, that looks very much like what I need. One problem: The
>> section labeled "Enabling Callbacks" says "TODO"!
>>
>> How do you set them up?
>>
>> Thanks,
>> Jeff
>>
>> Aristedes Maniatis wrote:
>>> On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
>>>
>>>>> What I'm *really* trying to do is that we have about 15-20 different
>>>>> types of alerts, and a bunch of rules that specify some additional
>>>>> processing that needs to take place when certain types of alerts are
>>>>> generated. Rather than scatter the rules around the umpteen
>>>>> different
>>>>> places alerts are created, I thought I'd be "clever" and put all the
>>>>> rule processing stuff in one place, looking at the alerts as they get
>>>>> written out. So, as a complete workaround, I could just go add the
>>>>> rules to the umpteen different places the alerts are getting
>>>>> generated.
>>>>> Or, if there was a convenient place to hook some "aspect-oriented"
>>>>> programming stuff (which is what I guess I'm doing), like a
>>>>> Alert.onSave(), that would work too.
>>>
>>> Actually support to do exactly this is now built into Cayenne 3.0
>>> and we are using it in production. It was added only in the last
>>> fortnight, but is working really well.
>>>
>>> http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
>>>
>>> I think it will do exactly what you need.
>>>
>>>
>>> As for auditing, I wonder whether this callback work now makes the
>>> auditing approach redundant? It appears that the callbacks are a
>>> more general implementation of what Mike has done and might be able
>>> to be used for his auditing requirements.
>>>
>>> Ari Maniatis
>>>
>>>
>>>
>>> -------------------------->
>>> ish
>>> http://www.ish.com.au
>>> Level 1, 30 Wilson Street Newtown 2042 Australia
>>> phone +61 2 9550 5001 fax +61 2 9550 4001
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>
>>>
>>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Yeah, need to write the docs. Here is a short example:
DataDomain domain;
int callbackType; // types are defined in
'org.apache.cayenne.map.LifecycleEventCallback' interface
domain.getEntityResolver().getCallbacks(callbackType).addListener(
MyClass.class, listener, "handleCallback");
or
domain.getEntityResolver().getCallbacks(callbackType).addListener(
MyClass.class, "handleCallback");
Andrus
On Oct 2, 2006, at 10:31 PM, Jeff de Vries wrote:
> Yes, that looks very much like what I need. One problem: The
> section labeled "Enabling Callbacks" says "TODO"!
>
> How do you set them up?
>
> Thanks,
> Jeff
>
> Aristedes Maniatis wrote:
>> On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
>>
>>>> What I'm *really* trying to do is that we have about 15-20
>>>> different
>>>> types of alerts, and a bunch of rules that specify some additional
>>>> processing that needs to take place when certain types of alerts
>>>> are
>>>> generated. Rather than scatter the rules around the umpteen
>>>> different
>>>> places alerts are created, I thought I'd be "clever" and put all
>>>> the
>>>> rule processing stuff in one place, looking at the alerts as
>>>> they get
>>>> written out. So, as a complete workaround, I could just go add the
>>>> rules to the umpteen different places the alerts are getting
>>>> generated.
>>>> Or, if there was a convenient place to hook some "aspect-oriented"
>>>> programming stuff (which is what I guess I'm doing), like a
>>>> Alert.onSave(), that would work too.
>>
>> Actually support to do exactly this is now built into Cayenne 3.0
>> and we are using it in production. It was added only in the last
>> fortnight, but is working really well.
>>
>> http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
>>
>> I think it will do exactly what you need.
>>
>>
>> As for auditing, I wonder whether this callback work now makes the
>> auditing approach redundant? It appears that the callbacks are a
>> more general implementation of what Mike has done and might be
>> able to be used for his auditing requirements.
>>
>> Ari Maniatis
>>
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Jeff de Vries <jd...@pfrog.com>.
Yes, that looks very much like what I need. One problem: The section
labeled "Enabling Callbacks" says "TODO"!
How do you set them up?
Thanks,
Jeff
Aristedes Maniatis wrote:
> On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
>
>>> What I'm *really* trying to do is that we have about 15-20 different
>>> types of alerts, and a bunch of rules that specify some additional
>>> processing that needs to take place when certain types of alerts are
>>> generated. Rather than scatter the rules around the umpteen different
>>> places alerts are created, I thought I'd be "clever" and put all the
>>> rule processing stuff in one place, looking at the alerts as they get
>>> written out. So, as a complete workaround, I could just go add the
>>> rules to the umpteen different places the alerts are getting generated.
>>> Or, if there was a convenient place to hook some "aspect-oriented"
>>> programming stuff (which is what I guess I'm doing), like a
>>> Alert.onSave(), that would work too.
>
> Actually support to do exactly this is now built into Cayenne 3.0 and
> we are using it in production. It was added only in the last
> fortnight, but is working really well.
>
> http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
>
> I think it will do exactly what you need.
>
>
> As for auditing, I wonder whether this callback work now makes the
> auditing approach redundant? It appears that the callbacks are a more
> general implementation of what Mike has done and might be able to be
> used for his auditing requirements.
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
Re: How to use TransactionDelegate to do audit logging?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 9/30/06, Jeff de Vries <jd...@pfrog.com> wrote:
>> What I'm *really* trying to do is that we have about 15-20 different
>> types of alerts, and a bunch of rules that specify some additional
>> processing that needs to take place when certain types of alerts are
>> generated. Rather than scatter the rules around the umpteen
>> different
>> places alerts are created, I thought I'd be "clever" and put all the
>> rule processing stuff in one place, looking at the alerts as they get
>> written out. So, as a complete workaround, I could just go add the
>> rules to the umpteen different places the alerts are getting
>> generated.
>> Or, if there was a convenient place to hook some "aspect-oriented"
>> programming stuff (which is what I guess I'm doing), like a
>> Alert.onSave(), that would work too.
Actually support to do exactly this is now built into Cayenne 3.0 and
we are using it in production. It was added only in the last
fortnight, but is working really well.
http://cwiki.apache.org/CAYDOC/lifecycle-callbacks.html
I think it will do exactly what you need.
As for auditing, I wonder whether this callback work now makes the
auditing approach redundant? It appears that the callbacks are a more
general implementation of what Mike has done and might be able to be
used for his auditing requirements.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A