RE: Cactus 1.3 and Log4j

[Vincent Massol <vm...@octo.com>]

Florent,

Have you seen the email I posted about 2 weeks ago WRT log4j ? Here is
what it was saying (in case you haven't seen it) :

"
Some of you have had problems with Cactus 1.2 (and even some builds of
Cactus 1.3) and Log4j. When you were using Log4j 1.1.3, you were saying
CNF exceptions for Logger or Level ...

We now know the cause of this error. I was compiling Cactus on my
machine with log4j 1.2alphaX, and there was a bug in that version of
log4j. Here's a statement published by Ceki from the Log4j team :

"
There will be also unexpected interactions between log4j and the
commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a
very subtle bug which caused client code compiled with log4j version
1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely, code
compiled with 1.2alpha would crash when ran using log4j 1.1.3. This
problem was fixed in log4j beta. "

Log4j 1.2alphaX is now history and all nightly builds (broken for the
moment but will be restored in 1 or 2 days) and releases will work fine
with log4j 1.1.3 and log4j 1.2.

Thank you.
-Vincent
"

Hope it helps.
Thanks
-Vincent

> -----Original Message-----
> From: Florent Nisseron [mailto:florent.nisseron@softeam.fr]
> Sent: 18 March 2002 08:03
> To: Cactus Users List
> Subject: Re: Cactus 1.3 and Log4j
> 
> 
> 
> Vincent Massol wrote:
> 
> >Florent,
> >
> >>-----Original Message-----
> >>From: Florent Nisseron [mailto:florent.nisseron@softeam.fr]
> >>Sent: 26 February 2002 08:09
> >>To: cactus-user@jakarta.apache.org
> >>Subject: Cactus 1.3 and Log4j
> >>
> >>   Hi,
> >>
> >>Like few days ago, I have problem with cactus 1.3 when I want to use
> >>
> >it
> >
> >>with Log4j.
> >>JUnit throws the following errors for a test which works well
without
> >>Log4j
> >>
> >><<<<<<<<<<<<<<<<<
> >>java.security.AccessControlException: access denied
> >>(java.lang.RuntimePermission getClassLoader)
> >>    at
>
java.security.AccessControlContext.checkPermission(AccessControlContext.
> >>java:272)
> >>    at
>
java.security.AccessController.checkPermission(AccessController.java:399
)
> >>
> >>    at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
> >>
> >>    at java.lang.ClassLoader.getParent(ClassLoader.java:692)
> >>    at
>
org.apache.cactus.server.AbstractTestCaller.getTestClassInstance(Abstrac
tT
> estCaller.java:290)
> >><<<<<<<<<<<<<<<<<
> >>
> >>As you see, the error is thrown from
> >>AbstractTestCaller.getTestClassInstance method in a part of code
which
> >>is only use in debug mode
> >>( included in a block like this :
> >><<<<<<<<<<<<<<if(logger.isDebugEnabled()) <<<<<<<<<<< )
> >>The call to ClassLoader.getParent throws an AccesControlException.
> >>
> >>The question is why ? Must I add something into my java.security or
> >>java.policy ? Why ?
> >>
> >
> >I would say yes ! The container under which you're running is
probably
> >using a security manager that protects something. This part of the
code
> >retrieves the parent classloaders of the current class. Thus, I
believe
> >it is either the call to classLoader.getParent() or the
getClassLoader()
> >one that must be causing this security exception.
> >
> >Which container are you using ? (I have never seen this exception in
any
> >of the containers I have used Cactus with).
> >
> 
> Well, this errors is thrown by the container provided with the
j2sdkee1.3.
> However i think the same error is raised when i use an other container
> like the IONA ( iPortal )  one.
> 
> >One solution is of course to disable the security check by modifying
> >your policy file.
> >
> The problem is that i try to disable this security check by adding
lines
> into my java.policy using the policytool but even if i have added  :
> 
> <<<<<<<<
> grant {
>   permission java.security.AllPermission;
> }
> <<<<<<<<<<< OR
> grant {
>   permission java.security.AllPermission;
>   permission java.lang.RuntimePermission "getClassLoader";
>   permission java.io.FilePermission "<<ALL FILES>>", "read, write,
> delete, execute";
> };
> <<<<<<<<<<<<
> 
> The problem still remains the same .... and i have try many
combinaison
> ( but not the good one )
> I must admit that i am not a guru in security file and I don't see
what
> to add more.
> I use the same jdk ( and the same policy file in
%JDK_PATH%\lib\security
> ) for client and server side
> 
> 
> Florent
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>