Re: Using log4j to log XML-files?

2003-11-18 Thread Thorbjørn Ravn Andersen
Thorbjørn Ravn Andersen wrote:

I have a scenario where I would like to use log4j to save intermediate 
XML-files for later debugging.  We are using log4j 1.2.7, and it is 
cumbersome to upgrade.

I therefore need a configuration that saves exactly one log entry per 
log file, and names it with some unique name.I tried 
DailyRollingFileAppender which - with S in the DatePattern - in theory 
should give me a uniquely named file per entry, but where the program 
logic apparently is not prepared for millisecond resolution.  
RollingFileAppender is less attractive as it renames  and deletes 
files and does not allow a timestamp in the name.
I have a feeling I may be using a wrong approach. for this.  Any 
suggestions?

After hitting send, I realised  I forgot to describe what happens.  Both 
appenders log several entries in the same file, without rolling over.  
DailyROllingFileAppender with S in the pattern, and RolingFileAppender 
with a filesize of 1 and ImmediateFlush on.   So my problem is to get 
log4j to check for rollover _every_time, and actually do it :)

Sorry for the multiple posting.

--
 Thorbjoern Ravn Andersen  "...plus...Tubular Bells!"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: using log4j socketserver for non-Java applications?

2002-12-11 Thread Ceki Gülcü

Not to my knowledge. However, I would be very interested in a 
cross-language appender/receiver pair.

At 16:12 11.12.2002 +0100, Garhoefer Andreas wrote:
hi!

I would like to use the log4j SocketServer for C++ apps (using log4cpp).
As far as I can see, the SocketAppender sends (serialized) objects over the
net
which are java-specific. So using log4cpp from a C++ application means that
I have
to write an appender which is able to creates serialized objects. Has
anybody done
that already ?

regards
andreas garhoefer


--
Ceki



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4J with JBoss and Cactus

2002-07-25 Thread Paul Ekeland

I had already enabled the internal logging of JBoss, with no success
unfortunately. This "log4j:WARN No appenders could be found for logger
com.credm.babel.cactus.TestPropertyType" is output on the console screen of
Ant when I try running the program.

And in the class com.credm.babel.cactus.TestPropertyType, here is how I
declare the logger:

"public class TestPropertyType extends ServletTestCase
{
private PropertyTypeLocal propertyType;
final static Logger logger = Logger.getLogger("org.apache.cactus");
...
}"

Nothing much to do with the error... And to add to that, I did declare a
"com.credm.babel.cactus" logger in my log4j.xml file of JBoss! This is
pretty confusing. The war file used with Cactus does not seem to see the
log4j configuration for JBoss. Would that be possible?

One last thing that would ease the development: is it possible to merge
log_client.properties and log_server.properties in the log4j.xml?

Thanks!

Paul

-Message d'origine-
De : Ceki Gulcu [mailto:[EMAIL PROTECTED]]
Envoye : jeudi 25 juillet 2002 16:39
A : Log4J Users List
Objet : RE: using log4J with JBoss and Cactus




The fact that log4j warns about not seeing the root logger is normal
because the log_server.properties file probably does not mention the
root logger (which is perfectly fine.) Log4j is suspicious about not
seeing the root logger mentioned in the config file and emits a
warning which you can safely ignore.

The "log4j:WARN No appenders could be found for logger
com.credm.babel.cactus.TestPropertyType" is more serious. You should
enable internal log4j debugging for the JBoss' log4j.xml file and see
what that gives.

At 16:12 25.07.2002 +0200, you wrote:
>Hello Ceki,
>
>Thanks for answering.
>So far, I have solved one of the problem: now my appenders do produce
files.
>In the log4j.xml of JBoss, my error was to make them derive from the
>"org.apache.log4j.FileAppender". The correct way is to make them derive
from
>JBoss' class.:
>  class="org.jboss.logging.appender.FileAppender">
>
>Now, the problem with merging the contents of "log_client.properties" into
>"log4j.xml" is that cactus.jar is looking for a "log_client.properties" in
>the classpath. Same effect with "log_server.properties"... Is there a way
to
>bypass this?
>
>JBoss manages to start correctly its Log4J service, as you can see:

[snip]


--
Ceki

For complete log4j documentation please refer to
http://qos.ch/log4jBook.html


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: using log4J with JBoss and Cactus

2002-07-25 Thread Ceki Gülcü



The fact that log4j warns about not seeing the root logger is normal
because the log_server.properties file probably does not mention the
root logger (which is perfectly fine.) Log4j is suspicious about not
seeing the root logger mentioned in the config file and emits a
warning which you can safely ignore.

The "log4j:WARN No appenders could be found for logger
com.credm.babel.cactus.TestPropertyType" is more serious. You should
enable internal log4j debugging for the JBoss' log4j.xml file and see
what that gives.

At 16:12 25.07.2002 +0200, you wrote:
>Hello Ceki,
>
>Thanks for answering.
>So far, I have solved one of the problem: now my appenders do produce files.
>In the log4j.xml of JBoss, my error was to make them derive from the
>"org.apache.log4j.FileAppender". The correct way is to make them derive from
>JBoss' class.:
>  class="org.jboss.logging.appender.FileAppender">
>
>Now, the problem with merging the contents of "log_client.properties" into
>"log4j.xml" is that cactus.jar is looking for a "log_client.properties" in
>the classpath. Same effect with "log_server.properties"... Is there a way to
>bypass this?
>
>JBoss manages to start correctly its Log4J service, as you can see:

[snip]


--
Ceki

For complete log4j documentation please refer to http://qos.ch/log4jBook.html


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4J with JBoss and Cactus

2002-07-25 Thread Paul Ekeland

Hello Ceki,

Thanks for answering.
So far, I have solved one of the problem: now my appenders do produce files.
In the log4j.xml of JBoss, my error was to make them derive from the
"org.apache.log4j.FileAppender". The correct way is to make them derive from
JBoss' class.:


Now, the problem with merging the contents of "log_client.properties" into
"log4j.xml" is that cactus.jar is looking for a "log_client.properties" in
the classpath. Same effect with "log_server.properties"... Is there a way to
bypass this?

JBoss manages to start correctly its Log4J service, as you can see:

"2002-07-25 13:05:34,149 DEBUG [org.jboss.logging.Log4jService] Installed
System.out adapter
2002-07-25 13:05:34,149 DEBUG [org.jboss.logging.Log4jService] Installed
System.err adapter
2002-07-25 13:05:34,159 DEBUG [org.jboss.logging.Log4jService] Added
ThrowableListener:
org.jboss.logging.Log4jService$ThrowableListenerLoggingAdapter@f0c85e
2002-07-25 13:05:34,159 INFO  [org.jboss.logging.Log4jService] Started"

and even to parse correctly the log_server.properties:

"2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Reading configuration from
URL
file:D:/applications/jboss-3.0.0_tomcat-4.0.3/catalina/work/localhost/babelt
est/WEB-INF/classes/log_server.properties
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Could not find root logger
information. Is this OK?
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Parsing for
[org.apache.cactus] with value=[INFO, cactus].
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Level token is [INFO].
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Category org.apache.cactus set
to INFO
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Parsing appender named
"cactus".
2002-07-25 15:15:50,058 INFO  [STDOUT] log4j: Parsing layout options for
"cactus".
2002-07-25 15:15:50,439 INFO  [STDOUT] log4j: Setting property
[conversionPattern] to [%d{ABSOLUTE} [%t] %-5p %-30.30c{2} %x - %m %n].
2002-07-25 15:15:50,439 INFO  [STDOUT] log4j: End of parsing for "cactus".
2002-07-25 15:15:50,899 INFO  [STDOUT] log4j: Setting property [append] to
[false].
2002-07-25 15:15:50,899 INFO  [STDOUT] log4j: Setting property [file] to
[D:/applications/jboss-3.0.0_tomcat-4.0.3/server/default/log/cactus_server.l
og].
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: setFile called:
D:/applications/jboss-3.0.0_tomcat-4.0.3/server/default/log/cactus_server.lo
g, false
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: setFile ended
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: Parsed "cactus" options.
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: Handling
log4j.additivity.org.apache.cactus=[false]
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: Setting additivity for
"org.apache.cactus" to false
2002-07-25 15:15:50,909 INFO  [STDOUT] log4j: Finished configuring."

The problem is that it cannot see the root logger!!
Furthermore, I still have the following error when I start my program:

" Standard Error -
 log4j:WARN No appenders could be found for logger
com.credm.babel.cactus.TestPropertyType).
 log4j:WARN Please initialize the log4j system properly.
-  ---"

I hope someone knows what is going on... Any help is appreciated! Thanks!

Paul

-Message d'origine-
De : Ceki Gulcu [mailto:[EMAIL PROTECTED]]
Envoye : mercredi 24 juillet 2002 18:41
A : Log4J Users List
Objet : Re: using log4J with JBoss and Cactus



Paul,

What does log4j say when it reads log4j.xml? Second, you can merge the
contents of log_client.properties into log4j.xml. Do you know if
log_client.properties parsed at all?

At 17:44 24.07.2002 +0200, Paul Ekeland wrote:
>Hello everyone,
>
>I am currently writing a program to test my EJBs using Cactus. I created a
>war file of the cactus tests and they run on a JBoss 3.0 platform. JBoss,
>Cactus and my program are all using log4J... Here is how it is written so
>far: I followed your recommandations and so I adapted the log4j.xml of
JBoss
>and inserted my own appenders and loggers as shown in appendix.
>
>Now, Cactus also is using log4J and needs 2 configuration files,
>log_client.properties and log_server.properties . log_client.properties is
>described in the appendix too.
>
>With this setup, here is what i get:
>
> * 2 empty logfiles cactus_client.log and cactus_server.log even
> though the
>code requires some  events to be written in them. At least, it seems it
>reads correctly the configuration files from Cactus.
>
> * an appender error that should not have happened if the
> appenders i had
>put in the  configuration file of JBoss, log4J.xml, had been taken in
>account:
> " Standard Error -
> log4j:WARN No appenders could be found for logger
&

Re: using log4J with JBoss and Cactus

2002-07-24 Thread Ceki Gülcü


Paul,

What does log4j say when it reads log4j.xml? Second, you can merge the
contents of log_client.properties into log4j.xml. Do you know if
log_client.properties parsed at all?

At 17:44 24.07.2002 +0200, Paul Ekeland wrote:
>Hello everyone,
>
>I am currently writing a program to test my EJBs using Cactus. I created a
>war file of the cactus tests and they run on a JBoss 3.0 platform. JBoss,
>Cactus and my program are all using log4J... Here is how it is written so
>far: I followed your recommandations and so I adapted the log4j.xml of JBoss
>and inserted my own appenders and loggers as shown in appendix.
>
>Now, Cactus also is using log4J and needs 2 configuration files,
>log_client.properties and log_server.properties . log_client.properties is
>described in the appendix too.
>
>With this setup, here is what i get:
>
> * 2 empty logfiles cactus_client.log and cactus_server.log even 
> though the
>code requires some  events to be written in them. At least, it seems it
>reads correctly the configuration files from Cactus.
>
> * an appender error that should not have happened if the 
> appenders i had
>put in the  configuration file of JBoss, log4J.xml, had been taken in
>account:
> " Standard Error -
> log4j:WARN No appenders could be found for logger
>(com.credm.babel.cactus.TestPropertyType).
> log4j:WARN Please initialize the log4j system properly.
> -  ---"
>
> * No files are created for the CACTUSTEST appender..

[snip]

--

Ceki

For complete log4j documentation please refer to http://qos.ch/log4jBook.html


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4j in jsp

2002-07-08 Thread Mark Womack

Denis,

I make up logger names for the jsp pages, since you cannot predict what the
jsp java name will be (and you probably don't want to use it anyway since it
is so long).

Also, I use a mix of tags and direct java classes and use which ever one is
appropriate for the place I am logging a message.

hope it helps,
-Mark

> -Original Message-
> From: Denis McCarthy [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 04, 2002 8:55 AM
> To: Log4J Users List
> Subject: using log4j in jsp
> 
> 
> Hi,
> I'm using log4j as my logger in a web application. This is 
> all well and good
> for my back end (control  ,business and data access tiers) 
> but I'm stumped
> about what the best approach is to using log4j in my front 
> end (jsp pages).
> Has anyone out there used log4j in jsp pages, and if so what if any
> strategies have they implemented to deal with things like logger
> inheritance?
> Thanks
> Denis
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: using log4j in jsp

2002-07-07 Thread goetz

I'm interested, too. You might also think about putting it into the Sourceforge 
Snippet library.

Regards
-Bernd.

Jochen Hiller wrote:
> Hi Denis,
> 
> I've written a tag library which will be used in our company projects. Also,
> as part of the jakarta-taglibs there is a  tag support. See
> http://jakarta.apache.org
> 
> If I should provide you with the code, let me know.
> 
> Bye, Jochen
> 
> -Original Message-
> From: Denis McCarthy [mailto:[EMAIL PROTECTED]]
> Sent: Donnerstag, 4. Juli 2002 17:55
> To: Log4J Users List
> Subject: using log4j in jsp
> 
> 
> Hi,
> I'm using log4j as my logger in a web application. This is all well and good
> for my back end (control  ,business and data access tiers) but I'm stumped
> about what the best approach is to using log4j in my front end (jsp pages).
> Has anyone out there used log4j in jsp pages, and if so what if any
> strategies have they implemented to deal with things like logger
> inheritance?
> Thanks
> Denis
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



-- 
Bernd Goetz [EMAIL PROTECTED]
TARSEC AG   Tel +41 1 496 61 11
Rautistrasse 12 Fax +41 1 496 61 99
PostfachMobile +41 79 759 04 26
8047 Zurich, Switzerlandhttp://www.tarsec.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4j in jsp

2002-07-05 Thread Jochen Hiller

Hi Denis,

I've written a tag library which will be used in our company projects. Also,
as part of the jakarta-taglibs there is a  tag support. See
http://jakarta.apache.org

If I should provide you with the code, let me know.

Bye, Jochen

-Original Message-
From: Denis McCarthy [mailto:[EMAIL PROTECTED]]
Sent: Donnerstag, 4. Juli 2002 17:55
To: Log4J Users List
Subject: using log4j in jsp


Hi,
I'm using log4j as my logger in a web application. This is all well and good
for my back end (control  ,business and data access tiers) but I'm stumped
about what the best approach is to using log4j in my front end (jsp pages).
Has anyone out there used log4j in jsp pages, and if so what if any
strategies have they implemented to deal with things like logger
inheritance?
Thanks
Denis


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using Log4J in EJB server

2002-05-30 Thread Cakalic, James

Also consider, albeit poor practice, how much working EJB code you've seen
that uses System.out and/or System.err. Clearly, these are (and must be)
java.io.PrintStream instances. Furthermore, all implementations I've seen of
PrintStream are internally synchronized to prevent output from multiple
callers becoming commingled. IBM's WebSphere Best Practices document even
cites this synchronization (and the resultant performance decrease) as a
reason for avoiding the use of System.out. However, their balanced (italics
mine :-) view is to "Avoid indiscriminate System.out.println statements". 

The EJB spec section (23.1.2 in the EJB 2.0 Spec) states that the intent of
the specification is to describe "the programming restrictions that a Bean
Provider must follow to ensure that the enterprise bean is portable and can
be deployed in any compliant EJB 2.0 Container." Thus, primarily portability
-- not functional or operational concerns -- would seem to be at the heart
of these restrictions. Restrictions which extend to the dependent classes
used by an entity bean with CMP.

The specific restriction on java.io is "An enterprise bean must not use the
java.io package to attempt to access files and directories in the file
system." The important bit for designers is the why: "The file system APIs
are not well-suited for business components to access data. Business
components should use a resource manager API, such as JDBC, to store data."
File system characteristics vary widely between deployment environments and
so effect the portability of a dependent application. File systems are not
transactional so "data" stored to a file system cannot carry transactional
guarantees. But are logs "data"? I mean, in the same way that user
registration information is "data"? Or that your product catalog is "data"?
Or that orders sent to a back-end fulfillment system are "data"? If you
think yes, then definitely avoid using files for logs. If you think no, and
portability is not an outstanding concern, then why not?

Consider again thread synchronization. The restriction is: "An enterprise
Bean must not use thread synchronization primitives to synchronize execution
of multiple instances. This rule is required to ensure consistent runtime
semantics because while some EJB Containers may use a single JVM to execute
all enterprise bean's instances, others may distribute the instances across
multiple JVMs. Synchronization would not work if the EJB Container
distributed enterprise bean's instances across multiple JVMs."

So thread synchronization isn't inherently a "bad thing". The reason has to
do with sequencing the activities of bean instances across multiple JVMs.
But that isn't what we are doing here. We want to limit the access to a
particular shared resource within a single JVM. That resource is not
transactional so it presents no deadlock issues. In this case, as in the
case with java.io.PrintStream (aka System.out), there may be performance or
scalability issues to consider (like there aren't with JDBC or JMS?) but not
functional issues -- and I mean the application fails to function correctly
when moved to a new environment.

Certainly, adhering to the spirit of the restrictions set out in the EJB
specification is beneficial and a recommended practice. However, intelligent
application of each restriction requires understanding the intent behind it
and the possible impact of violating it.

Best regards,
Jim Cakalic

> -----Original Message-
> From: Steve Ebersole [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 7:50 PM
> To: Log4J Users List
> Subject: Re: Using Log4J in EJB server
> 
> 
> Not to bemuse this point, but that is just not a complete 
> truth (as is true
> for most generalizations).  I'll give you two prime examples 
> (though there
> are others) where not only is the use of classes from the 
> java.io package
> used extensively in J2EE environments, but in fact validated 
> directly by Sun
> in its tutorials and J2EE patterns:
> 
> 1) A combination of java.io.StringWriter and 
> java.io.PrintWriter as a means
> of maintaining stack trace information in inter-tier Exception classes
> 2) A combination of 
> java.io.ByteArrayOutputStream/java.io.ObjectOutputStream
> and java.io.ByteArrayInputStream/java.io.ObjectInputStream as 
> a quick way to
> perform deep copies of server objects for serialization.
> 
> And lets not even get into java.io.Serializable/Externalizable
> 
> Is it a good idea to perform direct file IO from within a 
> J2EE app at all?
> Generally no.  However, the reason is usually not for the 
> first one you
> mentioned; rather the fact that you would need to know 
> something of the
> file-system layout in order to perform direct 

RE: Using Log4J in EJB server

2002-05-30 Thread Bellamy, Scot

As far as java.io, I was simply repeating what is stated in the spec.
It doesn't prevent bean writers from using the package anyway, but doing
so introduces the risk of performance issues and reduced protability.

Explicit thread synchronization may work if your container provider
hasn't optimized the container in such a way as to use multiple JVM
instances.  If multiple JVM instances are used, you might find
unpredictable behavior when explicitly synchronizing threads.  If it
works ok with the container you are now using, you may be tied to that
vendor, or even a specific version of the container from that vendor.

Scot.

Scot Bellamy
Infrastructure & Architecture
eBusiness Technology
Cardinal Health, Inc.


-Original Message-
From: Steve Ebersole [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, May 29, 2002 8:50 PM
To: Log4J Users List
Subject: Re: Using Log4J in EJB server


Not to bemuse this point, but that is just not a complete truth (as is
true for most generalizations).  I'll give you two prime examples
(though there are others) where not only is the use of classes from the
java.io package used extensively in J2EE environments, but in fact
validated directly by Sun in its tutorials and J2EE patterns:

1) A combination of java.io.StringWriter and java.io.PrintWriter as a
means of maintaining stack trace information in inter-tier Exception
classes
2) A combination of
java.io.ByteArrayOutputStream/java.io.ObjectOutputStream
and java.io.ByteArrayInputStream/java.io.ObjectInputStream as a quick
way to perform deep copies of server objects for serialization.

And lets not even get into java.io.Serializable/Externalizable

Is it a good idea to perform direct file IO from within a J2EE app at
all? Generally no.  However, the reason is usually not for the first one
you mentioned; rather the fact that you would need to know something of
the file-system layout in order to perform direct file IO is usually the
greatest concern.  Although for me the new JMX implmentation for log4j
would help alleviate that issue.  And yes of course file IO has the
potential to be a bottle neck (and you think database access won't).

And FYI, the same holds true for thread synchronization.  I use TopLink
within J2EE containers.  And while I haven't seen their source cde, I'd
be more than willing to bet you that they are using thread
synchronization internally?  If so, would that mean that I am violating
the J2EE specs by using TopLink from within my EJBs?



- Original Message -
From: "Bellamy, Scot" <[EMAIL PROTECTED]>
To: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 11:12 AM
Subject: RE: Using Log4J in EJB server


Whether the code is directly in the bean  or is in another class used by
the bean, the problem is the same.  The problem is that there will
likely be multiple instances of the bean instantiated at the same time.
This will cause a threading problem when attempting direct file io.  The
same section of the EJB spec (EJB.18.1.2) that prohibits use of the io
package, also prohibits explicit thread synchronization.

The other problem is that direct file io will be a bottle-neck to your
system, preventing your system from scaling as usage increases.

Scot.

Scot Bellamy
Infrastructure & Architecture
eBusiness Technology
Cardinal Health, Inc.


-Original Message-
From: Steve Ebersole [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 27, 2002 11:31 AM
To: Log4J Users List
Subject: Re: Using Log4J in EJB server


The direct use of the java.io package is forbidden by the EJB spec. That
does not mean that your EJBs cannot use classes/libraries which use the
java.io package.  I use log4j in a J2EE environment with no problems
(although i log to a JMS queue from within the app components).


- Original Message -
From: "Chris Naude" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 10:26 AM
Subject: Using Log4J in EJB server


>
> Hi
>
> I have been looking at the log4j archives regarding the use of log4j
inside an EJB. I am not quite sure what all the discussion is about (as
usage of the java.io package is forbidden in the spec). However, I have
the ff line in each of my EJB's:
>
> private static final Logger L = Logger.getLogger(SomeEJBClass.class);
>
> The EJB server I am using (Borland Enterprise Server V5.0) does not
complain about anything in this regard.
>
> Can someone tell me if there are any hidden problems with this 
> approach -
we have just started our project and I don't want to get any surprises
later on.
>
> Thanks in advance.
>
> Chris
>
>
>
>
>
>
>
> I
>
>
>
> -
> Sign up to watch the FIFA World Cup video highlights from your desk!
>
> http://fifaworldcup.yahoo.com/fc/en


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTE

Re: Using Log4J in EJB server

2002-05-29 Thread Steve Ebersole

Not to bemuse this point, but that is just not a complete truth (as is true
for most generalizations).  I'll give you two prime examples (though there
are others) where not only is the use of classes from the java.io package
used extensively in J2EE environments, but in fact validated directly by Sun
in its tutorials and J2EE patterns:

1) A combination of java.io.StringWriter and java.io.PrintWriter as a means
of maintaining stack trace information in inter-tier Exception classes
2) A combination of java.io.ByteArrayOutputStream/java.io.ObjectOutputStream
and java.io.ByteArrayInputStream/java.io.ObjectInputStream as a quick way to
perform deep copies of server objects for serialization.

And lets not even get into java.io.Serializable/Externalizable

Is it a good idea to perform direct file IO from within a J2EE app at all?
Generally no.  However, the reason is usually not for the first one you
mentioned; rather the fact that you would need to know something of the
file-system layout in order to perform direct file IO is usually the
greatest concern.  Although for me the new JMX implmentation for log4j would
help alleviate that issue.  And yes of course file IO has the potential to
be a bottle neck (and you think database access won't).

And FYI, the same holds true for thread synchronization.  I use TopLink
within J2EE containers.  And while I haven't seen their source cde, I'd be
more than willing to bet you that they are using thread synchronization
internally?  If so, would that mean that I am violating the J2EE specs by
using TopLink from within my EJBs?



- Original Message -
From: "Bellamy, Scot" <[EMAIL PROTECTED]>
To: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 11:12 AM
Subject: RE: Using Log4J in EJB server


Whether the code is directly in the bean  or is in another class used by
the bean, the problem is the same.  The problem is that there will
likely be multiple instances of the bean instantiated at the same time.
This will cause a threading problem when attempting direct file io.  The
same section of the EJB spec (EJB.18.1.2) that prohibits use of the io
package, also prohibits explicit thread synchronization.

The other problem is that direct file io will be a bottle-neck to your
system, preventing your system from scaling as usage increases.

Scot.

Scot Bellamy
Infrastructure & Architecture
eBusiness Technology
Cardinal Health, Inc.


-Original Message-
From: Steve Ebersole [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 27, 2002 11:31 AM
To: Log4J Users List
Subject: Re: Using Log4J in EJB server


The direct use of the java.io package is forbidden by the EJB spec.
That does not mean that your EJBs cannot use classes/libraries which use
the java.io package.  I use log4j in a J2EE environment with no problems
(although i log to a JMS queue from within the app components).


- Original Message -
From: "Chris Naude" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 10:26 AM
Subject: Using Log4J in EJB server


>
> Hi
>
> I have been looking at the log4j archives regarding the use of log4j
inside an EJB. I am not quite sure what all the discussion is about (as
usage of the java.io package is forbidden in the spec). However, I have
the ff line in each of my EJB's:
>
> private static final Logger L = Logger.getLogger(SomeEJBClass.class);
>
> The EJB server I am using (Borland Enterprise Server V5.0) does not
complain about anything in this regard.
>
> Can someone tell me if there are any hidden problems with this
> approach -
we have just started our project and I don't want to get any surprises
later on.
>
> Thanks in advance.
>
> Chris
>
>
>
>
>
>
>
> I
>
>
>
> -
> Sign up to watch the FIFA World Cup video highlights from your desk!
>
> http://fifaworldcup.yahoo.com/fc/en


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>









> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: Using Log4J in EJB server

2002-05-29 Thread Bellamy, Scot

Whether the code is directly in the bean  or is in another class used by
the bean, the problem is the same.  The problem is that there will
likely be multiple instances of the bean instantiated at the same time.
This will cause a threading problem when attempting direct file io.  The
same section of the EJB spec (EJB.18.1.2) that prohibits use of the io
package, also prohibits explicit thread synchronization. 

The other problem is that direct file io will be a bottle-neck to your
system, preventing your system from scaling as usage increases.

Scot.

Scot Bellamy
Infrastructure & Architecture
eBusiness Technology
Cardinal Health, Inc.


-Original Message-
From: Steve Ebersole [mailto:[EMAIL PROTECTED]] 
Sent: Monday, May 27, 2002 11:31 AM
To: Log4J Users List
Subject: Re: Using Log4J in EJB server


The direct use of the java.io package is forbidden by the EJB spec.
That does not mean that your EJBs cannot use classes/libraries which use
the java.io package.  I use log4j in a J2EE environment with no problems
(although i log to a JMS queue from within the app components).


- Original Message -
From: "Chris Naude" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 10:26 AM
Subject: Using Log4J in EJB server


>
> Hi
>
> I have been looking at the log4j archives regarding the use of log4j
inside an EJB. I am not quite sure what all the discussion is about (as
usage of the java.io package is forbidden in the spec). However, I have
the ff line in each of my EJB's:
>
> private static final Logger L = Logger.getLogger(SomeEJBClass.class);
>
> The EJB server I am using (Borland Enterprise Server V5.0) does not
complain about anything in this regard.
>
> Can someone tell me if there are any hidden problems with this 
> approach -
we have just started our project and I don't want to get any surprises
later on.
>
> Thanks in advance.
>
> Chris
>
>
>
>
>
>
>
> I
>
>
>
> -
> Sign up to watch the FIFA World Cup video highlights from your desk!
>
> http://fifaworldcup.yahoo.com/fc/en


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


Re: Using Log4J in EJB server

2002-05-27 Thread Steve Ebersole

The direct use of the java.io package is forbidden by the EJB spec.  That
does not mean that your EJBs cannot use classes/libraries which use the
java.io package.  I use log4j in a J2EE environment with no problems
(although i log to a JMS queue from within the app components).


- Original Message -
From: "Chris Naude" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 10:26 AM
Subject: Using Log4J in EJB server


>
> Hi
>
> I have been looking at the log4j archives regarding the use of log4j
inside an EJB. I am not quite sure what all the discussion is about (as
usage of the java.io package is forbidden in the spec). However, I have the
ff line in each of my EJB's:
>
> private static final Logger L = Logger.getLogger(SomeEJBClass.class);
>
> The EJB server I am using (Borland Enterprise Server V5.0) does not
complain about anything in this regard.
>
> Can someone tell me if there are any hidden problems with this approach -
we have just started our project and I don't want to get any surprises later
on.
>
> Thanks in advance.
>
> Chris
>
>
>
>
>
>
>
> I
>
>
>
> -
> Sign up to watch the FIFA World Cup video highlights from your desk!
>
> http://fifaworldcup.yahoo.com/fc/en


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using log4j

2002-05-21 Thread Shapira, Yoav

Howdy,
It's definitely and easily possible with log4j.  See the javadoc for 
DailyRollingFileAppender.  (If you've never used log4j before, it may make better 
sense if you read the short manual first).

Depending on how your own logging mechanism works, it may make sense to use a façade 
and just use all log4j under it, or replace your mechanism with log4j altogether. 

Good luck ;)

Yoav Shapira
ChemInformatics


>-Original Message-
>From: Anand M S [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, May 21, 2002 4:00 PM
>To: [EMAIL PROTECTED]
>Subject: Using log4j
>
>
>Hi,
>
> I'm new to this group. Currently I have my own logging mechanisim, but I
>want to reset(should archive the old file and start new file) the log file
>depending on date, is this possible with log4J? can I use log4j in my
>logging module for this purpose?
>
>
>
>Thanks in advance,
>
>Anand
>
>
>
>
>
>-
>Do You Yahoo!?
>LAUNCH - Your Yahoo! Music Experience

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Using log4j in an applet

2002-04-14 Thread Srinivasarao Nandiwada

Thanks adam. As you described, I notice these only during log4j 
initialization (once per VM). I wonder whether there is a way to tell 
Java not to look for these classes. Thanks again for your reply.

-nsr

[EMAIL PROTECTED] wrote:

> This is standard "bean" behaviour. These class are optional XXXBeanInfo
> classes for class XXX that *if* they are found/load can contain additional
> metadata about the bean. Log4J does not need that, but still Java does the
> attempt for them.
> 
> This isn't a bug, so I'd guess there is no fix. I doubt it'll cause you much
> problem (other than confusion) since it will only do it the first time your
> log4j configuration is loaded.
> 
> If you see it a lot, I'd worry that log4j is being configured "too
> often" -- hmm, I guess it will be, once per remote applet VM.
> Hmmm... interesting, good luck. :-)
> 
> regards
> 
> Adam
> -Original Message-
> From: Srinivasarao Nandiwada [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 12, 2002 12:41 PM
> To: [EMAIL PROTECTED]
> Subject: Using log4j in an applet
> 
> 
> Hi,
> 
> I am using log4j (V1.1.3) in an applet and works great except that I
> notice a strange behavior while loading the applet. I notice that applet
> is making connection to server and trying to retrieve a few class files
> other than log4j.jar (see below) and wondering whether any one has seen
> this behavior and know any fixes? My applet does not do anything other
> than displaying a "hello world" string and log the same.  I notice that
> loading of the applet takes about 35 to 40 seconds (server on same box
> running the browser). However, subsequent invocations (without closing
> the browser) take less than two seconds.
> 
> I don't see PatternLayoutBeanInfo class in log4j.jar and I greped in
> log4j sources, and didn't find it anywhere. For sure, I don't see these
> extra calls if I don't use log4j. Quite confused. Any help?
> 
> Thanks,
> nsr
> 
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/jars/log4j.jar HTTP/1.1" 200 158892^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/log4j.properties HTTP/1.1" 400 751^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/org/apache/log4j/PatternLayoutBeanInfo.class
> HTTP/1.1" 400 835^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/org/apache/log4j/PatternLayoutBeanInfo.class
> HTTP/1.1" 400 835^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/sun/beans/infos/PatternLayoutBeanInfo.class
> HTTP/1.1" 400 832^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/sun/beans/infos/PatternLayoutBeanInfo.class
> HTTP/1.1" 400 832^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/org/apache/log4j/LayoutBeanInfo.class HTTP/1.1"
> 400 814^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/org/apache/log4j/LayoutBeanInfo.class HTTP/1.1"
> 400 814^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/sun/beans/infos/LayoutBeanInfo.class HTTP/1.1"
> 400 811^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/java/lang/ObjectBeanInfo.class HTTP/1.1" 400 793^M
> 127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
> /campaignapp/do/campaign/sun/beans/infos/ObjectBeanInfo.class HTTP/1.1"
> 400 811^M
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using log4j in an applet

2002-04-12 Thread ajack

This is standard "bean" behaviour. These class are optional XXXBeanInfo
classes for class XXX that *if* they are found/load can contain additional
metadata about the bean. Log4J does not need that, but still Java does the
attempt for them.

This isn't a bug, so I'd guess there is no fix. I doubt it'll cause you much
problem (other than confusion) since it will only do it the first time your
log4j configuration is loaded.

If you see it a lot, I'd worry that log4j is being configured "too
often" -- hmm, I guess it will be, once per remote applet VM.
Hmmm... interesting, good luck. :-)

regards

Adam
-Original Message-
From: Srinivasarao Nandiwada [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 12:41 PM
To: [EMAIL PROTECTED]
Subject: Using log4j in an applet


Hi,

I am using log4j (V1.1.3) in an applet and works great except that I
notice a strange behavior while loading the applet. I notice that applet
is making connection to server and trying to retrieve a few class files
other than log4j.jar (see below) and wondering whether any one has seen
this behavior and know any fixes? My applet does not do anything other
than displaying a "hello world" string and log the same.  I notice that
loading of the applet takes about 35 to 40 seconds (server on same box
running the browser). However, subsequent invocations (without closing
the browser) take less than two seconds.

I don't see PatternLayoutBeanInfo class in log4j.jar and I greped in
log4j sources, and didn't find it anywhere. For sure, I don't see these
extra calls if I don't use log4j. Quite confused. Any help?

Thanks,
nsr

127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/jars/log4j.jar HTTP/1.1" 200 158892^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/log4j.properties HTTP/1.1" 400 751^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/org/apache/log4j/PatternLayoutBeanInfo.class
HTTP/1.1" 400 835^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/org/apache/log4j/PatternLayoutBeanInfo.class
HTTP/1.1" 400 835^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/sun/beans/infos/PatternLayoutBeanInfo.class
HTTP/1.1" 400 832^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/sun/beans/infos/PatternLayoutBeanInfo.class
HTTP/1.1" 400 832^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/org/apache/log4j/LayoutBeanInfo.class HTTP/1.1"
400 814^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/org/apache/log4j/LayoutBeanInfo.class HTTP/1.1"
400 814^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/sun/beans/infos/LayoutBeanInfo.class HTTP/1.1"
400 811^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/java/lang/ObjectBeanInfo.class HTTP/1.1" 400 793^M
127.0.0.1 - - [12/Apr/2002:13:58:30 -0500] "GET
/campaignapp/do/campaign/sun/beans/infos/ObjectBeanInfo.class HTTP/1.1"
400 811^M


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using log4j with EJB

2002-03-22 Thread Michael Wang (IT)

One question about using log4j with EJB. (WebSphere 4.0)

The log4j works smoothly with any Java code except EJB beans. All log4j
codes among EJB beans just don't produce any output in the log file. Anyone
on the same boat?
Or should I configure Websphere to allow it to use log4j ('cause log4j
violates EJB spec, e.g. reflection, etc)

Thanks.

Mike


-Original Message-
From: ajack [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 21, 2002 10:37 AM
To: 'Log4J Users List'
Subject: RE: Using log4j with EJB


The suggestion that Adam made regarding use of JNDI sounds the most
appealing and I have a couple of questions:

1.  You establish the java:comp/env/... settings for Log4J in the
app
server XML configuration file(s), correct?

Our app server implements JNDI via CORBA naming, and the underlying storage
is not XML, but I guess from your question your is.

2.  Using this method of configuration, are you able to use the
automatic reload capability so that changes can be made to the
configuration at runtime without having to cycle the app server?

I suspect one could, it "hits" JNDI each time a property request is made,
but we've chosen not to try, for performance. Our code, including logging
code, loads configuration only once.

3.  The Properties extension you wrote, is that something you would
be
willing to release to the open source community? :-) (worth a shot).

"willing to release" implies release worthy, any this code is not the
quality of that.  No testing on other app servers, not optimised, no
documentation, you know the kind: it works well enough for us. That said,
I'll send you a few classes if you want, maybe the code will be like a
sample.

regards

Adam



RE: Using log4j with EJB

2002-03-21 Thread Ceki Gülcü


Indeed, reading the restriction as pertaining only private fields is
entirely reasonable. Now, does reflection allow the access of private
fields? I don't think so.

Furthermore, if you read two pages ahead in the EJB 2.0 spec, Table 19
explicitly states that the application server should deny
java.lang.reflect.ReflectPermission to EJBs.

Here is snip from the javadocs:

ReflectPermission
=

The Permission class for reflective operations. A ReflectPermission is
a named permission and has no actions. The only name currently defined
is suppressAccessChecks, which allows suppressing the standard Java
language access checks -- for public, default (package) access,
protected, and private members -- performed by reflected objects at
their point of use.

The following table provides a summary description of what the
permission allows, and discusses the risks of granting code the
permission.

What the Permission Allows:

   Ability to access fields and invoke methods in a class. Note that
   this includes not only public, but protected and private fields and
   methods as well.

Risks of Allowing this Permission

   This is dangerous in that information (possibly confidential) and
   methods normally unavailable would be accessible to malicious code.


Rereading the above more carefully, it seems that granting the
ReflectPermission allows the user to access private fields. So your
comments were entirely appropriate. I was misreading the spec. Thanks
for the correction.


At 17:38 21.03.2002 -0500, you wrote:
>I'm not sure there is a restriction on using reflection in EJB.  On page
>495 of the EJB 2.0 spec, in section 24.1.2, Programming Restrictions:
>
>The enterprise bean must not attempt to query a class to obtain
>information about the declared
>members that are not otherwise accessible to the enterprise bean because
>of the security rules
>of the Java language. The enterprise bean must not attempt to use the
>Reflection API to access
>information that the security rules of the Java programming language
>make unavailable.
>
>Maybe I'm reading too literally, but the restriction is on using
>reflection to circumvent standard Java security.  I don't think log4j
>use of reflection is breaking this rule; e.g., you're not manipulating
>private fields or calling private methods, are you?
>
>I'm also making use of reflection for some startup code (which populates
>the JNDI tree based on configuration files and databases) and would be
>quite dismayed if a container should choose to disallow it.
>
>Rich
>
>  -Original Message-
>From:   Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>Sent:   Wednesday, March 20, 2002 7:38 PM
>To: Log4J Users List
>Subject:Re: Using log4j with EJB
>
>
>XYZConfigurator.configureAndWatch is known to work (in single server
>mode) with WebSphere 4, Weblogic 6.1, Orion and JBoss. This particular
>method call violates the EJB spec on three accounts. 1) It uses
>reflection. 2) It accesses a file. 3) It spawns a thread.
>
>I find the restriction on reflection particularly unacceptable because
>a lot of interesting stuff can only be done using reflection. In any
>case, the section entitled "Programming Restrictions" has a lot of
>impact on user code but it is particularly unclear.
>
>
>At 17:56 20.03.2002 -0600, Bobby Nations wrote:
> >Scot,
> >
> >We're using WebLogic 6.1 and having no trouble with the
>configureAndWatch(
> >"log4j.properties" ) methods.  We placed the directory holding the
> >properties file into the server's classpath, and it finds it no
>problem.
> >
> >Yeah, I know, this violates the EJB spec, but hey, it works for us and
>we
> >have no plans of switching app servers any time soon.  Of course, BEA
> >could always take it away from us at some point, but we'll cross that
> >bridge when we get to it.
> >
> >Your mileage may vary,
> >
> >Bobby
> >
> >
> >Bellamy, Scot wrote:
> >
> >>In our environment we are using J2EE, including EJB.  We would like to
> >>employ Log4J as our logging utility for new projects.  This isn't a
> >>problem with the exception of EJB.  We have identified a way to write
> >>log messages utilizing JMS to send to a separate running process.
> >>However, we haven't found a good way to utilize the Log4J
>configuration
> >>files in EJB, since EJB code cannot utilize the java.io package.  Has
> >>anyone discovered a way to accomplish this?
> >>
> >>
> >>Thanks,
> >>
> >>Scot.
> >>
> >>
> >
> >--
> >Sr. Programmer / Analyst
> >FedEx Services
> >20 FedEx Parkway
>

RE: Using log4j with EJB

2002-03-21 Thread Rich Steele

I'm not sure there is a restriction on using reflection in EJB.  On page
495 of the EJB 2.0 spec, in section 24.1.2, Programming Restrictions:

The enterprise bean must not attempt to query a class to obtain
information about the declared
members that are not otherwise accessible to the enterprise bean because
of the security rules
of the Java language. The enterprise bean must not attempt to use the
Reflection API to access
information that the security rules of the Java programming language
make unavailable.

Maybe I'm reading too literally, but the restriction is on using
reflection to circumvent standard Java security.  I don't think log4j
use of reflection is breaking this rule; e.g., you're not manipulating
private fields or calling private methods, are you?

I'm also making use of reflection for some startup code (which populates
the JNDI tree based on configuration files and databases) and would be
quite dismayed if a container should choose to disallow it.

Rich

 -Original Message-
From:   Ceki Gülcü [mailto:[EMAIL PROTECTED]] 
Sent:   Wednesday, March 20, 2002 7:38 PM
To: Log4J Users List
Subject:Re: Using log4j with EJB


XYZConfigurator.configureAndWatch is known to work (in single server
mode) with WebSphere 4, Weblogic 6.1, Orion and JBoss. This particular
method call violates the EJB spec on three accounts. 1) It uses
reflection. 2) It accesses a file. 3) It spawns a thread.

I find the restriction on reflection particularly unacceptable because
a lot of interesting stuff can only be done using reflection. In any
case, the section entitled "Programming Restrictions" has a lot of
impact on user code but it is particularly unclear.


At 17:56 20.03.2002 -0600, Bobby Nations wrote:
>Scot,
>
>We're using WebLogic 6.1 and having no trouble with the
configureAndWatch( 
>"log4j.properties" ) methods.  We placed the directory holding the 
>properties file into the server's classpath, and it finds it no
problem.
>
>Yeah, I know, this violates the EJB spec, but hey, it works for us and
we 
>have no plans of switching app servers any time soon.  Of course, BEA 
>could always take it away from us at some point, but we'll cross that 
>bridge when we get to it.
>
>Your mileage may vary,
>
>Bobby
>
>
>Bellamy, Scot wrote:
>
>>In our environment we are using J2EE, including EJB.  We would like to
>>employ Log4J as our logging utility for new projects.  This isn't a
>>problem with the exception of EJB.  We have identified a way to write
>>log messages utilizing JMS to send to a separate running process.
>>However, we haven't found a good way to utilize the Log4J
configuration
>>files in EJB, since EJB code cannot utilize the java.io package.  Has
>>anyone discovered a way to accomplish this?
>>
>>
>>Thanks,
>>
>>Scot.
>>
>>
>
>--
>Sr. Programmer / Analyst
>FedEx Services
>20 FedEx Parkway
>Collierville, TN  38017
>(901) 263-6517
>
>
>
>
>--
>To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>

--
Ceki


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: Using log4j with EJB

2002-03-21 Thread ajack

The suggestion that Adam made regarding use of JNDI sounds the most
appealing and I have a couple of questions:

1.  You establish the java:comp/env/... settings for Log4J in the
app
server XML configuration file(s), correct?

Our app server implements JNDI via CORBA naming, and the underlying storage
is not XML, but I guess from your question your is.

2.  Using this method of configuration, are you able to use the
automatic reload capability so that changes can be made to the
configuration at runtime without having to cycle the app server?

I suspect one could, it "hits" JNDI each time a property request is made,
but we've chosen not to try, for performance. Our code, including logging
code, loads configuration only once.

3.  The Properties extension you wrote, is that something you would
be
willing to release to the open source community? :-) (worth a shot).

"willing to release" implies release worthy, any this code is not the
quality of that.  No testing on other app servers, not optimised, no
documentation, you know the kind: it works well enough for us. That said,
I'll send you a few classes if you want, maybe the code will be like a
sample.

regards

Adam



winmail.dat
Description: application/ms-tnef

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


RE: Using log4j with EJB

2002-03-21 Thread Bellamy, Scot

Thanks for all of the suggestions that were made to help solve my
problem.  Open Source rules!

I understand that the EJB container providers are not restricting use of
java.io and that is an option.  However, I want to keep as close to the
specification as possible.  

The suggestion that Adam made regarding use of JNDI sounds the most
appealing and I have a couple of questions:

1.  You establish the java:comp/env/... settings for Log4J in the app
server XML configuration file(s), correct?

2.  Using this method of configuration, are you able to use the
automatic reload capability so that changes can be made to the
configuration at runtime without having to cycle the app server?

3.  The Properties extension you wrote, is that something you would be
willing to release to the open source community? :-) (worth a shot).

Thanks,
Scot.

-Original Message-
From: ajack [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, March 20, 2002 6:21 PM
To: 'Log4J Users List'
Subject: RE: Using log4j with EJB


"Bellamy, Scot" <[EMAIL PROTECTED]> on 21/03/2002 06:07:55
wrote:

[...] we haven't found a good way to utilize the Log4J
configuration
files in EJB, since EJB code cannot utilize the java.io package.
Has
anyone discovered a way to accomplish this?

We wrote a Properties sub-class that used JNDI to access the
java:comp/env/
context, and pass that to PropertyConfigurator.configure().

We also found we could initialise Log4j in an app server start-up
function,
so EJBs wouldn't have to, and 'cos they shared the VM things worked. You
app
server may vary.

Good luck.

regards

Adam


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: Using log4j with EJB

2002-03-20 Thread ajack

Same would probably work w/ EAServer, the Sybase app server, it (in
violation no doubt) allows IO access also. I guess the IO restrictions are
to allow for distribution/failover/loadbalancing --- where the file system
could "change under you" as your EJB is run on another host --- but app
server folks appear to be saying "if you want to, your call..."

regards

Adam
-Original Message-
From: Bobby Nations [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 4:57 PM
To: Log4J Users List
Subject: Re: Using log4j with EJB


Scot,

We're using WebLogic 6.1 and having no trouble with the
configureAndWatch( "log4j.properties" ) methods.  We placed the
directory holding the properties file into the server's classpath, and
it finds it no problem.

Yeah, I know, this violates the EJB spec, but hey, it works for us and
we have no plans of switching app servers any time soon.  Of course, BEA
could always take it away from us at some point, but we'll cross that
bridge when we get to it.

Your mileage may vary,

Bobby


Bellamy, Scot wrote:

>In our environment we are using J2EE, including EJB.  We would like to
>employ Log4J as our logging utility for new projects.  This isn't a
>problem with the exception of EJB.  We have identified a way to write
>log messages utilizing JMS to send to a separate running process.
>However, we haven't found a good way to utilize the Log4J configuration
>files in EJB, since EJB code cannot utilize the java.io package.  Has
>anyone discovered a way to accomplish this?
>
>
>
>Thanks,
>
>Scot.
>
>
>
>

--
Sr. Programmer / Analyst
FedEx Services
20 FedEx Parkway
Collierville, TN  38017
(901) 263-6517




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: Using log4j with EJB

2002-03-20 Thread Ceki Gülcü


XYZConfigurator.configureAndWatch is known to work (in single server
mode) with WebSphere 4, Weblogic 6.1, Orion and JBoss. This particular
method call violates the EJB spec on three accounts. 1) It uses
reflection. 2) It accesses a file. 3) It spawns a thread.

I find the restriction on reflection particularly unacceptable because
a lot of interesting stuff can only be done using reflection. In any
case, the section entitled "Programming Restrictions" has a lot of
impact on user code but it is particularly unclear.


At 17:56 20.03.2002 -0600, Bobby Nations wrote:
>Scot,
>
>We're using WebLogic 6.1 and having no trouble with the configureAndWatch( 
>"log4j.properties" ) methods.  We placed the directory holding the 
>properties file into the server's classpath, and it finds it no problem.
>
>Yeah, I know, this violates the EJB spec, but hey, it works for us and we 
>have no plans of switching app servers any time soon.  Of course, BEA 
>could always take it away from us at some point, but we'll cross that 
>bridge when we get to it.
>
>Your mileage may vary,
>
>Bobby
>
>
>Bellamy, Scot wrote:
>
>>In our environment we are using J2EE, including EJB.  We would like to
>>employ Log4J as our logging utility for new projects.  This isn't a
>>problem with the exception of EJB.  We have identified a way to write
>>log messages utilizing JMS to send to a separate running process.
>>However, we haven't found a good way to utilize the Log4J configuration
>>files in EJB, since EJB code cannot utilize the java.io package.  Has
>>anyone discovered a way to accomplish this?
>>
>>
>>Thanks,
>>
>>Scot.
>>
>>
>
>--
>Sr. Programmer / Analyst
>FedEx Services
>20 FedEx Parkway
>Collierville, TN  38017
>(901) 263-6517
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>

--
Ceki


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Using log4j with EJB

2002-03-20 Thread Bobby Nations

Scot,

We're using WebLogic 6.1 and having no trouble with the 
configureAndWatch( "log4j.properties" ) methods.  We placed the 
directory holding the properties file into the server's classpath, and 
it finds it no problem.  

Yeah, I know, this violates the EJB spec, but hey, it works for us and 
we have no plans of switching app servers any time soon.  Of course, BEA 
could always take it away from us at some point, but we'll cross that 
bridge when we get to it.

Your mileage may vary,

Bobby


Bellamy, Scot wrote:

>In our environment we are using J2EE, including EJB.  We would like to
>employ Log4J as our logging utility for new projects.  This isn't a
>problem with the exception of EJB.  We have identified a way to write
>log messages utilizing JMS to send to a separate running process.
>However, we haven't found a good way to utilize the Log4J configuration
>files in EJB, since EJB code cannot utilize the java.io package.  Has
>anyone discovered a way to accomplish this?
>
> 
>
>Thanks,
>
>Scot.
>
> 
>
>

-- 
Sr. Programmer / Analyst
FedEx Services
20 FedEx Parkway
Collierville, TN  38017
(901) 263-6517




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using log4j with EJB

2002-03-20 Thread ajack


"Bellamy, Scot" <[EMAIL PROTECTED]> on 21/03/2002 06:07:55 wrote:

[...] we haven't found a good way to utilize the Log4J configuration
files in EJB, since EJB code cannot utilize the java.io package.  Has
anyone discovered a way to accomplish this?

We wrote a Properties sub-class that used JNDI to access the java:comp/env/
context, and pass that to PropertyConfigurator.configure().

We also found we could initialise Log4j in an app server start-up function,
so EJBs wouldn't have to, and 'cos they shared the VM things worked. You app
server may vary.

Good luck.

regards

Adam


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Using log4j with EJB

2002-03-20 Thread david.gray



I do not use Log4j specifically but if you had an LDAP server you could
store the XML in there. The XML can be quite long depending on the LDAP
server. You would read the string from LDAP and then convert the string to
an InputStream as follows:

  byte[] xmlStream = aString.getBytes();
  ByteArrayInputStream bais = new ByteArrayInputStream(xmlStream);

I know it is a Input stream but it is in memory so is not using IO to disk.

 (I have tried this but not inside an EJB only in command line).





"Bellamy, Scot" <[EMAIL PROTECTED]> on 21/03/2002 06:07:55

Please respond to "Log4J Users List" <[EMAIL PROTECTED]>

To:<[EMAIL PROTECTED]>
cc:

Subject:Using log4j with EJB

In our environment we are using J2EE, including EJB.  We would like to
employ Log4J as our logging utility for new projects.  This isn't a
problem with the exception of EJB.  We have identified a way to write
log messages utilizing JMS to send to a separate running process.
However, we haven't found a good way to utilize the Log4J configuration
files in EJB, since EJB code cannot utilize the java.io package.  Has
anyone discovered a way to accomplish this?



Thanks,

Scot.













NOTICE - This message is intended only for the use of the 
addressee named above and may contain privileged and 
confidential information.  If you are not the intended recipient
of this message you are hereby notified that you must not 
disseminate, copy or take any action based upon it.  If you 
received this message in error please notify HIC immediately.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of HIC.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: Using log4j with EJB

2002-03-20 Thread Bellamy, Scot

Actually, I already have solved the issue of writing error messages.  I
am looking for a way to read the Log4J configuration file(s) at startup.
Are you simply putting this configuration in your deployment descriptor
or have you found another way to handle run-time configuration of Log4J?

Scot.


-Original Message-
From: Nate Drake [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, March 20, 2002 2:16 PM
To: Log4J Users List
Subject: RE: Using log4j with EJB

We're using the JDBCAppender by Thomas Fenner
(http://support.klopotek.de/log4j/jdbc/default.htm).  This will put your
log
messages into a database.  It works great for us.

-Original Message-
From: Bellamy, Scot [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 2:08 PM
To: [EMAIL PROTECTED]
Subject: Using log4j with EJB


In our environment we are using J2EE, including EJB.  We would like to
employ Log4J as our logging utility for new projects.  This isn't a
problem with the exception of EJB.  We have identified a way to write
log messages utilizing JMS to send to a separate running process.
However, we haven't found a good way to utilize the Log4J configuration
files in EJB, since EJB code cannot utilize the java.io package.  Has
anyone discovered a way to accomplish this?



Thanks,

Scot.





--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: Using log4j with EJB

2002-03-20 Thread Nate Drake

We're using the JDBCAppender by Thomas Fenner
(http://support.klopotek.de/log4j/jdbc/default.htm).  This will put your log
messages into a database.  It works great for us.

-Original Message-
From: Bellamy, Scot [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 2:08 PM
To: [EMAIL PROTECTED]
Subject: Using log4j with EJB


In our environment we are using J2EE, including EJB.  We would like to
employ Log4J as our logging utility for new projects.  This isn't a
problem with the exception of EJB.  We have identified a way to write
log messages utilizing JMS to send to a separate running process.
However, we haven't found a good way to utilize the Log4J configuration
files in EJB, since EJB code cannot utilize the java.io package.  Has
anyone discovered a way to accomplish this?



Thanks,

Scot.





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4J for auditing?

2001-11-14 Thread Leathers, Burton

Noah,

I am in the midst of building a facility based on log4j which handles
auditing, tracing, performance and chargeback records. The key is to note
that the sets of categories appropriate to each of these activities may
differ and that simple text records are rarely sufficient.

I have made extensive use of the Renderer capability which is tersely
described in the documentation. In addition, I have specialized the the
Category class so that each specialized form accepts only objects of a
specific class (or instances of descendents). In addition, when category
trees are created, their names are prefixed with the activity (auditing
etc.) for which thy are used.

I have found log4 (j&cpp) to be a pretty good base on which to build. The
Java version is distinctly stronger than the C++ version but that, I trust,
reflects the fact that it is early days for the C++ implementation. The
thing which made me a log4 user was changing my question from "Can log4 do
what I need" to "How must I extend log4 to do what I need". Once I asked the
right question, the answer was blindingly obvious.

Hope this helps,

Burton

Burton Leathers
Software Architect

The end of the human race will be that it will eventually die of
civilization.  Ralph Waldo Emerson


-Original Message-
From: Noah Davis [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 1:54 PM
To: [EMAIL PROTECTED]
Subject: using log4J for auditing?


Still new to Log4J and I want to get an idea if it's
really the right tool for what I need. In some
respects it's spot on - I need to be able to log
exceptions at different priorities and categories. ok,
so far so good.

However, there's another requirement which is somewhat
different, and that's an auditing requirement.
Correctly or not, I consider auditing, at least of the
kind I need, to be a separate kind of activity than
exception logging for 2 reasons:

1. There is no priority concept for auditing. Or, if
you'd like, auditing is all of level "info" - but
there's no need to distinguish between one kind of
auditing and another in terms of priority.

2. At least in the system I'd be working with,
exceptions are just exceptions which don't differ much
as far as the information stored (message, time, stack
trace, etc), but one audit trail may differ widely
from another. For example, in a brokerage system, an
audit record for a buy order will differ significantly
from an audit record for a customer registering on the
system. This information would also need to be
captured relationally (I know log4j has some jdbc
appenders)

Where log4J would still come in handy is in its
configuration of categories. The ability to turn on
and off audit trails (a requirement of the system)
could probably be handled through log4j's
configuration of categories.

However, given the differences, does log4j still make
sense for auditing? In Paul Glezen's article "Adding
conversion characters to patternlayout" he extends 6
classes just to log some new information -- if
auditing has a heavy "information extension"
requirement, perhaps log4j doesn't fit the bill in
this case.  Thanks for any thoughts on this.

Noah

__
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender by
e-mail promptly that you have done so.  Thank You.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




Re: Using log4j with JBoss-2.4.3

2001-10-31 Thread Yoav Shapira

Howdy,
If you could post your config file and exceptions test, maybe we could
do a better job helping ;)  Are they actual log4j exceptions, or 
stuff like SAXFactory configuration errors, linkage errors, etc. ?

Yoav

Rajesh S Patil wrote:
> 
> Hi all
> 
> Has any one used log4j with JBoss-2.4.3
> I getting exception while using log4j in my own beans deployed in JBoss-2.4.3
> 
> any one has any solution
> 
> thanking you all
> Regards
> 
> Rajesh S
> Software Engineer
> Velankaini Information Systems Ltd.
> Electronic city Bangalore
> 
> mail to: [EMAIL PROTECTED]
> ph: 91-80-8522507/509
> fax:  91-80-8522508

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: using log4j in multithreaded environment

2001-10-15 Thread Millard, Ray

You can sort your output based on whatever you pushed onto your NDC.  For
example, you could insert some characters between each of the pieces of
information that you are logging (to delineate the information), for example
the ~ character.  Then, open the file in some program that can sort, for
example Microsoft Excel.  Next, sort your output.

> -Original Message-
> From: Andrew B [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, October 15, 2001 11:06 AM
> To:   [EMAIL PROTECTED]
> Subject:  using log4j in multithreaded environment
> 
> Hi,
> 
> Is there an appender that allows all the output from
> each thread to be grouped together? I have a
> multithreaded web server environment (Tomcat), as do
> many of you I suspect, and would like to use log4j
> server-side. The manual discusses multithreading, and
> suggests not using a category for each thread, but
> using the NDC instead with the thread ID.
> 
> However, this won't produce the result I am looking
> for: the ability to have the output from each thread
> grouped together instead of interleaved with that of
> other threads. For example, assuming concurrent
> threads:
> 
> Normal output:
> Thread-1: start request
> Thread-2: start request
> Thread-1: end request
> Thread-2: end  request
> 
> Desired output:
> Thread-1: start request
> Thread-1: end request
> Thread-2: start request
> Thread-2:  request
> 
> I realise that to do this you would somehow have to
> tell it to start buffering at the start of the request
> and flush at the end. Would subclassing an appender
> work? Is there already an appender for this?
> 
> Thanks,
> 
> Andrew Broderick
> 
> 
> 
> =
> The geek shall inherit the earth.
> 
> __
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Using log4j in JSP's

2001-10-11 Thread David Schultz

The parameter to the Category.getInstance(String name) is just some name to
look for in the properties.  That is, you do not HAVE to use a class name
(although that is the preffered technique).  Since JSPs get translated into
servlets with a hidden classname, you can make up your own heirarchy for
pages.  I'd use the relative pathing from the Web context with "jsp" as the
root level.

So, lets say I'm doing logging in the following JSP file
myapp/jsp/authentication/login.jsp :

<% Category cat = Category.getInstance("jsp.authentication.login"); %>

You could even just use "jsp" if you want ALL jsp pages to log in the same
manner.  If there is a log4j.category.jsp entry in your properties, it will
get used.  Otherwise, you inherit from the the rootCategory.

That should get you started...

-Original Message-
From: Tom Bednarz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 11.October 2001 10:39
To: log4j user list
Subject: Using log4j in JSP's


Hello,

Can log4j be used in JSP's? If so how?

The problem is, that I have to do something like:

class myClass
{
   static Cateory cat = Category.getInstance(myClass.class);
   
}

The problem is, that I do not know the name of the class since it is
generated by the jsp compiler. I currently use jRun. A JSP named myPage
will become jrun__myClass2ejspb. This is for sure different when I use a
different application server.

Has anybody a suggestion how this problem could be solved?

Thomas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Using log4j in JSP's

2001-10-11 Thread Mitchell Ackermann

The convention of using .class or .class.getName() is a convention that many or 
most people follow, but it's not a hard an fast rule.
Just use a different scheme for naming the Category.
e.g. for a file x.jsp, I've used something like
   private static Cateory cat = Category.getInstance("jsp.x");
or
   private static Cateory cat = Category.getInstance(  + ".jsp.x");
or something similar.

Mitchell Ackermann

- Original Message - 
From: Tom Bednarz <[EMAIL PROTECTED]>
To: log4j user list <[EMAIL PROTECTED]>
Sent: Thursday, October 11, 2001 9:38 AM
Subject: Using log4j in JSP's


Hello,

Can log4j be used in JSP's? If so how?

The problem is, that I have to do something like:

class myClass
{
   static Cateory cat = Category.getInstance(myClass.class);
   
}

The problem is, that I do not know the name of the class since it is 
generated by the jsp compiler. I currently use jRun. A JSP named myPage 
will become jrun__myClass2ejspb. This is for sure different when I use a 
different application server.

Has anybody a suggestion how this problem could be solved?

Thomas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Using log4j in JSP's

2001-10-11 Thread Joe Pollard

Have you looked at the jakarta taglibs project?  There is one that
preforms logging that uses the log4j package.  You can then enter into
your pages:


<%
String message = "something"
%>


You can also use categories like this:



What a crazy error that was!!!


Check out http://jakarta.apache.org/taglibs/doc/log-doc/intro.html
Hope that helps

-Joe
-Original Message-
From: Tom Bednarz [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, October 11, 2001 9:39 AM
To: log4j user list
Subject: Using log4j in JSP's


Hello,

Can log4j be used in JSP's? If so how?

The problem is, that I have to do something like:

class myClass
{
   static Cateory cat = Category.getInstance(myClass.class);
   
}

The problem is, that I do not know the name of the class since it is 
generated by the jsp compiler. I currently use jRun. A JSP named myPage 
will become jrun__myClass2ejspb. This is for sure different when I use a

different application server.

Has anybody a suggestion how this problem could be solved?

Thomas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Using log4j in custom tag libraries

2001-06-06 Thread Johri, Priyank

Hey Doug,
I did the same for WebLogic. If you want to use basic configuration, this
is fine. If you want to do more, like call configureAndWatch to see
if the log4j.properties changes, then you have to do more.

Ceki suggested using a servlet that is loaded when the appserver comes up.
This servlet should do the initialization (in its init maybe?)..

Let me know what you eventually come up with.

Priyank


-Original Message-
From: Doug Grimwade [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 7:13 AM
To: LOG4J Users Mailing List
Subject: Re: Using log4j in custom tag libraries


Hi,

I think I may be able to answer my own question now (having read the
manual a little more carefully). In case anyone is having a similar
problem I have outline the approach below:

Basically I am using the default initialisation method and it seems to
work great.

In each tag class I do the usual stuff

static Category cat = Category.getInstance(...);
...
cat.debug("debug message");

For initialisation I simply set the environment variable TOMCAT_OPTS as
follows

TOMCAT_OPTS="-Dlog4j.configuration=file:/filename path"

and then run tomcat as normal. When my tags are invoked I get a nice
stream of output messages in the log - brilliant.

Before I get carried away with my enthusiasm for this - are there any
problems or restrictions using this approach that anyone can advise me
of ?

Regards

Doug

--
Doug Grimwade wrote:
> 
> Hi,
> 
> I am trying to replace the System.out.println() logging in my custom tag
> library with log4j (using jakarta 3.2.1). I have added
> Category.getInstance() calls in each tag but I am not sure where I
> should add the log4j initialisation code.  Do I just have a static
> initialisation block in one of the tags I think will get loaded quickly
> ? I tried this and I can see messages from the static block in the log
> file but not messages from other classes - I am not sure why not. But
> this doesn't seem a very clean way of initialising log4j but I am not
> sure what else I can do.
> 
> Any clues to point me in the right direction would be much appreciated.
> What I am really aiming for is a way of logging all activity from
> several custom tag libraries in a single log file.
> 
> Regards
> 
> Doug
> --
> Doug Grimwade   [EMAIL PROTECTED]
> Olive Systems Limited   Tel:01206 217961
> The Old Exchange, 64 West Stockwell Street, Fax:01206 575101
> Colchester, Essex, CO1 1HE, England Mob:07775 556535
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Doug Grimwade   [EMAIL PROTECTED]
Olive Systems Limited   Tel:01206 217961
The Old Exchange, 64 West Stockwell Street, Fax:01206 575101
Colchester, Essex, CO1 1HE, England Mob:07775 556535

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Using log4j in custom tag libraries

2001-06-06 Thread Doug Grimwade

Hi,

I think I may be able to answer my own question now (having read the
manual a little more carefully). In case anyone is having a similar
problem I have outline the approach below:

Basically I am using the default initialisation method and it seems to
work great.

In each tag class I do the usual stuff

static Category cat = Category.getInstance(...);
...
cat.debug("debug message");

For initialisation I simply set the environment variable TOMCAT_OPTS as
follows

TOMCAT_OPTS="-Dlog4j.configuration=file:/filename path"

and then run tomcat as normal. When my tags are invoked I get a nice
stream of output messages in the log - brilliant.

Before I get carried away with my enthusiasm for this - are there any
problems or restrictions using this approach that anyone can advise me
of ?

Regards

Doug

--
Doug Grimwade wrote:
> 
> Hi,
> 
> I am trying to replace the System.out.println() logging in my custom tag
> library with log4j (using jakarta 3.2.1). I have added
> Category.getInstance() calls in each tag but I am not sure where I
> should add the log4j initialisation code.  Do I just have a static
> initialisation block in one of the tags I think will get loaded quickly
> ? I tried this and I can see messages from the static block in the log
> file but not messages from other classes - I am not sure why not. But
> this doesn't seem a very clean way of initialising log4j but I am not
> sure what else I can do.
> 
> Any clues to point me in the right direction would be much appreciated.
> What I am really aiming for is a way of logging all activity from
> several custom tag libraries in a single log file.
> 
> Regards
> 
> Doug
> --
> Doug Grimwade   [EMAIL PROTECTED]
> Olive Systems Limited   Tel:01206 217961
> The Old Exchange, 64 West Stockwell Street, Fax:01206 575101
> Colchester, Essex, CO1 1HE, England Mob:07775 556535
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Doug Grimwade   [EMAIL PROTECTED]
Olive Systems Limited   Tel:01206 217961
The Old Exchange, 64 West Stockwell Street, Fax:01206 575101
Colchester, Essex, CO1 1HE, England Mob:07775 556535

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: using log4j in a web application

2001-05-13 Thread BillWorker 2i Development Team

Robert Burrell Donkin wrote:
> no.
> log4j's configuration is shared by the entire VM.
> take a look in the archives about where and when to configure.
> 
> - robert
> 

Yes, found out that it is shared by the VM. That was real nice. I am now
loading a servlet on start up to configure the log4j and accessing it
from all the other places I need.


-- 
BillWorker 2i Development Team,
Infocom Solutions Pvt. Ltd.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: using log4j in a web application

2001-05-13 Thread Robert Burrell Donkin

BillWorker 2i Development Team wrote:

> Hi!
>
> I have just started using log4j. I plan to use it in a web application.
> My question is do I have to create new instances and set the
> configuration each time I access it from different places in my web
> application? For example, I would access it from the jsp page, servlet,
> beans and other java classes.

no.
log4j's configuration is shared by the entire VM.
take a look in the archives about where and when to configure.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]