RE: Hibernate modifying POJOs before rollback...

2006-05-25 Thread James Carman
Thanks, but I've already written it.  I will take a look, though.

-Original Message-
From: Javier Sanchez [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 25, 2006 5:42 PM
To: Tapestry users
Subject: Re: Hibernate modifying POJOs before rollback...

I think you need a Transactions Manager for Java Objects such as JBoss
Transactions to do that.  Look at
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jb
osstm

JAVIER SANCHEZ.

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:
> All,
>
> I am trying to add some code into Tapernate which will "rollback" the
POJOs
> that Hibernate has changed when a transaction is rolled back (the version
or
> auto-generated id properties).  I am going to attempt it using an
> interceptor.  Has anyone every tried to do this before?  I'm just
wondering
> if there is a better approach.
>
> I'm actually changing Tapernate to include a "hibernate interceptor
> pipeline" so that you can contribute your own "interceptor filters" to do
> whatever you want.  The "endpoint" of the pipeline will be an
> EmptyInterceptor, so if no interceptor filters are contributed to the
> pipeline, then nothing will happen.
>
> James
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hibernate modifying POJOs before rollback...

2006-05-25 Thread Javier Sanchez

I think you need a Transactions Manager for Java Objects such as JBoss
Transactions to do that.  Look at
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jbosstm

JAVIER SANCHEZ.

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:

All,

I am trying to add some code into Tapernate which will "rollback" the POJOs
that Hibernate has changed when a transaction is rolled back (the version or
auto-generated id properties).  I am going to attempt it using an
interceptor.  Has anyone every tried to do this before?  I'm just wondering
if there is a better approach.

I'm actually changing Tapernate to include a "hibernate interceptor
pipeline" so that you can contribute your own "interceptor filters" to do
whatever you want.  The "endpoint" of the pipeline will be an
EmptyInterceptor, so if no interceptor filters are contributed to the
pipeline, then nothing will happen.

James



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hibernate modifying POJOs before rollback...

2006-05-24 Thread Henri Dupre

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:


All,

I am trying to add some code into Tapernate which will "rollback" the
POJOs
that Hibernate has changed when a transaction is rolled back (the version
or
auto-generated id properties).  I am going to attempt it using an
interceptor.  Has anyone every tried to do this before?  I'm just
wondering
if there is a better approach.



I'm a little confused on the objective... If you load a pojo from your db
through hibernate, then you start a transaction, modify it, roll back the
transaction... if your pojo is proxied, wouldn't hibernate do it
automatically?

Thanks,

Henri.


RE: Hibernate modifying POJOs before rollback...

2006-05-23 Thread James Carman
Well, as I said, I haven't really dug in too far just yet.  I'm still
setting up the interceptor pipeline and making sure that all works before I
try adding my own to the mix.

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 23, 2006 7:41 PM
To: Tapestry users
Subject: Re: Hibernate modifying POJOs before rollback...

Ah well..You don't even need to do that. The main interface has a ton of
methods to define, but it also comes with a "Default" implementation,
letting you choose which one to handle..

I'm 90% sure there is a specific method / info in the parms passed in that
you won't even need to track which objects were modified outside of the
interceptor itself. (hibernate goes to a lot of trouble to do this tracking
for you )

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:
>
> The idea is that I'll try to remember each POJO that has been modified
> during the course of a tx.  If the tx is rolled back, then I'll set
> properties to their previous values.  I don't know if this is going to
> work
> or not.  That's why I asked if someone has already done it so that I could
> maybe stand "on the shoulders of giants" a bit. :-)
>
>
>
> -Original Message-
> From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 23, 2006 7:17 PM
> To: Tapestry users
> Subject: Re: Hibernate modifying POJOs before rollback...
>
> I've added interceptors into hibernate before with great success.
>
> The method implementations pass in before / after data comparisons for you
> to look at / modify. It sounds like tricky stuff though(with how they
> normally document "all bets are off" type things when a rollback happens
> or
> exception occurs), make sure your unit tests cover everything :)
>
> On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:
> >
> > All,
> >
> > I am trying to add some code into Tapernate which will "rollback" the
> > POJOs
> > that Hibernate has changed when a transaction is rolled back (the
> version
> > or
> > auto-generated id properties).  I am going to attempt it using an
> > interceptor.  Has anyone every tried to do this before?  I'm just
> > wondering
> > if there is a better approach.
> >
> > I'm actually changing Tapernate to include a "hibernate interceptor
> > pipeline" so that you can contribute your own "interceptor filters" to
> do
> > whatever you want.  The "endpoint" of the pipeline will be an
> > EmptyInterceptor, so if no interceptor filters are contributed to the
> > pipeline, then nothing will happen.
> >
> > James
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hibernate modifying POJOs before rollback...

2006-05-23 Thread Jesse Kuhnert

Ah well..You don't even need to do that. The main interface has a ton of
methods to define, but it also comes with a "Default" implementation,
letting you choose which one to handle..

I'm 90% sure there is a specific method / info in the parms passed in that
you won't even need to track which objects were modified outside of the
interceptor itself. (hibernate goes to a lot of trouble to do this tracking
for you )

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:


The idea is that I'll try to remember each POJO that has been modified
during the course of a tx.  If the tx is rolled back, then I'll set
properties to their previous values.  I don't know if this is going to
work
or not.  That's why I asked if someone has already done it so that I could
maybe stand "on the shoulders of giants" a bit. :-)



-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 23, 2006 7:17 PM
To: Tapestry users
Subject: Re: Hibernate modifying POJOs before rollback...

I've added interceptors into hibernate before with great success.

The method implementations pass in before / after data comparisons for you
to look at / modify. It sounds like tricky stuff though(with how they
normally document "all bets are off" type things when a rollback happens
or
exception occurs), make sure your unit tests cover everything :)

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:
>
> All,
>
> I am trying to add some code into Tapernate which will "rollback" the
> POJOs
> that Hibernate has changed when a transaction is rolled back (the
version
> or
> auto-generated id properties).  I am going to attempt it using an
> interceptor.  Has anyone every tried to do this before?  I'm just
> wondering
> if there is a better approach.
>
> I'm actually changing Tapernate to include a "hibernate interceptor
> pipeline" so that you can contribute your own "interceptor filters" to
do
> whatever you want.  The "endpoint" of the pipeline will be an
> EmptyInterceptor, so if no interceptor filters are contributed to the
> pipeline, then nothing will happen.
>
> James
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.


RE: Hibernate modifying POJOs before rollback...

2006-05-23 Thread James Carman
The idea is that I'll try to remember each POJO that has been modified
during the course of a tx.  If the tx is rolled back, then I'll set
properties to their previous values.  I don't know if this is going to work
or not.  That's why I asked if someone has already done it so that I could
maybe stand "on the shoulders of giants" a bit. :-)



-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 23, 2006 7:17 PM
To: Tapestry users
Subject: Re: Hibernate modifying POJOs before rollback...

I've added interceptors into hibernate before with great success.

The method implementations pass in before / after data comparisons for you
to look at / modify. It sounds like tricky stuff though(with how they
normally document "all bets are off" type things when a rollback happens or
exception occurs), make sure your unit tests cover everything :)

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:
>
> All,
>
> I am trying to add some code into Tapernate which will "rollback" the
> POJOs
> that Hibernate has changed when a transaction is rolled back (the version
> or
> auto-generated id properties).  I am going to attempt it using an
> interceptor.  Has anyone every tried to do this before?  I'm just
> wondering
> if there is a better approach.
>
> I'm actually changing Tapernate to include a "hibernate interceptor
> pipeline" so that you can contribute your own "interceptor filters" to do
> whatever you want.  The "endpoint" of the pipeline will be an
> EmptyInterceptor, so if no interceptor filters are contributed to the
> pipeline, then nothing will happen.
>
> James
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Hibernate modifying POJOs before rollback...

2006-05-23 Thread Jesse Kuhnert

I've added interceptors into hibernate before with great success.

The method implementations pass in before / after data comparisons for you
to look at / modify. It sounds like tricky stuff though(with how they
normally document "all bets are off" type things when a rollback happens or
exception occurs), make sure your unit tests cover everything :)

On 5/23/06, James Carman <[EMAIL PROTECTED]> wrote:


All,

I am trying to add some code into Tapernate which will "rollback" the
POJOs
that Hibernate has changed when a transaction is rolled back (the version
or
auto-generated id properties).  I am going to attempt it using an
interceptor.  Has anyone every tried to do this before?  I'm just
wondering
if there is a better approach.

I'm actually changing Tapernate to include a "hibernate interceptor
pipeline" so that you can contribute your own "interceptor filters" to do
whatever you want.  The "endpoint" of the pipeline will be an
EmptyInterceptor, so if no interceptor filters are contributed to the
pipeline, then nothing will happen.

James



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.