Hi,
I am trying to find an elegant way to do the following:
We use GeoServer as WFS-T service writing to a PostGIS database from a web application. This is already implemented and working fine.
Now we want to write information about successful transactions to a second database which is part of an already running notification system. This means always when a transaction was successfull, we would like to write some of the data involved in the transaction also to another database which will automatically lead to a notification of certain users using a notification system already in use.
So my question is if someone could help me in finding the best way doing this. To get started I will let you know about my investigations so far:
The first idea to implement this was to use triggers in the PostGIS database (preferable PL/JAVA since we have some Java libraries we want to use to write to the notification database) which should be possible. On the other hand we would like to reduce the nodes where application logic is implemented and therefore would like to have this logic in our GeoServer application. We also would prefer not to change any GeoServer code directly but to “plug in” in some way. Therefore I was looking for some kind of hook mechanism available in the GeoServer transaction mechanism and in a first step thought of Spring AOP since Spring is already used in the GeoServer architecture. The place I found responsible for the transaction management is the toWrite method of TransactionResponse. Using around advice on this class will nevertheless not give me any information on the success of the transaction and on the data in case committed by the transaction since no return value is given by the method. Alternatively one could probably set the transaction by means of Spring IoC but again would not get information on the transaction data when putting around advice on the commit method. Furthermore setting the transaction would have to be changed removing it from TransactionResponse.execute and giving Spring control over that.
This makes me think that there is still no advantage over rewriting the TransactionResponse.writeTo method (or using triggers on database side). Does anyone see alternatives or can give me a hint how to implement that a better way on GeoServer side?
Thanks in advance,
Matthias
Matthias Schulz ha scritto:
Hi,
...
This makes me think that there is still no advantage over rewriting the TransactionResponse.writeTo method (or using triggers on database side). Does anyone see alternatives or can give me a hint how to implement that a better way on GeoServer side?
Interesting questions. On Geoserver trunk (1.6.0-betaX) we have a transaction plugin framework that allows you to attach a pluggable
listener to transactions, and be informed of what's going on.
The framework changed the transaction code quite a bit, so I'm
not comfortable backporting it to 1.5.x.
The idea of an around advice should work thought, you just have
to catch eventual exceptions, and inspect the transaction
response field after calling execute to see if
the transaction succeeded or not. You don't have access
to the WfsTransResponse field because it's private, but
you can force your access to it using reflection (see the Field
class).
Hope this helps
Cheers
Andrea
Hi Matthias,
Andrea just recently implemented a transaction listener interface on geoserver trunk (1.6.x). It may suite your needs, you can check it out here:
http://svn.codehaus.org/geoserver/trunk/geoserver/wfs/src/main/java/org/geoserver/wfs/TransactionListener.java
To plug your implementation in all you need to do is create a spring context which registers it, throw it and the listener in a way and then drop it into your geoserver install and it should work and you wont have to much with any geoserver code.
-Justin
Matthias Schulz wrote:
Hi,
I am trying to find an elegant way to do the following:
We use GeoServer as WFS-T service writing to a PostGIS database from a web application. This is already implemented and working fine.
Now we want to write information about successful transactions to a second database which is part of an already running notification system. This means always when a transaction was successfull, we would like to write some of the data involved in the transaction also to another database which will automatically lead to a notification of certain users using a notification system already in use.
So my question is if someone could help me in finding the best way doing this. To get started I will let you know about my investigations so far:
The first idea to implement this was to use triggers in the PostGIS database (preferable PL/JAVA since we have some Java libraries we want to use to write to the notification database) which should be possible. On the other hand we would like to reduce the nodes where application logic is implemented and therefore would like to have this logic in our GeoServer application. We also would prefer not to change any GeoServer code directly but to "plug in" in some way. Therefore I was looking for some kind of hook mechanism available in the GeoServer transaction mechanism and in a first step thought of Spring AOP since Spring is already used in the GeoServer architecture. The place I found responsible for the transaction management is the toWrite method of TransactionResponse. Using around advice on this class will nevertheless not give me any information on the success of the transaction and on the data in case committed by the transaction since no return value is given by the method. Alternatively one could probably set the transaction by means of Spring IoC but again would not get information on the transaction data when putting around advice on the commit method. Furthermore setting the transaction would have to be changed removing it from TransactionResponse.execute and giving Spring control over that.
This makes me think that there is still no advantage over rewriting the TransactionResponse.writeTo method (or using triggers on database side). Does anyone see alternatives or can give me a hint how to implement that a better way on GeoServer side?
Thanks in advance,
Matthias !DSPAM:4007,469b955b19313327367457!
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
!DSPAM:4007,469b955b19313327367457!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,469b955b19313327367457!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi Andrea and Justin,
thank you very much for your prompt help, great! Seems this is exactly what I am looking for. I tried to get a feeling of your roadmap to see when 1.6 could be used for a productive system. What would you say?
Cheers,
Matthias
2007/7/16, Andrea Aime <aaime@anonymised.com>:
Matthias Schulz ha scritto:
Hi,
…
This makes me think that there is still no advantage over rewriting the
TransactionResponse.writeTo method (or using triggers on database side).
Does anyone see alternatives or can give me a hint how to implement that
a better way on GeoServer side?
Interesting questions. On Geoserver trunk (1.6.0-betaX) we have a
transaction plugin framework that allows you to attach a pluggable
listener to transactions, and be informed of what’s going on.
The framework changed the transaction code quite a bit, so I’m
not comfortable backporting it to 1.5.x.
The idea of an around advice should work thought, you just have
to catch eventual exceptions, and inspect the transaction
response field after calling execute to see if
the transaction succeeded or not. You don’t have access
to the WfsTransResponse field because it’s private, but
you can force your access to it using reflection (see the Field
class).
Hope this helps
Cheers
Andrea
Matthias Schulz ha scritto:
Hi Andrea and Justin,
thank you very much for your prompt help, great! Seems this is exactly what I am looking for. I tried to get a feeling of your roadmap to see when 1.6 could be used for a productive system. What would you say?
Hem, after releasing 1.6.0-beta2 we're now focused on releasing 1.5.2.
Soo... considering vacations and whatnot, I'd say late August, or September? For sure in time for FOSS4G 2007 
Cheers
Andrea
Andrea Aime wrote:
Matthias Schulz ha scritto:
Hi Andrea and Justin,
thank you very much for your prompt help, great! Seems this is exactly what I am looking for. I tried to get a feeling of your roadmap to see when 1.6 could be used for a productive system. What would you say?
Hem, after releasing 1.6.0-beta2 we're now focused on releasing 1.5.2.
Soo... considering vacations and whatnot, I'd say late August, or September? For sure in time for FOSS4G 2007
And do note that if you're testing it out and using it a lot that will make it easier for us to go 1.6.0 soon. We'd be happy to prioritize your requests, since we really want people testing it. Most things should be pretty stable already, we're using it on our production system at http://sigma.openplans.org
best regards,
Chris
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,469c9216269607180515871!