RE: Watchdogs (was RE: Use of java.io.File)

[Mark Womack <mw...@bevocal.com>]

Keith,

I have proposed an update/extension to the watchdog mechanism.  Below is a
reference to the latest message.  I have not spent any time recently trying
to get my proposed code compiling under the current cvs, but I can if you
need it.  I would really appreciate your feedback regarding this proposal.

As it stands right now, both PropertyConfigurator and DOMConfigurator
require files for the watchdog version they support internally
(FileWatchdog).  PropertyConfigurator does not support InputStream as a
configuration source (something that can be easily fixed (see my message),
and I have discussed with Ceki about adding the method to the Configurator
interface, but I haven't convinced him yet).

My proposal extends the concept and usage of watchdogs so that they can be
used as stand alone entities, no longer tied to a specific method on a
configurator.  Also, many different sources of configuration data can be
supported: file, web url, and socket are the examples I created as part of
the proposal, but one could write a new watchdog for just about anything,
like jms or a database.

http://marc.theaimsgroup.com/?l=log4j-dev&m=101219985524532&w=2

If you search the archive, you will find other related messages that have
some discussion back and forth about the InputStream issue as well.

thanks, and hope to hear back from you,
-Mark

-----Original Message-----
From: keithnielsen@discoverfinancial.com
[mailto:keithnielsen@discoverfinancial.com]
Sent: Friday, March 01, 2002 6:10 AM
To: log4j-dev@jakarta.apache.org
Subject: RE: Use of java.io.File



Thanks for the response Harald.

Problem is not with getting PropertyConfigure compliant but rather
PropertyWatchDog class which attempts to use File class . I guess I will
for go the PropertyWatchdog and stick with the simple PropertyConfigurator

Keith Nielsen




 

                    Harald Ommang

                    <harald.ommang@del        To:
"'log4j-dev@jakarta.apache.org'" <lo...@jakarta.apache.org>   
                    fidata.no>                cc:
"'keithnielsen@discoverfinancial.com'"                            
 
<ke...@discoverfinancial.com>                                      
                    03/01/2002 12:02          Subject:     RE: Use of
java.io.File                                      
                    AM

 

 





Hello!

You can do something like this:

           url = getClass().getClassLoader().getResource
( "/log4jconfig.xml" );
           DOMConfigurator.configure( url );

or

           url = getClass().getClassLoader().getResource
( "/log4jconfig.conf"
);
           PropertyConfigurator.configure( url );


Harald

-----Original Message-----
From: keithnielsen@discoverfinancial.com
[mailto:keithnielsen@discoverfinancial.com]
Sent: 28. februar 2002 20:58
To: log4j-dev@jakarta.apache.org
Subject: Use of java.io.File


I am trying to use log4j within my application which among other things
consists of Session Beans.

Reading the EJB spec (1.1) states that

"Most servers do not allow direct interaction between an application
program and a keyboard/display
attached to the server system.
     An enterprise bean must not use the java.io package to attempt to
   access files and directories
     in the file system."

The PropertyWatchDog attempts to open a file to the specified configuration
file with File aFile = new File(configFile);

It seems to me that this is in violation of the spec????

Also it seems that the configFileName must be fully qualified, which is a
hassle when switching platforms. What I would like it to do is to take be
implemented like this:

InputStream istream = getClass().getResourceAsStream("/log4j.conf");

That way the file jsut has to be in the classpath and I don't have to worry
about full paths.

I just joined this list so I apologize if this is a repeat.

Any help is appreciated!

Thanks.

Keith Nielsen




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

This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
For more information, connect to http://www.F-Secure.com/





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

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