You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jeff Drew <je...@gmail.com> on 2006/02/20 23:32:55 UTC
reusability and applet dilemma
I'm converting my desktop application to an applet. Due to browser
security, I can't read or write local files so I can neither use .properties
nor write logs. My dilemma is rooted in reusable classes. My desktop
application(now applet) uses some classes, such as a timeStamp class, that
are also used in my server. I'd prefer to retain that class's logging
capability when it is running in the server, but disable the logging when
running in the applet.
I see 3 alternatives:
1. move the logger instantiation to the constructor, then pass the
constructor a newly created boolean indicating whether it's running as an
applet.
2. subclass Logger, then have the subclass check some global boolean
indicating whether it's running as an applet
3. remove logging from the reused classes altogether
I don't like any of these alternatives and wondered if there is another,
more appealing alternative. Here's a simple example that illustrates my
problem.
Thanks
Jeff
public class TimeStamp implements Serializable {
// the following line will cause a security exception
static Logger cat =
Logger.getLogger( "TimeStamp" );
public TimeStamp( long milliSeconds ) {
}
}
Re: reusability and applet dilemma
Posted by Jeff Drew <je...@gmail.com>.
Thanks for the replies. I'm not understanding Ceki's suggestion so I wrote
the attached applet to illustrate my misunderstanding.
here's the code:
public class AppletLogTest extends javax.swing.JApplet {
public void init() {
Logger root = Logger.getRootLogger();
root.setLevel(Level.OFF);
TestClass testClass= new TestClass();
getContentPane( ).add( new JLabel( "hello log4j mailing list!" ) );
}
class TestClass {
Logger cat = Logger.getLogger( "TestClass" );
}
}
When I run it, appletviewer writes this access denied error for the first
access to getRootLogger():
java.lang.ExceptionInInitializerError
at org.apache.log4j.Logger.getRootLogger(Logger.java:104)
at AppletLogTest.init(AppletLogTest.java:22)
at sun.applet.AppletPanel.run(AppletPanel.java:374)
at java.lang.Thread.run()V(Unknown Source)
Caused by: java.security.AccessControlException: access denied (
java.lang.Runtim
ePermission getClassLoader)
at java.security.AccessControlContext.checkPermission
(AccessControlConte
xt.java:264)
at java.security.AccessController.checkPermission(
AccessController.java:
427)
at java.lang.SecurityManager.checkPermission(
Ljava.security.Permission;)
V(Unknown Source)
at java.lang.ClassLoader.getSystemClassLoader
()Ljava.lang.ClassLoader;(U
nknown Source)
at java.lang.ClassLoader.getSystemResource(Ljava.lang.String
;)Ljava.net.
URL;(Unknown Source)
at org.apache.log4j.helpers.Loader.getResource(Loader.java:106)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:94)
... 4 more
It seems any reference to a Logger object creates a security violation.
Signing the applet might solve the problem. But I prefer using basic log4j
techniques if possible.
Thanks again,
Jeff
On 2/21/06, Ceki Gülcü <li...@qos.ch> wrote:
>
>
> Jeff,
>
> Have you considered using the basic techniques already offered by the
> log4j
> framework? For instance, you could configure log4j differently when
> running
> as an applet.
>
> In the init() method of your appplet, you could write:
>
> Logger timestampLogger = Logger.getLogger("TimeStamp");
> timestampLogger.setLevel(Level.OFF);
>
> You could even disable logging altogether
>
> Logger root = Logger.getRootLogger();
> root.setLevel(Level.OFF);
>
> I hope this helps,
>
> At 11:32 PM 2/20/2006, Jeff Drew wrote:
> >I'm converting my desktop application to an applet. Due to browser
> >security, I can't read or write local files so I can neither use
> .properties
> >nor write logs. My dilemma is rooted in reusable classes. My desktop
> >application(now applet) uses some classes, such as a timeStamp class,
> that
> >are also used in my server. I'd prefer to retain that class's logging
> >capability when it is running in the server, but disable the logging when
> >running in the applet.
> >
> >I see 3 alternatives:
> >1. move the logger instantiation to the constructor, then pass the
> >constructor a newly created boolean indicating whether it's running as an
> >applet.
> >2. subclass Logger, then have the subclass check some global boolean
> >indicating whether it's running as an applet
> >3. remove logging from the reused classes altogether
> >
> >I don't like any of these alternatives and wondered if there is another,
> >more appealing alternative. Here's a simple example that illustrates my
> >problem.
> >
> >Thanks
> >
> >Jeff
> >
> >public class TimeStamp implements Serializable {
> >
> >// the following line will cause a security exception
> > static Logger cat =
> >Logger.getLogger( "TimeStamp" );
> >
> > public TimeStamp( long milliSeconds ) {
> >
> > }
> >}
>
> --
> Ceki Gülcü
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: reusability and applet dilemma
Posted by Ceki Gülcü <li...@qos.ch>.
Jeff,
Have you considered using the basic techniques already offered by the log4j
framework? For instance, you could configure log4j differently when running
as an applet.
In the init() method of your appplet, you could write:
Logger timestampLogger = Logger.getLogger("TimeStamp");
timestampLogger.setLevel(Level.OFF);
You could even disable logging altogether
Logger root = Logger.getRootLogger();
root.setLevel(Level.OFF);
I hope this helps,
At 11:32 PM 2/20/2006, Jeff Drew wrote:
>I'm converting my desktop application to an applet. Due to browser
>security, I can't read or write local files so I can neither use .properties
>nor write logs. My dilemma is rooted in reusable classes. My desktop
>application(now applet) uses some classes, such as a timeStamp class, that
>are also used in my server. I'd prefer to retain that class's logging
>capability when it is running in the server, but disable the logging when
>running in the applet.
>
>I see 3 alternatives:
>1. move the logger instantiation to the constructor, then pass the
>constructor a newly created boolean indicating whether it's running as an
>applet.
>2. subclass Logger, then have the subclass check some global boolean
>indicating whether it's running as an applet
>3. remove logging from the reused classes altogether
>
>I don't like any of these alternatives and wondered if there is another,
>more appealing alternative. Here's a simple example that illustrates my
>problem.
>
>Thanks
>
>Jeff
>
>public class TimeStamp implements Serializable {
>
>// the following line will cause a security exception
> static Logger cat =
>Logger.getLogger( "TimeStamp" );
>
> public TimeStamp( long milliSeconds ) {
>
> }
>}
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org