Would it be useful to be able to configure the GeoServer data directory
via JNDI? An , perhaps?
Alas, the J2EE spec mandates 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.
--
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 Ca
Ben Caradoc-Davies ha scritto:
> Would it be useful to be able to configure the GeoServer data directory
> via JNDI? An , perhaps?
>
> Alas, the J2EE spec mandates in web.xml if you want to
> access JNDI data sources, otherwise we could have a zero-configuration
> GeoServer deployment with eve
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
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
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
ever
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
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
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
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 \
-
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 abou
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
Software Engineer,
12 matches
Mail list logo
