Folks,
we have DB2 and WebLogic 9.2 on Solaris, and the sysadmin is asking us to use a database connection from the connection pool managed by WebLogic instead of a direct JDBC connection: could someone tell me how to do it ?
Regards,
--------------------
Luca Morandini
www.lucamorandini.it
--------------------
(cc'ing geotools-devel because someone may be willing to chime in
and comment on this issue)
Luca Morandini ha scritto:
Folks,
we have DB2 and WebLogic 9.2 on Solaris, and the sysadmin is asking us to use a database connection from the connection pool managed by WebLogic instead of a direct JDBC connection: could someone tell me how to do it ?
Sure, out of the box, as far as I know, you can't 
None of the jdbc data stores accept a jndi reference to a connection pool, and pretend to use its own connection pool.
Have a look at the DB2DataStore, the DB2DataStoreFactory and the org.geotools.data.jdbc.ConnectionPool class, and see if you manage
to change the db2 datastore code enough to make it use a JNDI provided
connection pool.
Cheers
Andrea
I'll see what I can find out but I really don't have any familiarity with connection
pooling.
GeoTools appears to have some connection pooling support but it isn't really
clear to me how/if it works. The DB2 plug-in seems to work fine with this support.
I don't know if any of the other GeoTools database plugins work with WebLogic
or similar connection pooling spuport.
Regards,
David
At 09:10 AM 10/26/2006, Luca Morandini wrote:
Folks,
we have DB2 and WebLogic 9.2 on Solaris, and the sysadmin is asking us
to use a database connection from the connection pool managed by
WebLogic instead of a direct JDBC connection: could someone tell me how
to do it ?Regards,
--------------------
Luca Morandini
www.lucamorandini.it
---------------------------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Yeah, GeoTools connection pooling works great, but the problem is that it doesn't integrate with others. We need to rework our jdbc datastores to be able to take advantage of JNDI and to use other connection pools, to completely abstract that part out. As GeoServer becomes more of an framework and is used more in production this is going to become an increasingly popular request, we should investigate it sometime soon. If someone has time to look in to it now that would be great - I don't _think_ it should be all that hard to do - I believe we just need to make a different factory and to not pass the full connection pool to datastores but just an abstraction that lets them get and return connections.
best regards,
Chris
David Adler wrote:
I'll see what I can find out but I really don't have any familiarity with connection
pooling.GeoTools appears to have some connection pooling support but it isn't really
clear to me how/if it works. The DB2 plug-in seems to work fine with this support.I don't know if any of the other GeoTools database plugins work with WebLogic
or similar connection pooling spuport.Regards,
DavidAt 09:10 AM 10/26/2006, Luca Morandini wrote:
Folks,
we have DB2 and WebLogic 9.2 on Solaris, and the sysadmin is asking us
to use a database connection from the connection pool managed by
WebLogic instead of a direct JDBC connection: could someone tell me how
to do it ?Regards,
--------------------
Luca Morandini
www.lucamorandini.it
---------------------------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users!DSPAM:1003,4540b8b7273414750375898!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Yeah, GeoTools connection pooling works great, but the problem is that it doesn't integrate with others. We need to rework our jdbc datastores to be able to take advantage of JNDI and to use other connection pools, to completely abstract that part out. As GeoServer becomes more of an framework and is used more in production this is going to become an increasingly popular request, we should investigate it sometime soon. If someone has time to look in to it now that would be great - I don't _think_ it should be all that hard to do - I believe we just need to make a different factory and to not pass the full connection pool to datastores but just an abstraction that lets them get and return connections.
Well, that abstraction has been defined in java 1.4 and it's called
DataSource: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html
Connection pool libraries do implement this interface and usually
provide more than just connection pooling, that is, also prepared
statement pooling, which can improve query performance a lot on
databases like oracle.
An example:
http://jakarta.apache.org/commons/dbcp/apidocs/index.html?org/apache/commons/dbcp/BasicDataSource.html
Cheers
Andrea
Andrea Aime wrote:
Chris Holmes ha scritto:
Yeah, GeoTools connection pooling works great, but the problem is that it doesn't integrate with others. We need to rework our jdbc datastores to be able to take advantage of JNDI and to use other connection pools, to completely abstract that part out. As GeoServer becomes more of an framework and is used more in production this is going to become an increasingly popular request, we should investigate it sometime soon. If someone has time to look in to it now that would be great - I don't _think_ it should be all that hard to do - I believe we just need to make a different factory and to not pass the full connection pool to datastores but just an abstraction that lets them get and return connections.
Well, that abstraction has been defined in java 1.4 and it's called
DataSource: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html
Right, then we need to use it. Right now we pass in an org.geotools.data.jdbc.ConnectionPool. I suppose we could actually just make it an interface and naively implement it with dbcp or some such (or even better make it pluggable there too). That's all I meant by abstracting it out - in our own code. And to do it in such a way that we can easily revert if the library is functioning exactly as we'd like.
The code we have in there now seems to do management that a library would handle properly now.
Once we can pass a javax.sql.ConnectionPoolDataSource directly to the jdbc implementations we'll be in good shape. Then we just need a way to go from jndi -> datastore.
Chris
Connection pool libraries do implement this interface and usually
provide more than just connection pooling, that is, also prepared
statement pooling, which can improve query performance a lot on
databases like oracle.
An example:
http://jakarta.apache.org/commons/dbcp/apidocs/index.html?org/apache/commons/dbcp/BasicDataSource.htmlCheers
Andrea!DSPAM:1003,4540d2b3294551429667743!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Guys,
First off, great job on the 1.4.x RC release; it's a big improvement over 1.3.x
The issue I'm running into has to do with the naming of files (ie kml and shp) returned by Geoserver. Would there be a way, instead of returning just a header and a file entitled "wfs" and "wms", to return the feature name and an extension (eg states.zip). I'm trying to get some of our clients to use geoserver, but they get confused when all that is returned is just a "wms" or "wfs" file. I tell them to just rename the file upon downloading it, but that's a not a real scalable/ideal solution.
I was going to mention that the option to return zipped GML isn't working either, but checked the bugzilla and see that it's on the hit parade of bugs to be squashed.
Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline
Dave Shroeder wrote:
Guys,
First off, great job on the 1.4.x RC release; it's a big improvement over 1.3.x
Thanks! We definitely try to get better with each and every release. Out of curiosity which improvements do you like?
The issue I'm running into has to do with the naming of files (ie kml and shp) returned by Geoserver. Would there be a way, instead of returning just a header and a file entitled "wfs" and "wms", to return the feature name and an extension (eg states.zip). I'm trying to get some of our clients to use geoserver, but they get confused when all that is returned is just a "wms" or "wfs" file. I tell them to just rename the file upon downloading it, but that's a not a real scalable/ideal solution.
Could you file a jira feature request for this? See: http://docs.codehaus.org/display/GEOSDOC/1+Reporting+Issues
It is a nice suggestion, it would be a cleaner way to handle things. I'm not sure how easy it would be to implement - it may have to entail us writing to disk first - the nice thing about the way stuff currently works is we stream straight from the database to the output.
Just looked online and it looks like there's some header stuff we can set: http://forum.java.sun.com/thread.jspa?threadID=486951&tstart=135
Your suggestion is to use the featureType name plus a zip or gzip or kmz extension? Probably won't get this for RC2, as it's going out quite soon, but if it's easy to fix I'd like to get it in soon, I've been annoyed by that in the past.
I was going to mention that the option to return zipped GML isn't working either, but checked the bugzilla and see that it's on the hit parade of bugs to be squashed.
Hrm, it should have already been hit: http://jira.codehaus.org/browse/GEOS-692
You're using RC1? What is the problem you have with it? If it's not working then that bug should be re-opened.
best regards,
Chris
Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,4542c388229171194215290!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Hi Dave,
about returning friendlier file names for packed content, it would be possible
as long as asking the HTTP client to redirect to another resource is
acceptable.
Rationale: from an HTTP point of view, accessing the wfs, the wms or any other
resource, either with CGI parameters or not, just means that, givme this
resource. And in the case of wfs the resource to download is denoted by the
wfs path, so you get a resource names "wfs", which is the terminal resource
name in the URL.
Now, I've been done what you're asking for in other projects (for example, to
return meaningful names for dynamicaly generated PDF reports), and the
approach is:
- Client asks for content to a dynamic content generator (servlet?) through an
URL
- Server executes the request and generates the content
- Server assigns a keyword (file name?) to the content and asks the client to
redirect over another URL (i.e. if original was http://server/wfs?… it is
redirected to http://server/downloads/states.zip)
- Upon redirection, a servlet filter configured to serve downloads/* catches
up the request and sends the content previously stored.
The only pitfall with this approach would be the imposition that the client
supports HTTP url redirection, which I guess wouldn't be a big dead
nowadays?.
2c-
Gabriel
On Saturday 28 October 2006 04:41, Dave Shroeder wrote:
Guys,
First off, great job on the 1.4.x RC release; it's a big improvement over
1.3.xThe issue I'm running into has to do with the naming of files (ie kml and
shp) returned by Geoserver. Would there be a way, instead of returning just
a header and a file entitled "wfs" and "wms", to return the feature name
and an extension (eg states.zip). I'm trying to get some of our clients to
use geoserver, but they get confused when all that is returned is just a
"wms" or "wfs" file. I tell them to just rename the file upon downloading
it, but that's a not a real scalable/ideal solution.I was going to mention that the option to return zipped GML isn't working
either, but checked the bugzilla and see that it's on the hit parade of
bugs to be squashed.Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today!
http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=
hmtagline-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
Hi Chris,
I responded previously without reading your post, seems like the
Content-Disposition header would be more straight-forward than my solution,
damn I didn't knew it before
for reference, spec here: http://www.ietf.org/rfc/rfc1806.txt
Gabriel
On Saturday 28 October 2006 05:00, Chris Holmes wrote:
Dave Shroeder wrote:
> Guys,
>
> First off, great job on the 1.4.x RC release; it's a big improvement over
> 1.3.xThanks! We definitely try to get better with each and every release.
Out of curiosity which improvements do you like?> The issue I'm running into has to do with the naming of files (ie kml and
> shp) returned by Geoserver. Would there be a way, instead of returning
> just a header and a file entitled "wfs" and "wms", to return the feature
> name and an extension (eg states.zip). I'm trying to get some of our
> clients to use geoserver, but they get confused when all that is returned
> is just a "wms" or "wfs" file. I tell them to just rename the file upon
> downloading it, but that's a not a real scalable/ideal solution.Could you file a jira feature request for this? See:
http://docs.codehaus.org/display/GEOSDOC/1+Reporting+IssuesIt is a nice suggestion, it would be a cleaner way to handle things.
I'm not sure how easy it would be to implement - it may have to entail
us writing to disk first - the nice thing about the way stuff currently
works is we stream straight from the database to the output.Just looked online and it looks like there's some header stuff we can
set: http://forum.java.sun.com/thread.jspa?threadID=486951&tstart=135Your suggestion is to use the featureType name plus a zip or gzip or kmz
extension? Probably won't get this for RC2, as it's going out quite
soon, but if it's easy to fix I'd like to get it in soon, I've been
annoyed by that in the past.> I was going to mention that the option to return zipped GML isn't working
> either, but checked the bugzilla and see that it's on the hit parade of
> bugs to be squashed.Hrm, it should have already been hit:
http://jira.codehaus.org/browse/GEOS-692
You're using RC1? What is the problem you have with it? If it's not
working then that bug should be re-opened.best regards,
Chris
> Cheers
>
> _________________________________________________________________
> Try the next generation of search with Windows Live Search today!
> http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&sourc
>e=hmtagline
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:1003,4542c388229171194215290!
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
Dave Shroeder ha scritto:
I was going to mention that the option to return zipped GML isn't working either, but checked the bugzilla and see that it's on the hit parade of bugs to be squashed.
Indeed it should be already fixed unless it broke again... if you're expecting to have the browser ask you to save an xxx.gml.gz file that won't happen, because gzip compression is transparently handled as part
of the http protocol, but should be there even if you don't see it.
You can check if the compression is actually working using the same
method I used on issue 692:
http://jira.codehaus.org/browse/GEOS-692
Cheers
Andrea Aime
Gabriel Roldán ha scritto:
Hi Chris,
I responded previously without reading your post, seems like the Content-Disposition header would be more straight-forward than my solution, damn I didn't knew it beforefor reference, spec here: http://www.ietf.org/rfc/rfc1806.txt
Interesting stuff, worth implementing before 1.4.0 I'd say.
Cheers
Andrea
Chris Holmes ha scritto:
Could you file a jira feature request for this? See: http://docs.codehaus.org/display/GEOSDOC/1+Reporting+Issues
It is a nice suggestion, it would be a cleaner way to handle things. I'm not sure how easy it would be to implement - it may have to entail us writing to disk first - the nice thing about the way stuff currently works is we stream straight from the database to the output.
Well, according to the code in ShapeFeatureResponseDelegate we are writing a temporary file anyways? We are streaming GML because it's a single file, but streaming a zip made of multiple files its simply not
possible as far as I know...
Cheers
Andrea
Response inline
From: Chris Holmes <cholmes@anonymised.com>
To: Dave Shroeder <huskytec@anonymised.com>
CC: geoserver-users@lists.sourceforge.net, geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Geoserver 1.4.x File Naming?
Date: Fri, 27 Oct 2006 23:00:27 -0400Dave Shroeder wrote:
Guys,
First off, great job on the 1.4.x RC release; it's a big improvement over 1.3.x
Thanks! We definitely try to get better with each and every release. Out of curiosity which improvements do you like?
Basically, that it works a lot better than the 1.3.x version. A number of really annoying bugs (eg the shapefile big decimal error) were squashed, and adding some useful new features (eg inclusion of metadata file location) without blowing up the code (I have a number of files in place to automate the adding and deleting of layers from within Geoserver from a CLI, so the less I have to modify these files for each release, the better).
The issue I'm running into has to do with the naming of files (ie kml and shp) returned by Geoserver. Would there be a way, instead of returning just a header and a file entitled "wfs" and "wms", to return the feature name and an extension (eg states.zip). I'm trying to get some of our clients to use geoserver, but they get confused when all that is returned is just a "wms" or "wfs" file. I tell them to just rename the file upon downloading it, but that's a not a real scalable/ideal solution.
Could you file a jira feature request for this? See: http://docs.codehaus.org/display/GEOSDOC/1+Reporting+Issues
Done.
It is a nice suggestion, it would be a cleaner way to handle things. I'm not sure how easy it would be to implement - it may have to entail us writing to disk first - the nice thing about the way stuff currently works is we stream straight from the database to the output.
I'm glad to see the creative juices are still flowing on a Friday night for you guys
Just looked online and it looks like there's some header stuff we can set: http://forum.java.sun.com/thread.jspa?threadID=486951&tstart=135
Your suggestion is to use the featureType name plus a zip or gzip or kmz extension? Probably won't get this for RC2, as it's going out quite soon, but if it's easy to fix I'd like to get it in soon, I've been annoyed by that in the past.
I was going to mention that the option to return zipped GML isn't working either, but checked the bugzilla and see that it's on the hit parade of bugs to be squashed.
Hrm, it should have already been hit: http://jira.codehaus.org/browse/GEOS-692
You're using RC1? What is the problem you have with it? If it's not working then that bug should be re-opened.
Ok, it looks like i was just confused on the capabilities. I thought instead of returning a compressed, gzip response (which it now does), it would actually return some zipped gml (similar to kml). The problem I'm having with this is that on a shapefile over 2 or 3 megs, anytime you request gml, or gzipped gml, that response back to the client (esp in mozilla) will freeze or lock up the browser. Perhaps, if the aforementioned friendly file naming can be implemented, Geoserver could return a gml file (instead of the raw GML) back to the user.
Thanks again guys!
best regards,
Chris
Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,4542c388229171194215290!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
<< cholmes.vcf >>
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial! http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
On Sat, October 28, 2006 6:48 am, Dave Shroeder wrote:
Response inline
From: Chris Holmes <cholmes@anonymised.com>
To: Dave Shroeder <huskytec@anonymised.com>
CC: geoserver-users@lists.sourceforge.net,
geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Geoserver 1.4.x File Naming?
Date: Fri, 27 Oct 2006 23:00:27 -0400Dave Shroeder wrote:
Guys,
First off, great job on the 1.4.x RC release; it's a big improvement
over 1.3.xThanks! We definitely try to get better with each and every release.
Out
of curiosity which improvements do you like?Basically, that it works a lot better than the 1.3.x version. A number of
really annoying bugs (eg the shapefile big decimal error) were squashed,
and adding some useful new features (eg inclusion of metadata file
location) without blowing up the code (I have a number of files in place
to automate the adding and deleting of layers from within Geoserver from a
CLI, so the
less I have to modify these files for each release, the better).
Cool. Yeah, we're going to try to keep all configuration working for each
release, and will go to 2.0 if we have to break anything. So if on any
release things don't work as you expect, please let us know immediately.
In the future we want to improve the adding and deleting of layers with a
nicer API, so if you have suggestions about how you'd like to use it
that'd be great. Actually I'll try to start a wiki page soon, just so we
can slowly gather requirements for how people would like to interact
programmatically with geoserver.
I was going to mention that the option to return zipped GML isn't
working either, but checked the bugzilla and see that it's on the hit
parade of bugs to be squashed.Hrm, it should have already been hit:
http://jira.codehaus.org/browse/GEOS-692
You're using RC1? What is the problem you have with it? If it's not
working then that bug should be re-opened.Ok, it looks like i was just confused on the capabilities. I thought
instead of returning a compressed, gzip response (which it now does), it
would actually return some zipped gml (similar to kml). The problem I'm
having with this is that on a shapefile over 2 or 3 megs, anytime you
request gml, or gzipped gml, that response back to the client (esp in
mozilla) will freeze or lock up the browser. Perhaps, if the
aforementioned friendly file naming can be implemented, Geoserver could
return a gml file (instead of the raw GML) back to the user.
Could you file a feature request for this too? I'd probably make it a
different producer option, since I think sometimes people may want it as
it works now. I'll have to think about it.
As for large files returning GML, what I usually do is a wget command line
call if I want the whole file, and if I just want to check out what's
going on I use the maxfeatures param to limit it.
best regards,
Chris
Thanks again guys!
best regards,
Chris
Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today!
http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&so
urce=hmtagline---------------------------------------------------------------------
----
Using Tomcat but need to do more? Need to support web services,
security? Get stuff done quickly with pre-integrated technology to
make your job easier Download IBM WebSphere Application Server v.1.0.1
based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121
642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Chris Holmes
The Open Planning Project
http://topp.openplans.org<< cholmes.vcf >>
_________________________________________________________________
All-in-one security and maintenance for your PC. Get a free 90-day trial!http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://
www.windowsonecare.com/?sc_cid=msn_hotmail!DSPAM:1003,454335c0269196309890654!
That's great. Can you share the code so we can see how you did it?
That's nice we've got the createConnection method all abstracted out already, I had forgotten about that. Did you have OracleJNDIDataStore extend OracleDataStore? It seems like you could just have it use a different constructor and then just override the createConnection method (at least if it weren't for the annoying OracleConnection stuff).
It sounds like there should be a nice way to handle this stuff, I just don't know JNDI that well, and how it's used in practice, so at least seeing what params your factory uses would be cool.
best regards,
Chris
Alcer (Raphael Gaquer) wrote:
Hi!
we are working with Oracle10g and JBoss on Windows and we have the same need : to use in our DataStore a J2EE connection pool referenced by JNDI.
So we made the followings changes/evolutions to test a solution :
- we have created a new specific couple of DataStore/DataStoreFactory classes (called OracleJNDIDataStore and OracleJNDIDataStoreFactory)
- we used a specific 'dbtype' parameter with 'oracleJ' value and configured our 'catalog.xml' in consequenceAnd our conclusions are (by now) :
- it works fine !
- the ConnectionPool class is not needed anymore because it is replaced by the JBoss/Oracle connection pool.
- the most important method (in Oracle case, we don't know if it is equivalent with DB2DataStore) to replace/bypass org.geotools.data.jdbc.ConnectionPool
is the protected 'org.geotools.data.jdbc.JDBC2DataStore.createConnection()' method
- we don't know how to propose/implement a "clean" solution because of an Oracle problem/limitation when using specific OracleSpatial/Locator DB types (MDSYS.SDO_xxx) : the driver need to use directly an oracle.jdbc.OracleConnection to (de)serialize its objects. To assure the providing of an OracleConnection we made a workaround in both org.geotools.data.oracle.OracleFeatureWriter and org.geotools.data.oracle.attributeio.SDOAttributeIO
to get the underlying connection through the org.jboss.resource.adapter.jdbc.WrappedConnection class using 'getUnderlyingConnection()' method
[to do that we used Java introspection to prevent the need of JBoss classes in classpath during compilation]
=> today we don't know how to propose a "non J2EE server specific" solution !We hope that these informations would help you Luca and we hope also that someone could have some ideas to get a solution that would be easily integrated in Geoserver/Geotools.
Best regards,
Raphael
Andrea Aime a écrit :
(cc'ing geotools-devel because someone may be willing to chime in
and comment on this issue)Luca Morandini ha scritto:
Folks,
we have DB2 and WebLogic 9.2 on Solaris, and the sysadmin is asking us to use a database connection from the connection pool managed by WebLogic instead of a direct JDBC connection: could someone tell me how to do it ?
Sure, out of the box, as far as I know, you can't
None of the jdbc data stores accept a jndi reference to a connection pool, and pretend to use its own connection pool.Have a look at the DB2DataStore, the DB2DataStoreFactory and the org.geotools.data.jdbc.ConnectionPool class, and see if you manage
to change the db2 datastore code enough to make it use a JNDI provided
connection pool.Cheers
Andrea-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,4541ad6797532051017194!
------------------------------------------------------------------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642!DSPAM:1003,4541ad6797532051017194!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1003,4541ad6797532051017194!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Andrea Aime wrote:
Gabriel Roldán ha scritto:
Hi Chris,
I responded previously without reading your post, seems like the Content-Disposition header would be more straight-forward than my solution, damn I didn't knew it beforefor reference, spec here: http://www.ietf.org/rfc/rfc1806.txt
Interesting stuff, worth implementing before 1.4.0 I'd say.
I'd probably agree, especially since it looks pretty easy to do. Looks like we're going to need an RC3... Do we have a jira for it yet? I just added RC3 to jira.
Chris
Cheers
Andrea!DSPAM:1003,45431b2a259161336712104!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Andrea Aime wrote:
Gabriel Roldán ha scritto:
Hi Chris,
I responded previously without reading your post, seems like the Content-Disposition header would be more straight-forward than my solution, damn I didn't knew it beforefor reference, spec here: http://www.ietf.org/rfc/rfc1806.txt
Interesting stuff, worth implementing before 1.4.0 I'd say.
I'd probably agree, especially since it looks pretty easy to do. Looks like we're going to need an RC3... Do we have a jira for it yet? I just added RC3 to jira.
Here we go:
http://jira.codehaus.org/browse/GEOS-776
Check if the issue contents are really what you want.
Cheers
Andrea
...
The issue I'm running into has to do with the naming of files (ie kml and shp) returned by Geoserver. Would there be a way, instead of returning just a header and a file entitled "wfs" and "wms", to return the feature name and an extension (eg states.zip). I'm trying to get some of our clients to use geoserver, but they get confused when all that is returned is just a "wms" or "wfs" file. I tell them to just rename the file upon downloading it, but that's a not a real scalable/ideal solution.
Ok, I think we've got this for gml and shp, and we're going to try it for KMZ, but could you test it for us? My one slight worry is that it might mess up something when you're doing a live connection.
Often the file generated need not even be seen by google earth, since it can just be enabled as a live network link. I believe all should be fine, but just want to be sure we don't mess up any other ways of working right before 1.4.0
Chris
I was going to mention that the option to return zipped GML isn't working either, but checked the bugzilla and see that it's on the hit parade of bugs to be squashed.
Cheers
_________________________________________________________________
Try the next generation of search with Windows Live Search today! http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users!DSPAM:1003,4542c389229091804284693!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Chris Holmes ha scritto:
Right, then we need to use it. Right now we pass in an org.geotools.data.jdbc.ConnectionPool. I suppose we could actually just make it an interface and naively implement it with dbcp or some such (or even better make it pluggable there too). That's all I meant by abstracting it out - in our own code. And to do it in such a way that we can easily revert if the library is functioning exactly as we'd like.
The code we have in there now seems to do management that a library would handle properly now.
Once we can pass a javax.sql.ConnectionPoolDataSource directly to the jdbc implementations we'll be in good shape. Then we just need a way to go from jndi -> datastore.
Ah, the poorly implementing connection pooling is keeping on biting
our users, see for example this:
http://www.nabble.com/Google-Maps---WMS-Layer-tf2511606.html
The problem is, when do we address this? It's a pretty big change
for something like geotools 2.2.x which should be at its end of life...
Do we schedule it in the 1.5.0 timeframe against the gt 2.3.x code?
Cheers
Andrea