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<
[hidden email]> 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
>>
[hidden email]
>>
https://lists.sourceforge.net/lists/listinfo/geotools-devel>>
--
Gabriel Roldan
OpenGeo -
http://opengeo.orgExpert 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
