Would it be useful to be able to configure the GeoServer data directory via JNDI? An <env-entry>, perhaps?
Alas, the J2EE spec mandates <resource-ref> in web.xml if you want to access JNDI data sources, otherwise we could have a zero-configuration GeoServer deployment with everything in an external data directory.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
What would be the benefit over how it is configured now via the context parameter? Unless there is some benefit I would generally be against it since it would yet another way to do the same thing. And unless you are a perl programmer multiple ways to do the same thing can be confusing 
Ben Caradoc-Davies wrote:
Would it be useful to be able to configure the GeoServer data directory via JNDI? An <env-entry>, perhaps?
Alas, the J2EE spec mandates <resource-ref> in web.xml if you want to access JNDI data sources, otherwise we could have a zero-configuration GeoServer deployment with everything in an external data directory.
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Ben Caradoc-Davies ha scritto:
Would it be useful to be able to configure the GeoServer data directory via JNDI? An <env-entry>, perhaps?
Alas, the J2EE spec mandates <resource-ref> in web.xml if you want to access JNDI data sources, otherwise we could have a zero-configuration GeoServer deployment with everything in an external data directory.
Hum, could be a good idea for any other configuration that we
already look for in web.xml, system properties and env vars.
See GeoServerExtensions for the code that does the lookups
in the three ways reported above.
What we could do is to have a well known JNDI location that
we pre-declare in web.xml so that people do not have to fiddle
with the web.xml contents?
Cheers
Andrea
Justin Deoliveira ha scritto:
What would be the benefit over how it is configured now via the context parameter? Unless there is some benefit I would generally be against it since it would yet another way to do the same thing. And unless you are a perl programmer multiple ways to do the same thing can be confusing
LOL
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
Cheers
Andrea
Andrea Aime wrote:
Justin Deoliveira ha scritto:
What would be the benefit over how it is configured now via the context parameter? Unless there is some benefit I would generally be against it since it would yet another way to do the same thing. And unless you are a perl programmer multiple ways to do the same thing can be confusing
LOL
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
yeah.. thinking about it I guess ti could be nice to set up a single jndi reference, and be able to configure it to point to various different places without fiddling with any geoserver config. So yeah... i could go for this.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Andrea Aime wrote:
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
Exactly. Just set up your options and resources in Tomcat, configure everything via JNDI, then deploying an updated GeoServer (with an external data directory) is as easy as dropping in a new WAR and letting Tomcat auto-deploy. This cannot be done now because web.xml must be hacked. Deployment scripts and "patch -p0" are your friend.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
What would be the benefit over how it is configured now via the context parameter? Unless there is some benefit I would generally be against it since it would yet another way to do the same thing. And unless you are a perl programmer multiple ways to do the same thing can be confusing
LOL
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
yeah.. thinking about it I guess ti could be nice to set up a single jndi reference, and be able to configure it to point to various different places without fiddling with any geoserver config. So yeah... i could go for this.
One thing that is not clear to me is whether it's possible to declare
access to a root in JNDI and then be able to access by it all resources
under it, or if any resource has to be declared separately.
The former would be oh so much nicer
Ben, Christian, any clue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ben Caradoc-Davies ha scritto:
Andrea Aime wrote:
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
Exactly. Just set up your options and resources in Tomcat, configure everything via JNDI, then deploying an updated GeoServer (with an external data directory) is as easy as dropping in a new WAR and letting Tomcat auto-deploy. This cannot be done now because web.xml must be hacked. Deployment scripts and "patch -p0" are your friend.
Yeah. The topic is interesting. Do you have any sample script to
share?
I guess having some guidance in the user guide on how to deal with
upgrades in production enviroments would be cool.
As for configuring up GeoServer, a web application where one
can select which extensions he wants (and maybe a choice of
release or empty data dir) and have it assemble
a custom GeoServer could be quite popular.
It would not work fine with all extensions (e.g., SDE, where
one has to hand add extra jars) but would be good anyways.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
One thing that is not clear to me is whether it's possible to declare
access to a root in JNDI and then be able to access by it all resources
under it, or if any resource has to be declared separately.
The former would be oh so much nicer
Ben, Christian, any clue?
I was reading the J2EE spec earlier today and I have the horrible recollection that it says you *must* declare every reference in web.xml, to force you to enumerate them (the latter of your options). This does not stop Jetty, which appears to ignore this stupid, stupid rule. Yay for Jetty! This is why Jetty debugging works with JNDI without touching the web.xml.
Page 72 of the J2EE 1.4 spec: "... the Application Component Provider must declare all the resource manager connection factory references in the deployment descriptor using the resource-ref elements. This allows the consumer of the application component’s JAR file (the Application Assembler or Deployer) to discover all the resource manager connection factory references used by an application component."
Yet another piece of horrible interface design. It prevents any application from accessing a resource unknown to the bundler, that might be named at runtime (e.g. GeoServer JNDI data sources named through the UI).
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
If I understand you right, you want a node in the jndi directory structure acting as the root node for the application.
See the followoing examples, the initial root node is passed with "java.naming.provider.url".
# java -Djava.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory \
-Djava.naming.provider.url=ldap://localhost:389/o=jnditutorial \
List
# java -Djava.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory \
-Djava.naming.provider.url=file:/tmp \
List
java:comp/env does something similiar. This pseudo var is resolved to node in the hierarchy which is NOT the root node in the directory tree.
Andrea Aime writes:
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Justin Deoliveira ha scritto:
What would be the benefit over how it is configured now via the context parameter? Unless there is some benefit I would generally be against it since it would yet another way to do the same thing. And unless you are a perl programmer multiple ways to do the same thing can be confusing
LOL
It would seem that people find fiddling with JNDI entries preferrable
than editing files. It's probably easier to do that with bigger containers or just the way webapp admins are used to, who knows
yeah.. thinking about it I guess ti could be nice to set up a single jndi reference, and be able to configure it to point to various different places without fiddling with any geoserver config. So yeah... i could go for this.
One thing that is not clear to me is whether it's possible to declare
access to a root in JNDI and then be able to access by it all resources
under it, or if any resource has to be declared separately.
The former would be oh so much nicer
Ben, Christian, any clue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ben, you are not forced to put the geoserver config data into the j2ee directory tree. Geoserver can create its own initial context for its data on startup.
I did this actually using an ldap server, getting my own initial Context and handling user profiles within J2EE (Websphere). Forget about j2ee jndi data, we create or own context and thats it.
Btw, it is a very good idea to put the config data into jndi, I would give a +++++++++++++1
Ben Caradoc-Davies writes:
Andrea Aime wrote:
One thing that is not clear to me is whether it's possible to declare
access to a root in JNDI and then be able to access by it all resources
under it, or if any resource has to be declared separately.
The former would be oh so much nicer
Ben, Christian, any clue?
I was reading the J2EE spec earlier today and I have the horrible recollection that it says you *must* declare every reference in web.xml, to force you to enumerate them (the latter of your options). This does not stop Jetty, which appears to ignore this stupid, stupid rule. Yay for Jetty! This is why Jetty debugging works with JNDI without touching the web.xml.
Page 72 of the J2EE 1.4 spec: "... the Application Component Provider must declare all the resource manager connection factory references in the deployment descriptor using the resource-ref elements. This allows the consumer of the application component’s JAR file (the Application Assembler or Deployer) to discover all the resource manager connection factory references used by an application component."
Yet another piece of horrible interface design. It prevents any application from accessing a resource unknown to the bundler, that might be named at runtime (e.g. GeoServer JNDI data sources named through the UI).
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Andrea Aime wrote:
Ben Caradoc-Davies ha scritto:
Deployment scripts and "patch -p0" are your friend.
Yeah. The topic is interesting. Do you have any sample script to
share?
I am rewriting one at the moment. I will publish it when it is done.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia