Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Message-Id: <6.0.3.0.0.20040615113326.0357b1b8@mail.qos.ch>
Date: Tue, 15 Jun 2004 13:47:15 +0200
To: "Log4J Developers List" <log4j-dev@logging.apache.org>
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: Re: JMSReceiver/ClassLoaders/Success+Dilema
In-Reply-To: <20040614203234.N99464@minotaur.apache.org>
References: <20040614203234.N99464@minotaur.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


Paul,

Please keep in mind that log4j can be placed quite high in the classloader=
=20
chain. Consider this as a side remark.

At 05:53 AM 6/15/2004, you wrote:
>Well, I have actually managed to work out how to get Chainsaw to work with=
=20
>the JMSReceiver and inside Web start.
>
>There is a couple of problems however.  To summarise, the ClassLoader that=
=20
>is used to load a class MUST have access to any required dependencies,=20
>either via the Jars/directories that the ClassLoader manages, or it's=20
>_parent_ ClassLoader.
>
>I am able to create a ClassLoader that loads classes from a local plugins=
=20
>directory, and can delegate to the Parent classloader as per the spec.=20
>However the JMSReceiver is bundled inside the log4j core jar file, and=20
>that class is loaded by Web start's JNLPClassLoader.  At the time of=20
>loading the JMSReceiver class, the JNLPClassLoader does have access to=20
>JMSReceiver class, but can't locate the other jms libraries, which are=20
>available via the _CHILD_ classLoader (this new PluginClassLoader).

The important questions to ask is why are the dependent JMS classes not=20
available? In my opinion, it is a consequence of the web-start deployment=20
scenario. How representative is the web-start deployment scenario? Not very=
=20
representative if you ask me.

>So the dilema is that realistically for this to work, the JMSReceiver=20
>class needs to be loaded by the PluginClassLoader.  This means that we=20
>would need to remove the JMSReceiver from the core jar only for web start=
=20
>purposes, and have the user drop it into their local plugin directory=20
>(lets call this log4jJMSReceiver.jar), along with say, weblogic.jar, or=20
>whatever JMS specific impl is required. The classes and it's dependancies=
=20
>need to be available from the same ClassLoader level or higher.

I am quite worried about log4j starting to have its own
classloader. Unless there is a compelling reason, I'd be much happier
without PluginClassLoaderFactory. You just don't start spawning your
own classloaders. It's usually very bad practice.

How does placing log4jJMSReceiver.jar in a local plugin directory help?

In order to answer this question, I had a peek at the recent
changes. In o.a.l.chainsaw.LogUI class these lines were added.

     ClassLoader classLoader =3D PluginClassLoaderFactory.create(new=20
File(SettingsManager.getInstance().getSettingsDirectory() + File.separator=
=20
+ "plugins"));
     Thread.currentThread().setContextClassLoader(classLoader);

Log4j should not set the thread context class loader as this is an
important prerogative of J2EE containers. Actually, this line will cause
havoc when used within a container. For once, it will immediately
break JNDI. (The TCL was invented to allow JNDI context variables.) It
will actually break log4j itself which uses JNDI variables.

Please don't bring the whole structure down in order to cater for this
marginal deployment scenario. If an elegant solution cannot be
provided, than it is better to recognize this fact and then to move
on. In this case, the wisest thing to do may be to declare that
JMSReceiver does not work with web-start.

>Secondly, to be able to actually use these loaded classes requires the=20
>following line in LogUI's startup method:
>
>System.setSecurityManager(null);
>
>This basically turns off security checking for most things, and is allowed=
=20
>because Chainsaw is marked with the "all Permissions" permission.  If this=
=20
>line is not added, then when a class inside one of these Plugin jars tries=
=20
>to, say, read a System property, you get something like:
>
>Caused by: java.security.AccessControlException: access denied=20
>(java.util.PropertyPermission weblogic.xml.debug read)
>
>Removing the SecurityManager seems a bit harsh, and I propose that we only=
=20
>do this with the User's permission via a AppliciationPreference so they=20
>can explicitly decide this.  The classes loaded via the PluginClassLoader=
=20
>then effectively become trusted.
>
>Given these ClassLoader issues, I wonder whether it is worth NOT=20
>distributing the JMSReceiver class inside the log4j core jar, as users=20
>could run into the same problems.


>I would appreciate if anyone has any comments on this.

Unless, it was not clear from the above, my comment can be summarized as a=
=20
big fat -1. :-)

>regards,
>
>Paul Smith

--=20
Ceki G=FClc=FC

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp =20


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org