Mark H. Wood wrote:
On Wed, Jun 09, 2010 at 05:20:22PM +0200, Thomas Kloeber wrote:
Mark H. Wood wrote on 09.06.2010 17:03:
On Wed, Jun 09, 2010 at 04:19:17PM +0200, Thomas Kloeber wrote:
the problems I have are:
* the IP address of the backing database is one of the parameters
that needs to be configured (in context.xml), so I can't get any
data from the db unless it is configured...
* the other confgurables (SPNEGO and kerberos stuff) are in web.xml
and as long as they are not set up correct, my app won't start!
* sounds like a catch 22 to me ...
Context parameter pointing to a properties file somewhere? Then you
can put the settings wherever you want them, and move them anytime
with minimal fuss. Install the app. outside of any appBase and use an
external Context file
($CATALINA_BASE/conf/Catalina/<hostname>/<contextname>.xml)
to point to it and provide the parameter's value:
<Context docBase='/some/where/myapp'>
<Parameter name='configuration'
value='/some/where/else/myapp.properties'
description='where the configurables are'/>
</Context>
You could just define the configurables as separate Parameters, but I
would keep them separated from configuration of the servlet container
(which the above is) if possible. Tastes vary.
sounds like a good idea, but what about the web.xml stuff? Can I use
some redirection there as well?
I guess I don't understand why web.xml must be customized at all.
In Tomcat, <Resource>s can be configured in a <Context>; <Environment>
entries can be made in a <Context>; initialization parameters can
be set in a <Context>. Is there something else? And Tomcat allows
you to place the <Context> declaration outside of the app. as noted above.
Caldarale, Charles R wrote on 09.06.2010 17:04:
how do you "make changes in context.xml inside archive"?
Unpack it with the jar utility, update, repack. Alternatively, you can supply
the<Context> element in a separate file, and have the admin put that in
conf/Catalina/[host]/[appName].xml after modifying the site-specific attributes.
I was afraid you say something like that, but to me that is why to
complicated/error prone...
I agree. This always feels to me like telling someone that he can
configure his word processor by using a binary editor on the
executable. Customers should never have to put their fingers inside
the app; it should get customer-specific information from some place
whose location is told to it at startup.
Let me speak for the OP, and for others like me who do not necessarily
write the applications and filters which they are installing on customer
systems.
Sometimes, you have to deal with such third-party modules, which have to
be used e.g. as a servlet filter in conjunction with your own
application. And sometimes, these third-party modules are like they are
and you cannot change their code. And sometimes, they require some
site-specific parameters, which they expect to be in their respective
<filter> section inside the application's web.xml file.
A typical example in my case is authentication servlet filters, which
require for example a domain name or a domain controller address which
is specific to each given customer.
If at the same time you have a customer who insists on receiving war
files for application updates, you're cooked, because you have to build
a customer-specific war file every time.
One suggestion I have in the case of Tomcat - and unfortunately only in
the case of Tomcat - would be an extension mechanism to the web.xml
file, which would allow some form of "include" in the web.xml.
(And maybe this would not be an extension, nor a Tomcat-specific thing,
if XML per se already allowed such things).
Then one could insert in web.xml something like this :
...
<filter>
<filter-name>NtlmHttpFilter</filter-name>
<filter-class>jcifs.http.NtlmHttpFilter</filter-class>
<!-- %%include-fragment: /some/path/local/to/customer/localparams.xml
%% -->
...
</filter>
...
and in localparams.xml one would have e.g. :
<fragment>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>EU</param-value>
</init-param>
</fragment>
(The above example being from some obsolete and no longer recommendable
piece of software).
Is something like that possible ?
Because then, you could set up the localparams.xml file once for a given
customer (and it would even be easy for them to edit it if needed), and
supply them in the future with updated war files which would always be
indentical for all customers, and this without having to modify the
third-party filter code (which is not necessarily open-source).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
