Hey, sorry for the late respose Jody Garnett wrote: > That seems fine; if I understand things correctly you are looking to > share the arcsde connections between the datastore and grid coverage > using JNDI? Not at all. This is to configure an arcsde connection pool (which as you know has nothing to do with jdbc) the same way you can do for a javax.sql.DataSource. This allows for the configuration to be container wide and the geoserver config portable without changes to the catalog configuration, just like for any jdbc jndi datastore.
About sharing a pool between geotools ArcSDE's DataStore and gce instances, that's another issue. It'll certainly be possible once I get to port the gce implementation from the old ArcSDEPooledConnection to the new Session/Command queue. But for that to happen I'm also looking forward to the new coverage API cause I'm tired of having to encode the connection parameters on a URL for every GridCoverage in the database. Cheers, Gabriel > > Jody > > On Fri, Jul 3, 2009 at 2:35 AM, Gabriel Roldan<grol...@opengeo.org> wrote: >> Hi PMC, >> >> This is to inform I'm about to create a new project under the >> plugin/arcsde umbrella. >> >> I am developing JNDI support for the ArcSDE module. >> But as ArcSDE is not jdbc related, there's no JNDI ObjectFactory that >> can deal with it (as opposed to javax.sql.DataSource for which J2EE >> containers come already shipped with an ObjectFactory for, or rather you >> need to set the specific database jars on the container's common class >> loader). >> >> So the way to allow an ArcSDE connection config or even an ArcSDE >> connection pool out of a JNDI context, is to provide a custom >> javax.naming.ObjectFactory to be placed on the container's common class >> loader (hence visible both to the container and the web applications). >> >> Having my ObjectFactory on the same jar than the rest of the plugin >> doesn't work at least I put all the plugin dependencies on the common >> classloader to (eg, mv webapps/geoserver/WEB-INF/lib/*jar lib/), which >> is less than optimal. Hence the need for a separate jar. >> >> If any objections, please speak out soon. >> >> Cheers, >> Gabriel >> -- >> Gabriel Roldan >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
