We have Log4j packaged within the WAR for each of the deployed applications.
Under run-time configuration I mean editing the standard log4j.xml which is
re-read by Tomcat. (I.e. we do not want to reimplement any log level
configuration in servlet configuraton, what we want is to pass the locati
Hi,
I am trying to deploy application as ROOT.war in tomcat 7.50 provided by
hosting service provider, but for some reasons I get below message
FAIL - War file "ROOT.war" cannot be uploaded if context is defined in
server.xml
I have below in server xml,
Host name="Myapp.com" appBase="path t
Hi,
I am working on a stress tester for my application, however, from within
the stress tester, sometimes it loses the sessionid
An overview of the process is
1. login to application and get sessionid
2. send subsequent requests to server that sessionid
3. Repeat steps 1 and 2 for multiple users
Hello,
If I deploy my servlet statically, it runs fine. When I deploy dynamically, I
get what looks like a classpath error.
The dependency for this class "org.bouncycastle.jce.X509Principal" is located
within the .war file at "WEB-INF/lib/bcprov-jdk15on-1.50.jar", and other
libraries such as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
On 9/10/2014 4:48 PM, Christopher Schultz wrote:
> Mark,
>
> On 9/10/14 6:45 PM, Mark Eggers wrote:
>> Responses inline.
>
>> On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
>>> I am pretty sure I tried option 3 and Log4j initialization did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 9/10/14 6:45 PM, Mark Eggers wrote:
> Responses inline.
>
> On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
>> I am pretty sure I tried option 3 and Log4j initialization did
>> ignore my log4jConfigLocation setting in conf/.../myapp.xml.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Responses inline.
On 9/10/2014 1:33 PM, sbre...@hotmail.com wrote:
> I am pretty sure I tried option 3 and Log4j initialization did
> ignore my log4jConfigLocation setting in conf/.../myapp.xml.
Oh heck, I think I see what you're trying to do. And th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Wim,
On 9/10/14 9:36 AM, Wim Bertels wrote:
> as i tested setup debian + tomcat7 following the documentation, i
> was refered to
> http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html
>
>
for enabling the security manager,
> as it s
I am pretty sure I tried option 3 and Log4j initialization did ignore my
log4jConfigLocation setting in conf/.../myapp.xml.
What I tried to see in the debug log is the list of context parameters picked
up at start time. Despite log level was set to FINEST nothing show up in any of
the Tomcat lo
2014-09-10 21:52 GMT+04:00 :
>
> (...)
>
> What puzzles me is the Context / Parameter feature of Tomcat. (context-param
> from Java is clear.) There are at least 3 locations to define Tomcat level
> parameters:
>
> - server.xml / Host (1)
> - webapps / ... / context.xml (2)
> - conf/.../myapp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Daniel,
On 9/10/14 3:40 PM, Daniel Pfeiffer wrote:
> Since switching from Apache 2.2 authorization gets bypassed for
> many JkMounts (except jk-status). If I cancel the browser password
> popup, I get a 401-page. It is not, as I expect, the one from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/10/2014 12:52 PM, André Warnier wrote:
> Daniel Pfeiffer wrote:
>> Since switching from Apache 2.2 authorization gets bypassed for
>> many JkMounts (except jk-status). If I cancel the browser
>> password popup, I get a 401-page. It is not, as I ex
Daniel Pfeiffer wrote:
Since switching from Apache 2.2 authorization gets bypassed for many
JkMounts (except jk-status). If I cancel the browser password popup, I
get a 401-page. It is not, as I expect, the one from Apache, but instead
from JBoss, which it shouldn't have been allowed to talk to
Since switching from Apache 2.2 authorization gets bypassed for many JkMounts
(except jk-status). If I cancel the browser password popup, I get a 401-page.
It is not, as I expect, the one from Apache, but instead from JBoss, which it
shouldn't have been allowed to talk to. (I found this because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Comments inline.
Conventions for this list are to post replies at the end or inline. It
makes reading the thread easier.
On 9/10/2014 10:52 AM, sbre...@hotmail.com wrote:
> Thanks, I am afraid I read a similar solution earlier which I did
> not favo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/10/2014 11:55 AM, Mark Eggers wrote:
> Context ctx = new InitialContext(); Integer maxExemptions =
> ctx.lookup("java:comp/env/maxExemptions");
>
> Try / catch and other issues are left as exercises for the reader.
Urp, at least get the casting
-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
>>> dep
On 10/09/2014 16:10, Jeffrey Janner wrote:
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Wednesday, September 10, 2014 9:00 AM
>> To: Tomcat Users List
>> Cc: Tomcat Developers List; annou...@apache.org;
>> annou...@tomcat.apache.org; fulldisclos...@seclists.
Thanks, I am afraid I read a similar solution earlier which I did not favour
for multiple reasons:
- it is a run-time configuration question (handled by DevOps, Ops) to have
various logging levels for various deployed applications on the same Tomcat
- we would like to have full control of loggin
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 pr
-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, DE
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:
webapp
On 9/10/2014 11:10 AM, Jeffrey Janner wrote:
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, September 10, 2014 9:00 AM
To: Tomcat Users List
Cc: Tomcat Developers List; annou...@apache.org;
annou...@tomcat.apache.org; fulldisclos...@seclists.org;
bugt...@s
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, September 10, 2014 9:00 AM
> To: Tomcat Users List
> Cc: Tomcat Developers List; annou...@apache.org;
> annou...@tomcat.apache.org; fulldisclos...@seclists.org;
> bugt...@securityfocus.com
> Subject: [SECU
Wim Bertels wrote:
Hallo,
as i tested setup debian + tomcat7
there are many versions of Tomcat 7.x. Which version precisely ?
(There is a "version.sh" script somewhere, which will tell you)
following the documentation,
i was refered to
http://tomcat.apache.org/tomcat-7.0-doc/security-manag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
CVE-2013- Remote Code Execution
Severity: Important
Vendor: The Apache Software Foundation
Versions Affected:
- - Apache Tomcat 7.0.0 to 7.0.39
Description:
In very limited circumstances, it was possible for an attacker to upload
a malicious JS
Hallo,
as i tested setup debian + tomcat7 following the documentation,
i was refered to
http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html
for enabling the security manager,
as it seems in debian stable (with tomcat + examples + admin debian
packages installed):
- enabling the sec
27 matches
Mail list logo
