-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/10/2014 9:43 AM, André Warnier wrote:
> Mark Eggers wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote:
>>> Hello
>>>
>>> We have a setup which compiles WAR applications once and
>>> deploys them in various environments. Each environment has its
>>> own per application Log4j configuration (WARN for production,
>>> DEBUG for development etc.) which should survive application
>>> redeployment.
>>>
>>> So far the solution is:
>>>
>>> webapps/myapp/WEB-INF/web.xml
>>>
>>> ... <context-param>
>>> <param-name>log4jConfigLocation</param-name>
>>> <param-value>file:///opt/tomcat6/conf/myapp/log4j.xml</param-value>
>>>
>>>
>>>
>>
>>>
</context-param>
>>> ...
>>>
>>> Pretty standard, works.
>>>
>>> Question is, how can I make sure the Log4j configuration path
>>> is not hard coded in the 'web.xml' at development time. Idea
>>> was:
>>>
>>> webapps/myapp/META-INF/context.xml ... <Parameter
>>> name="log4jConfigLocation" value="file://TBD" /> ...
>>>
>>> and change it after the application deployment:
>>>
>>> conf/Catalina/localhost/myapp.xml ... <Parameter
>>> name="log4jConfigLocation"
>>> value="file:///opt/tomcat6/conf/myapp/log4j.xml" /> ...
>>>
>>> Tomcat simply ignores both of these context XML files, or at
>>> least the parameters defined in them. I read through all
>>> mailing lists, all documentations, switched on debug to the
>>> 'finest' level, still no avail. How difficult can this be?
>>>
>>> Details:
>>>
>>> Server version: Apache Tomcat/6.0.35 Server built: Nov 28
>>> 2011 11:20:06 Server number: 6.0.35.0 OS Name: Linux
>>> OS Version: 2.6.18-348.el5 Architecture: amd64 JVM Version:
>>> 1.6.0_30-b12 JVM Vendor: Sun Microsystems Inc.
>>>
>>>
>>> Cheers B.
>>>
>>
>> I'm just noodling - haven't tried this. Your mileage may vary,
>> void where prohibited, etc., etc., etc.
>>
>> How about:
>>
>> 1. use Parameter in context.xml to set the logging level:
>>
>> <Parameter name="LoggingLevel" value="DEBUG" override="false"/>
>>
>> 2. Write a servlet context listener to read the parameter
>>
>> 3. Set the logging level accordingly
>>
>> Place the servlet context listener as the first one in your
>> web.xml so the new logging level is set before any other logging
>> occurs.
>>
>> This way your log4j.xml doesn't have to change, and you can just
>> use an appropriate
>> $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the
>> desired logging level.
>>
>> This seems as if it should work.
>>
>> . . . just my two cents /mde/
>
> Mark, I was watching this thread, because I think that the original
> question has a wider scope, which has been touched a few times in
> the past, but to which I have never seen a really convincing
> answer. Example : I have customers who are security-conscious, and
> I do not have access to their servers. When I need to send them an
> application update, it must be in the form of a WAR, which the
> local sysadmins then deploy on the server. But in that application,
> there is a third-party authentication servlet filter, which
> requires 3 parameters in web.xml : - the FQDN of an authentication
> server - a login on that authentication server - a password for
> that login This is specific to each customer. (Of course, there are
> plenty more parameters in web.xml which are not customer-specific,
> but may change with a new version of the app).
>
> So I cannot make a single WAR, and just send it to all. I have
> (for now) to create a separate WAR for each customer. And I have to
> know their password, which they do not like.
>
> Otherwise, my customer sysadmins would have to unpack the WAR,
> edit web.xml to insert their specific values, and re-pack the WAR.
> Which they do not like to do either.
>
> My customers also do not like a solution consisting in having
> these parameters defined somehow as JVM properties that must be
> given on the java command-line, because then any user with a
> console on the server can see them by doing a simple "ps -ef".
>
> So, yes, there are a lot of things which they don't like. But such
> it is, and I am only a small supplier happy to have them as
> customer, and I do not want to pick a fight with the sysadmins.
> Because that's like picking a fight with a waiter in a restaurant
> (*).
>
> So is there an easy generic way to solve this, without having to
> write some specific code to do it ? (which I think would also solve
> the OP's problem)
>
>
>
> (*) I once heard one say to a colleague : "Did you see ? he ate
> it."
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
André,
I am not aware of any generic Tomcat mechanism to do this without some
code. The quick and dirty method that I described in the previous
message is Tomcat-specific (which is OK since this is the Tomcat
mailing list).
I can think of a few ways to do this, but all would require some code.
A. Parameters in appname.xml (ie., application-specific context.xml)
You can do this and read the parameters from a listener and configure
a singleton. Then when you need to use the authentication /
authorization parameters, you can pry those out of the singleton with
very little cost.
If you're using the authorization / authentication parameters with a
Tomcat-controlled pool, I don't know how this would work. I suspect a
different mechanism would be in order.
B. JNDI parameters in appname.xml (ie., application-specific
context.xml)
This is probably more portable, because at least in some application
servers you can set JNDI values from an administration application
(not sure about Websphere, though).
- From the fine Tomcat documentation:
<Environment name="maxExemptions" value="10"
type="java.lang.Integer" override="false"/>
Then everywhere you need the environment variable maxExemptions, you
could write some JNDI code like the following pseudo-code:
Context ctx = new InitialContext();
Integer maxExemptions = ctx.lookup("java:comp/env/maxExemptions");
Try / catch and other issues are left as exercises for the reader.
Both of these mechanisms would allow an operator / administrator to
change the appropriate values at the server level without the
knowledge of the developer (at startup only, obviously).
The only thing that would have to remain in sync would be what needs
to be changed (documentation for the administrators - how novel).
C. JMX / MBeans
This is probably a bit more complex. You could expose the values as
editable via mbeans, and then use a suitably protected JMX connection
to change the values on the fly.
There are several advantages to this.
1. JMX management may already be available at your customers' sites
2. JMX can be secured via firewalls / SSL
3. You can change the values on a running application
4. mbean descriptors can help determine what needs to be changed
5. JMX doesn't depend on a container's ability to manage JNDI
information
I'd vote for mechanism C if as a former coworker used to say: "Is the
juice worth the squeeze?"
. . . just my two cents
/mde/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
iQEcBAEBAgAGBQJUEJ6zAAoJEEFGbsYNeTwtX7IIAK/4gi+vq+XoY4YkEW7vCF5l
g5rqgSUl2KGnO5xtoFsMDeOOUkNYBRpfR+QTAUE7Hd0dK8Ttv2UbQqrMtQ2C/mkH
7dcli8DdaH0hV6og3Zs6h0Odp+wrpQs9gFP9HtaVRUwnib+LAOHOTO10o3NDdrku
ADbDFLp2h/XNqYX+Z7NUxBwEtK63eNLGHaYrxDjxObftCMeY3D3VnojjtXp+rWMZ
DixZt9CeKKJvGCJKy9S9xQ67QAY1EFepGDXx1lprz/ltupGGcgYcEl/RXXFemnZS
qEB4jqp5t4gGAsVQN1wDKSjmBt4DPEAwWENekB+/lij1QEq/2LJAkCAwHAhx1WE=
=7LiW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
