[Geoserver-devel] Implementing TransactionPlugin for WFS-T

Hello,

I'm currently looking at the possibility to use the
org.geoserver.wfs.TransactionPlugin (Version 1.6-beta3) to follow the
evolution of a wfs transaction. After looking at the TransactionPlugin
interface I have a few questions:

- The TransactionPlugin interface is not public, therefore if I make my
own class implementing the interface it needs to be in the
org.geoserver.wfs package. This is not really a problem for me, but I
was wondering what was the reason for this?

- The two methods beforeCommit and afterTransaction do not get a
reference to the transaction request. How can these methods know, for
which request they are called? Or can I assume that the
Transaction.execute method is done, before a new transaction is
processed? In that case I could store a reference to the request when
beforeTransaction is called.

I hope I didn't miss anything, unfortunately I'm still not to familiar
with the geoserver code (and the spring framework) and how to use it for
my own development.

Best Regards, Tobias

---
Tobias Graf
phone: +49 (89) 121528-67 mailto:tobias.graf@anonymised.com
fax: +49 (89) 121528-79 http://www.gaf.de
GAF AG Arnulfstr. 197 D-80634 Muenchen Germany

Vorstand: Dr. Peter Volk, Aufsichtsratsvorsitzender: Marcello Maranesi

Amtsgericht Muenchen HRB 140 509, Firmensitz: Muenchen

Tobias Graf ha scritto:

Hello,

I'm currently looking at the possibility to use the
org.geoserver.wfs.TransactionPlugin (Version 1.6-beta3) to follow the
evolution of a wfs transaction. After looking at the TransactionPlugin
interface I have a few questions:

- The TransactionPlugin interface is not public, therefore if I make my
own class implementing the interface it needs to be in the
org.geoserver.wfs package. This is not really a problem for me, but I
was wondering what was the reason for this?

This is an overlook on my part, sorry. Fixed it.

- The two methods beforeCommit and afterTransaction do not get a
reference to the transaction request. How can these methods know, for
which request they are called? Or can I assume that the
Transaction.execute method is done, before a new transaction is
processed? In that case I could store a reference to the request when
beforeTransaction is called.

Hum, you're right... you could work around this limitation by declaring your listener as a prototype in the spring context, so that each transaction gets a new instance of the plugin. This would make your
coding easier (no mt to handle in the simple cases), but would limit the
amount of things you can do (or, to be more precise, make them more
complicated if you need to keep global state between transactions) and may have some performance implications.

Developers, what do you think of this point? Shall we ask people to
have plugins and listeners be prototypes or add TransactionType as
a parameter in all callbacks?

I noticed that I should add a reference to the originating transaction
to TransactionEvent as well.

I hope I didn't miss anything, unfortunately I'm still not to familiar
with the geoserver code (and the spring framework) and how to use it for
my own development.

Your points are very good, and it's nice to have someone testing the
framework, as you can see we don't have any implementation using it in
the plugin/listener part (we have plans to bring back WFS validation as
a plugin, but so far no-one has started working on it).

Cheers
Andrea

Developers, what do you think of this point? Shall we ask people to
have plugins and listeners be prototypes or add TransactionType as
a parameter in all callbacks?

Hmm... I dont think assuming a particular spring setting is a good plan
when designing an api. I would vote for passing the transaction type
into the call back.

I noticed that I should add a reference to the originating transaction
to TransactionEvent as well.

I hope I didn't miss anything, unfortunately I'm still not to familiar
with the geoserver code (and the spring framework) and how to use it for
my own development.

Your points are very good, and it's nice to have someone testing the
framework, as you can see we don't have any implementation using it in
the plugin/listener part (we have plans to bring back WFS validation as
a plugin, but so far no-one has started working on it).

Cheers
Andrea

!DSPAM:4007,470b915f66255409313003!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Hello Andrea,

thank you very much for your fasts reply and comments.

Developers, what do you think of this point? Shall we ask
people to have plugins and listeners be prototypes or add
TransactionType as a parameter in all callbacks?

I think for our purpose using a spring prototype would be ok, however it would be also fine for us if we get the TransactionType with all callbacks. In that case we still could use the prototype option if necessary.

Thanks, Tobias

---
Tobias Graf
phone: +49 (89) 121528-67 mailto:tobias.graf@anonymised.com
fax: +49 (89) 121528-79 http://www.gaf.de
GAF AG Arnulfstr. 197 D-80634 Muenchen Germany

Vorstand: Dr. Peter Volk, Aufsichtsratsvorsitzender: Marcello Maranesi
Amtsgericht Muenchen HRB 140 509, Firmensitz: Muenchen

-----Ursprüngliche Nachricht-----
Von: Andrea Aime [mailto:aaime@anonymised.com]
Gesendet: Dienstag, 9. Oktober 2007 16:31
An: Tobias Graf
Cc: geoserver-devel@lists.sourceforge.net; Justin Deoliveira
Betreff: Re: [Geoserver-devel] Implementing TransactionPlugin
for WFS-T

Tobias Graf ha scritto:
> Hello,
>
> I'm currently looking at the possibility to use the
> org.geoserver.wfs.TransactionPlugin (Version 1.6-beta3) to
follow the
> evolution of a wfs transaction. After looking at the
TransactionPlugin
> interface I have a few questions:
>
> - The TransactionPlugin interface is not public, therefore
if I make
> my own class implementing the interface it needs to be in the
> org.geoserver.wfs package. This is not really a problem for
me, but I
> was wondering what was the reason for this?

This is an overlook on my part, sorry. Fixed it.

> - The two methods beforeCommit and afterTransaction do not get a
> reference to the transaction request. How can these methods
know, for
> which request they are called? Or can I assume that the
> Transaction.execute method is done, before a new transaction is
> processed? In that case I could store a reference to the
request when
> beforeTransaction is called.

Hum, you're right... you could work around this limitation by
declaring your listener as a prototype in the spring context,
so that each transaction gets a new instance of the plugin.
This would make your coding easier (no mt to handle in the
simple cases), but would limit the amount of things you can
do (or, to be more precise, make them more complicated if you
need to keep global state between transactions) and may have
some performance implications.

Developers, what do you think of this point? Shall we ask
people to have plugins and listeners be prototypes or add
TransactionType as a parameter in all callbacks?

I noticed that I should add a reference to the originating
transaction to TransactionEvent as well.

> I hope I didn't miss anything, unfortunately I'm still not
to familiar
> with the geoserver code (and the spring framework) and how
to use it
> for my own development.

Your points are very good, and it's nice to have someone
testing the framework, as you can see we don't have any
implementation using it in the plugin/listener part (we have
plans to bring back WFS validation as a plugin, but so far
no-one has started working on it).

Cheers
Andrea