Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Giuseppe Madonna]

New logger and level elements are not fully 'compatible' with old category
and priority  (some attribute like class are now not supported), the order
of elements is changhed, there is no loggerFactory elements, etc. etc.

Anyone knows where can I find some documentation about differences in
log4j.dtd beetween version 1.2 and version 1.1?


Thanks in advance.


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

Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Ceki Gülcü]

Sub-classing of the Logger class is discouraged because it is a very
problematic feature.  Consequently, XML config scripts do not support
the class attribute in  element. However, your old
configuration scripts will continue to work since the 
element still has the "class" attribute.  Large code bases can
continue to use sub-classes of Category by changing a class name
(CategoryFactory -> LoggerFactory). If you have any problem with this
just shout.

A not  so casual developer  can still instruct  log4j to use  a custom
sub-class   of   Loggerby   programming   the   RepositorySelector
interface.  This  new  interface  is  much  more  robust  and  problem
free.

Log4j 1.2 is backward compatible with log4j 1.1 except for the
CategoryFactory -> LoggerFactory change. It also warns about features
that will be dropped in future releases. It prepares the terrain for
log4j 1.3 where Logger sub-classing will be generalized through the
RepositorySelector interface.

It might look like random changes to the user but it's all carefully
planned and in a way that is as backward compatible as possible.

At 09:28 30.05.2002 +0200, you wrote:
>New logger and level elements are not fully 'compatible' with old category
>and priority  (some attribute like class are now not supported), the order
>of elements is changhed, there is no loggerFactory elements, etc. etc.
>
>Anyone knows where can I find some documentation about differences in
>log4j.dtd beetween version 1.2 and version 1.1?
>
>
>Thanks in advance.

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Giuseppe Madonna]

First of all, thanks for RepositorySelector clue.
Just to clarify the sense of my message: it was not a critic, just a help
request! :-)
You know, I met log4j so long ago, and I found it very very useful for a
large range of problems.
So I think I'm not a 'casual developer' and I'm sure that releases are
carefully planned!
And it's true that upgrading to 1.2 consist in changing only one class name.
I'm writing a multi-purpose server that use log4j for auditing finality
(hence I found useful to create my own Category and Priority), so,
considering I'm in a early phase of develop,
I choose to switch to the newest version of log4j and embrace it in all its
improvements.
That's all.

However I wonder, to avoid Logger subclassing, why not make it final?
But it was just a thought...

Kind regards,
Giuseppe.

P.S. Sorry for my poor English!


- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Log4J Users List" <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 10:30 AM
Subject: Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2


>
> Sub-classing of the Logger class is discouraged because it is a very
> problematic feature.  Consequently, XML config scripts do not support
> the class attribute in  element. However, your old
> configuration scripts will continue to work since the 
> element still has the "class" attribute.  Large code bases can
> continue to use sub-classes of Category by changing a class name
> (CategoryFactory -> LoggerFactory). If you have any problem with this
> just shout.
>
> A not  so casual developer  can still instruct  log4j to use  a custom
> sub-class   of   Loggerby   programming   the   RepositorySelector
> interface.  This  new  interface  is  much  more  robust  and  problem
> free.
>
> Log4j 1.2 is backward compatible with log4j 1.1 except for the
> CategoryFactory -> LoggerFactory change. It also warns about features
> that will be dropped in future releases. It prepares the terrain for
> log4j 1.3 where Logger sub-classing will be generalized through the
> RepositorySelector interface.
>
> It might look like random changes to the user but it's all carefully
> planned and in a way that is as backward compatible as possible.
>
> At 09:28 30.05.2002 +0200, you wrote:
> >New logger and level elements are not fully 'compatible' with old
category
> >and priority  (some attribute like class are now not supported), the
order
> >of elements is changhed, there is no loggerFactory elements, etc. etc.
> >
> >Anyone knows where can I find some documentation about differences in
> >log4j.dtd beetween version 1.2 and version 1.1?
> >
> >
> >Thanks in advance.
>
> --
> Ceki
>
> SUICIDE BOMBING - A CRIME AGAINST HUMANITY
> Sign the petition: http://www.petitiononline.com/1234567b
> I am signatory number 22106. What is your number?
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

RE: Using Log4J in EJB server

[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:

For additional commands, e-mail:











> --
> To unsubscribe, e-mail:

Log4j and Tomcat apps

[Jacob Kjome]

I was reading the Log4j manual and it suggests that for each webapp, you 
should use a separate log4j jar file in each WEB-INF/lib to make sure that 
each log4j is in its own "log4j Universe".  However, this puts constraints 
on where I put my libraries that use log4j.  For instance, if I have log4j 
in WEB-INF/lib, I can't have libraries that use log4j in TOMCAT_HOME/lib 
because the libraries in the parent classloader won't find the Log4j 
libraries in the child classloader.  However, that is where I'd like to put 
some of my libraries since they are common to all my webapps.  In fact, 
Log4j is common to all my webapps so I'd like to put it in TOMCAT_HOME/lib 
as well.  However, this would cause conflicts becase Log4j would no longer 
be running in its own "Log4j Universe".

So, in a manner of speaking, my libraries are being held hostage in 
WEB-INF/lib because Log4j is designed in a way that it needs to live on 
it's own and not be shared by multiple apps at once.

Have I interpreted things wrong, or is this what was intended?  Is there 
anything I can do to keep my libraries from being "held hostage"?  Are 
there any tricks that I'm missing here?

Jake


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

RE: Log4j and Tomcat apps

[Shapira, Yoav]

Howdy,
I don't know the answer, but I wanted to say I'm very interested in this question as 
well. Mr. Gülcü or anyone else care to comment? ;)

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Jacob Kjome [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, May 30, 2002 8:52 AM
>To: [EMAIL PROTECTED]
>Subject: Log4j and Tomcat apps
>
>
>I was reading the Log4j manual and it suggests that for each webapp, you
>should use a separate log4j jar file in each WEB-INF/lib to make sure that
>each log4j is in its own "log4j Universe".  However, this puts constraints
>on where I put my libraries that use log4j.  For instance, if I have log4j
>in WEB-INF/lib, I can't have libraries that use log4j in TOMCAT_HOME/lib
>because the libraries in the parent classloader won't find the Log4j
>libraries in the child classloader.  However, that is where I'd like to put
>some of my libraries since they are common to all my webapps.  In fact,
>Log4j is common to all my webapps so I'd like to put it in TOMCAT_HOME/lib
>as well.  However, this would cause conflicts becase Log4j would no longer
>be running in its own "Log4j Universe".
>
>So, in a manner of speaking, my libraries are being held hostage in
>WEB-INF/lib because Log4j is designed in a way that it needs to live on
>it's own and not be shared by multiple apps at once.
>
>Have I interpreted things wrong, or is this what was intended?  Is there
>anything I can do to keep my libraries from being "held hostage"?  Are
>there any tricks that I'm missing here?
>
>Jake
>
>
>--
>To unsubscribe, e-mail:   [EMAIL PROTECTED]>
>For additional commands, e-mail: [EMAIL PROTECTED]>


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

Remove please

[David Thielen]

Hi;

I have sent remove messages twice and I keep getting e-mails. Any idea how
to get removed?

thanks - dave


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

Re: Log4j and Tomcat apps

[Scott Farquhar]

The reason that it should be in WEB-INF/lib & not int TOMCAT_HOME/lib is 
that log4j used to have problems loading the config file if you used the 
server library path.

This is because the server classloader cannot see anything in the 
application classloader.

If you are using a single configuration file for all apps, or if you are 
configuring log4j manually, then you should be fine using the 
TOMCAT_HOME/lib directory (someone correct me if I'm wrong - haven't 
looked at the log4j source recently).

Cheers,
Scott

Jacob Kjome wrote:
> 
> I was reading the Log4j manual and it suggests that for each webapp, you 
> should use a separate log4j jar file in each WEB-INF/lib to make sure 
> that each log4j is in its own "log4j Universe".  However, this puts 
> constraints on where I put my libraries that use log4j.  For instance, 
> if I have log4j in WEB-INF/lib, I can't have libraries that use log4j in 
> TOMCAT_HOME/lib because the libraries in the parent classloader won't 
> find the Log4j libraries in the child classloader.  However, that is 
> where I'd like to put some of my libraries since they are common to all 
> my webapps.  In fact, Log4j is common to all my webapps so I'd like to 
> put it in TOMCAT_HOME/lib as well.  However, this would cause conflicts 
> becase Log4j would no longer be running in its own "Log4j Universe".
> 
> So, in a manner of speaking, my libraries are being held hostage in 
> WEB-INF/lib because Log4j is designed in a way that it needs to live on 
> it's own and not be shared by multiple apps at once.
> 
> Have I interpreted things wrong, or is this what was intended?  Is there 
> anything I can do to keep my libraries from being "held hostage"?  Are 
> there any tricks that I'm missing here?
> 
> Jake
> 
> 
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


-- 
Scott Farquhar :: [EMAIL PROTECTED]

Atlassian :: http://www.atlassian.com
  Supporting YOUR J2EE World



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

minor bug in docfile PropertyConfigurator.html

[H . vanderLinden]

Hi,

I know this is a minor bug, but in the description of the "doConfigure"
method a  is missing so all subsequent info is in italics.

Bye,

Helma van der Linden
Medical Informatics
University Maastricht
The Netherlands
Tel: +31 43 3882235
Fax: +31 43 3884170
[EMAIL PROTECTED] 

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

RE: Wrapper Classes - duplication of log statements

[Rathod, Manoj (CAP, GEFA, Contractor)]

One solution that I suggest is, store all 5 logger instances in hashtable,
store this hashtable into session and every process that wants to log
information will first retreive the handle to the logger instance by passing
some unique parameter. 
The disadvantage of this method is that for every log:
1. You need to have seperate configuration parameters...
2. One logger instance will serve purpose of writing either debug, fatal, or
any other log type.

But the reason why its writing to all logger is because you have not created
seperate instances of logger...

Manoj Rathod
Patni Computers System.
Work *: (434) 845 0911 Ext: 4101
Home *: (434) 385 4113


-Original Message-
From: James Mitchell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 6:58 PM
To: Log4J Users List
Subject: RE: Wrapper Classes - duplication of log statements


sounds like your creating a new configuration instead of using your
singleton.

its happened to me. [DOH!!!]

James Mitchell

> -Original Message-
> From: Anand M S [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 2:36 PM
> To: Log4J Users List
> Subject: Wrapper Classes - duplication of log statements
>
>
>
>  Hi,
>  I have 5 loggers (Debug, error, all, info, warning), Im using
> my own wrapper classes to use log 4j, when I try to write to log
> file (separately for each logger), its writing to all loggers
> and duplicating the log statements
>
> Here is the example,
>
>
>
> DebugLogger.log(priority, Log statement), then it writes this
> log statement to DebugLogger more than once and to other loggers as well
>
>
>
> Am I missing any thing, please help me.
>
>
>
> Thanks,
>
> Anand
>
>
>
>
>
> -
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup


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

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

Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Ceki Gülcü]

At 11:48 30.05.2002 +0200, Giuseppe Madonna wrote:

>However I wonder, to avoid Logger subclassing, why not make it final?
>But it was just a thought...

Logger class is not final because Logger sub-classing allows very
important enhancements such as security or transparent logging domains.
Domains are a "secret" feature planned for log4j 1.3.

The important point to note is that these sub-classes do not change
the Logger interface, that is the set of methods available to the
user.  Sub-classing Logger by adding new logging methods is strongly
discouraged because code written for such loggers will simply not run
in environments where the enhanced Logger sub-classes are used. (I am
thinking of Application Servers and Servlet Containers.)

Does it make any sense?

>Kind regards,
>Giuseppe.


--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

RE: SocketAppender (was: console/file config)

[Klein, Scott @ TW]

I am starting to work with these as well...I have a simple example running
but there are some little 'tricks' --- like you get into an infinite loop if
everything is not set up properly because your SocketNodes start sending
their messages out to themselves (thats fun!).

Anyway, I got a zip file from the mail archives last night with some
'extension' classes that I have yet to get in depth with. since i don't want
to attach a zip to the list posting, if you would like a copy e-mail me
directly.


scott

-Original Message-
From: Sundararaman, Anand [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 9:19 PM
To: Log4J Users List
Subject: RE: SocketAppender (was: console/file config)


Hi Mark,
  Can you please give me one example on how to use the SocketNode class
on the server side.

Thanks
Anand

> -Original Message-
> From: Mark Womack [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 10:56 PM
> To:   'Log4J Users List'
> Subject:  RE: SocketAppender (was: console/file config)
> 
> Look at the SocketNode class.  You can use this class on the receiving end
> to read the logging events.
> 
> -Mark
> 
> > -Original Message-
> > From: Sundararaman, Anand [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 29, 2002 7:18 AM
> > To: Log4J Users List
> > Subject: RE: console/file config 
> > 
> > 
> > 
> > Hi,
> > I am new to Log4j. Please help me out. I am using 
> > SocketAppender class
> > to send a logging message to a port on another machine. Can 
> > anyone let me
> > know how to write my SocketServer to get the same message on 
> > the server
> > side.
> > 
> > It is Urgent.
> > 
> > Thanks in advance
> > Anand
> > WARNING: The information in this message is confidential and 
> > may be legally
> > privileged. It is intended solely for the addressee.  Access 
> > to this message
> > by anyone else is unauthorised.  If you are not the intended 
> > recipient, any
> > disclosure, copying, or distribution of the message, or any action or
> > omission taken by you in reliance on it, is prohibited and 
> > may be unlawful.
> > Please immediately contact the sender if you have received 
> > this message in
> > error. Thank you.- HCL Perot Systems
> > 
> > --
> > To unsubscribe, e-mail:   
> > 
> > For additional commands, e-mail: 
> > 
> > 
> 
> --
> To unsubscribe, e-mail:
> 
> For additional commands, e-mail:
> 
WARNING: The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee.  Access to this message
by anyone else is unauthorised.  If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message in
error. Thank you.- HCL Perot Systems

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

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

Re: minor bug in docfile PropertyConfigurator.html

[Ceki Gülcü]

Thanks!

At 15:32 30.05.2002 +0200, [EMAIL PROTECTED] wrote:
>Hi,
>
>I know this is a minor bug, but in the description of the "doConfigure"
>method a  is missing so all subsequent info is in italics.
>
>Bye,
>
>Helma van der Linden

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

Re: Remove please

[Ceki Gülcü]

reportedly, there were some problems with the mail servers at jakarta.
I don't know when it will be fixed.

At 07:13 30.05.2002 -0600, David Thielen wrote:
>Hi;
>
>I have sent remove messages twice and I keep getting e-mails. Any idea how
>to get removed?
>
>thanks - dave

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

RE: Using Log4J in EJB server

[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 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 

Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Giuseppe Madonna]

> >However I wonder, to avoid Logger subclassing, why not make it final?
> >But it was just a thought...
>
> Logger class is not final because Logger sub-classing allows very
> important enhancements such as security or transparent logging domains.
> Domains are a "secret" feature planned for log4j 1.3.
>
> The important point to note is that these sub-classes do not change
> the Logger interface, that is the set of methods available to the
> user.  Sub-classing Logger by adding new logging methods is strongly
> discouraged because code written for such loggers will simply not run
> in environments where the enhanced Logger sub-classes are used. (I am
> thinking of Application Servers and Servlet Containers.)
>
> Does it make any sense?

I'm missing the point.
Code will run fine anyway.
This is java, not C++ and (dynamic) linking is done at runtime, not at
compiletime.
If I extend from Logger class, e.g. MyLogger, code referring to MyLogger
methods will run fine
with log4j 1.999 version in which there will be a EnanchedLogger class
extending from Logger.
If you want to preserve public interface, you can (must) use java Interface
concept.
If you want to make new improvements and make it available to users, you can
(must) extend your old interface.
Application written for old interface are preserved and will runs fine:
backward compatibility is granted.
Who wants to use new enanchements will refer to new Interface.

Best regards,
Giuseppe.






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

Re: Log4j and Tomcat apps

[Ceki Gülcü]

Jake,

Very good question.

Log4j 1.2 introduced the concept of RepositorySelectors specifically
to deal with this problem. Unless the container does for you (which
Tomcat does not) you'd have to write your own RepositorySelector.
Writing a selector is trivial if you control the application
context... which you don't.

I am including a chapter on this subject in my log4j book. Remind me
to send you a free copy when it comes out.

At 07:51 30.05.2002 -0500, Jacob Kjome wrote:

>I was reading the Log4j manual and it suggests that for each webapp, you 
>should use a separate log4j jar file in each WEB-INF/lib to make sure that 
>each log4j is in its own "log4j Universe".  However, this puts constraints 
>on where I put my libraries that use log4j.  For instance, if I have log4j 
>in WEB-INF/lib, I can't have libraries that use log4j in TOMCAT_HOME/lib 
>because the libraries in the parent classloader won't find the Log4j 
>libraries in the child classloader.  However, that is where I'd like to 
>put some of my libraries since they are common to all my webapps.  In 
>fact, Log4j is common to all my webapps so I'd like to put it in 
>TOMCAT_HOME/lib as well.  However, this would cause conflicts becase Log4j 
>would no longer be running in its own "Log4j Universe".
>
>So, in a manner of speaking, my libraries are being held hostage in 
>WEB-INF/lib because Log4j is designed in a way that it needs to live on 
>it's own and not be shared by multiple apps at once.
>
>Have I interpreted things wrong, or is this what was intended?  Is there 
>anything I can do to keep my libraries from being "held hostage"?  Are 
>there any tricks that I'm missing here?
>
>Jake

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

SocketHubAppender

[Frissaer, Jeroen]

Hi Mark,

>From what I read it seems not very simple to use the SocketHubAppender.
You wrote that Lumbermill probably will need some modification in order to
work with the socketHubAppender.  Is this also the case for Chainsaw or LF5?

How did you use the socketHubAppender?

Regards
Jeroen


You wrote:

>Try calling the activateOptions() method on your SocketAppender in your
>start method.  It only connects after that call is made, I think.
>
>To use SocketHubAppender with Lumbermill, yes, I think the Lumbermill code
>would need modification.
>
>-Mark
>
> -Original Message-
> From: Jesse Vitrone [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 16, 2002 11:02 AM
> To: Log4J Users List
> Subject: RE: adding / removing appenders dynamically
> 
> 
> Does this mean that I can't do what I'm looking to do with 
> w/o modifying the
> Lumbermill code?  I can't just remove or add a socket appender?
> 
> Thanks,
>   Jesse
> 
> -Original Message-
> From: Mark Womack [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 16, 2002 1:53 PM
> To: 'Log4J Users List'
> Subject: RE: adding / removing appenders dynamically
> 
> 
> Jesse,
> 
> You might want to look at the SocketHubAppender that is part 
> of the log4j
> 1.2 release.  Instead of actively seeking a target, it waits 
> for clients to
> connect to it.  Multiple clients can be supported.  But you 
> will need to
> modify the Lumbermill code to connect to the server you want. 
>  Plans are
> being made to add this functionality to Chainsaw and/or 
> LogFactor5, both of
> which are part of the log4j (I know chainsaw is included in 
> v1.2, I don't
> know about LF5).
> 
> let me know if you have any questions.
> -Mark
> 
> > -Original Message-
> > From: Jesse Vitrone [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 16, 2002 10:43 AM
> > To: [EMAIL PROTECTED]
> > Subject: adding / removing appenders dynamically
> >
> >
> >
> > Lumbermill with Log4J looks great, but I don't want the
> > socket connector for
> > Lumbermill to be running all the time, I'd like to be able to
> > hit a servlet
> > at sets up the appender, then have Lumbermill connect to the
> > server and
> > start showing the logging info.
> >
> > I thought it would be easy to do, but I can't seem to get it
> > working right.
> > My code looks like this:
> >
> > public static final String LUMBERMILL_APPENDER_NAME = "LogServer";
> >
> > public static boolean isLumbermillSocketAppenderRunning() {
> > Logger rootLog = Logger.getRootLogger();
> > Appender app = rootLog.getAppender(LUMBERMILL_APPENDER_NAME);
> > return (app != null);
> > }
> >
> > public static void startLumbermillSocketAppender () {
> > Logger rootLog = Logger.getRootLogger();
> > SocketAppender app = new SocketAppender("localhost", 4445);
> > app.setName(LUMBERMILL_APPENDER_NAME);
> > rootLog.addAppender(app);
> > }
> >
> > public static void stopLumbermillSocketAppender () {
> > Logger rootLog = Logger.getRootLogger();
> > rootLog.removeAppender(LUMBERMILL_APPENDER_NAME);
> > }
> >
> > the method to check if there is an appender with the name
> > LogServer works
> > well, but the start and stop don't seem to do anything.
> >
> > Even when I start up the socket appender in the 
> log4j.properties (and
> > lumbermill works properly), I can't get it to stop with my
> > stop method. Any
> > ideas?
> >
> > Thanks in advance,
> > Jesse Vitrone

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

Re: Differences in XMLConfiguration beetween ver. 1.1 and 1.2

[Ceki Gülcü]

If MyLogger introduces a new method that your code uses, then your
code is tied to MyLogger.  It is *expecting* to use a MyLogger
instance. Your code won't work with any other Logger class.

At the same time, when you write

   Logger l = Logger.getLogger()

you don't actually know the type that is returned. It may well be an
instance of EnhancedLogger with a totally different logging
behavior. You just don't know and don't have to care as long as you
strictly adhere to the methods available in the Logger class.

At 17:41 30.05.2002 +0200, Giuseppe Madonna wrote:

> > >However I wonder, to avoid Logger subclassing, why not make it final?
> > >But it was just a thought...
> >
> > Logger class is not final because Logger sub-classing allows very
> > important enhancements such as security or transparent logging domains.
> > Domains are a "secret" feature planned for log4j 1.3.
> >
> > The important point to note is that these sub-classes do not change
> > the Logger interface, that is the set of methods available to the
> > user.  Sub-classing Logger by adding new logging methods is strongly
> > discouraged because code written for such loggers will simply not run
> > in environments where the enhanced Logger sub-classes are used. (I am
> > thinking of Application Servers and Servlet Containers.)
> >
> > Does it make any sense?
>
>I'm missing the point.
>Code will run fine anyway.
>This is java, not C++ and (dynamic) linking is done at runtime, not at
>compiletime.
>If I extend from Logger class, e.g. MyLogger, code referring to MyLogger
>methods will run fine
>with log4j 1.999 version in which there will be a EnanchedLogger class
>extending from Logger.
>If you want to preserve public interface, you can (must) use java Interface
>concept.
>If you want to make new improvements and make it available to users, you can
>(must) extend your old interface.
>Application written for old interface are preserved and will runs fine:
>backward compatibility is granted.
>Who wants to use new enanchements will refer to new Interface.
>
>Best regards,
>Giuseppe.
>
>
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

RE: SocketAppender (was: console/file config)

[Mark Womack]

There is also the SimpleSocketServer class which might serve as a better
example than SocketNode itself.

-Mark

> -Original Message-
> From: Klein, Scott @ TW [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 7:51 AM
> To: 'Log4J Users List'
> Subject: RE: SocketAppender (was: console/file config)
> 
> 
> I am starting to work with these as well...I have a simple 
> example running
> but there are some little 'tricks' --- like you get into an 
> infinite loop if
> everything is not set up properly because your SocketNodes 
> start sending
> their messages out to themselves (thats fun!).
> 
> Anyway, I got a zip file from the mail archives last night with some
> 'extension' classes that I have yet to get in depth with. 
> since i don't want
> to attach a zip to the list posting, if you would like a copy 
> e-mail me
> directly.
> 
> 
> scott
> 
> -Original Message-
> From: Sundararaman, Anand [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 9:19 PM
> To: Log4J Users List
> Subject: RE: SocketAppender (was: console/file config)
> 
> 
> Hi Mark,
>   Can you please give me one example on how to use the 
> SocketNode class
> on the server side.
> 
> Thanks
> Anand
> 
> > -Original Message-
> > From:   Mark Womack [SMTP:[EMAIL PROTECTED]]
> > Sent:   Wednesday, May 29, 2002 10:56 PM
> > To: 'Log4J Users List'
> > Subject:RE: SocketAppender (was: console/file config)
> > 
> > Look at the SocketNode class.  You can use this class on 
> the receiving end
> > to read the logging events.
> > 
> > -Mark
> > 
> > > -Original Message-
> > > From: Sundararaman, Anand [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, May 29, 2002 7:18 AM
> > > To: Log4J Users List
> > > Subject: RE: console/file config 
> > > 
> > > 
> > > 
> > > Hi,
> > > I am new to Log4j. Please help me out. I am using 
> > > SocketAppender class
> > > to send a logging message to a port on another machine. Can 
> > > anyone let me
> > > know how to write my SocketServer to get the same message on 
> > > the server
> > > side.
> > > 
> > > It is Urgent.
> > > 
> > > Thanks in advance
> > > Anand
> > > WARNING: The information in this message is confidential and 
> > > may be legally
> > > privileged. It is intended solely for the addressee.  Access 
> > > to this message
> > > by anyone else is unauthorised.  If you are not the intended 
> > > recipient, any
> > > disclosure, copying, or distribution of the message, or 
> any action or
> > > omission taken by you in reliance on it, is prohibited and 
> > > may be unlawful.
> > > Please immediately contact the sender if you have received 
> > > this message in
> > > error. Thank you.- HCL Perot Systems
> > > 
> > > --
> > > To unsubscribe, e-mail:   
> > > 
> > > For additional commands, e-mail: 
> > > 
> > > 
> > 
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> WARNING: The information in this message is confidential and 
> may be legally
> privileged. It is intended solely for the addressee.  Access 
> to this message
> by anyone else is unauthorised.  If you are not the intended 
> recipient, any
> disclosure, copying, or distribution of the message, or any action or
> omission taken by you in reliance on it, is prohibited and 
> may be unlawful.
> Please immediately contact the sender if you have received 
> this message in
> error. Thank you.- HCL Perot Systems
> 
> --
> 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: SocketHubAppender

[Mark Womack]

Jeroen,

Yes, unfortunately, this is the case right now.  All of the client tools are
geared to supporting SocketAppender (actually I have not looked at LF5
closely enough yet, but I assume it is the case).  I have a copy of Chainsaw
that I modified to support connecting to a SocketHubAppender.  I have not
put these changes into log4j cvs because it is a very complete hack to the
existing source code.

There has been discussion on the dev list about extending Chainsaw/LF5 to
support multiple "source types" that would be configured as they required.
But this work has not yet commenced as we are waiting for
guidance/leadership from Oliver and Brad on this subject.  I plan to help in
the design and implementation so that SocketHubAppender will be (officailly)
supported in a future version.

-Mark

> -Original Message-
> From: Frissaer, Jeroen [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 30, 2002 8:58 AM
> To: Log4j Mailing List (E-mail)
> Subject: SocketHubAppender
> 
> 
> Hi Mark,
> 
> From what I read it seems not very simple to use the 
> SocketHubAppender.
> You wrote that Lumbermill probably will need some 
> modification in order to
> work with the socketHubAppender.  Is this also the case for 
> Chainsaw or LF5?
> 
> How did you use the socketHubAppender?
> 
> Regards
> Jeroen
> 
> 
> You wrote:
> 
> >Try calling the activateOptions() method on your 
> SocketAppender in your
> >start method.  It only connects after that call is made, I think.
> >
> >To use SocketHubAppender with Lumbermill, yes, I think the 
> Lumbermill code
> >would need modification.
> >
> >-Mark
> >
> > -Original Message-
> > From: Jesse Vitrone [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 16, 2002 11:02 AM
> > To: Log4J Users List
> > Subject: RE: adding / removing appenders dynamically
> > 
> > 
> > Does this mean that I can't do what I'm looking to do with 
> > w/o modifying the
> > Lumbermill code?  I can't just remove or add a socket appender?
> > 
> > Thanks,
> >   Jesse
> > 
> > -Original Message-
> > From: Mark Womack [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 16, 2002 1:53 PM
> > To: 'Log4J Users List'
> > Subject: RE: adding / removing appenders dynamically
> > 
> > 
> > Jesse,
> > 
> > You might want to look at the SocketHubAppender that is part 
> > of the log4j
> > 1.2 release.  Instead of actively seeking a target, it waits 
> > for clients to
> > connect to it.  Multiple clients can be supported.  But you 
> > will need to
> > modify the Lumbermill code to connect to the server you want. 
> >  Plans are
> > being made to add this functionality to Chainsaw and/or 
> > LogFactor5, both of
> > which are part of the log4j (I know chainsaw is included in 
> > v1.2, I don't
> > know about LF5).
> > 
> > let me know if you have any questions.
> > -Mark
> > 
> > > -Original Message-
> > > From: Jesse Vitrone [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 16, 2002 10:43 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: adding / removing appenders dynamically
> > >
> > >
> > >
> > > Lumbermill with Log4J looks great, but I don't want the
> > > socket connector for
> > > Lumbermill to be running all the time, I'd like to be able to
> > > hit a servlet
> > > at sets up the appender, then have Lumbermill connect to the
> > > server and
> > > start showing the logging info.
> > >
> > > I thought it would be easy to do, but I can't seem to get it
> > > working right.
> > > My code looks like this:
> > >
> > > public static final String LUMBERMILL_APPENDER_NAME = "LogServer";
> > >
> > > public static boolean isLumbermillSocketAppenderRunning() {
> > > Logger rootLog = Logger.getRootLogger();
> > > Appender app = rootLog.getAppender(LUMBERMILL_APPENDER_NAME);
> > > return (app != null);
> > > }
> > >
> > > public static void startLumbermillSocketAppender () {
> > > Logger rootLog = Logger.getRootLogger();
> > > SocketAppender app = new SocketAppender("localhost", 4445);
> > > app.setName(LUMBERMILL_APPENDER_NAME);
> > > rootLog.addAppender(app);
> > > }
> > >
> > > public static void stopLumbermillSocketAppender () {
> > > Logger rootLog = Logger.getRootLogger();
> > > rootLog.removeAppender(LUMBERMILL_APPENDER_NAME);
> > > }
> > >
> > > the method to check if there is an appender with the name
> > > LogServer works
> > > well, but the start and stop don't seem to do anything.
> > >
> > > Even when I start up the socket appender in the 
> > log4j.properties (and
> > > lumbermill works properly), I can't get it to stop with my
> > > stop method. Any
> > > ideas?
> > >
> > > Thanks in advance,
> > > Jesse Vitrone
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

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

Re[2]: Log4j and Tomcat apps

[Jacob Kjome]

Hello Ceki,

So, being somewhat new with Log4j, are you saying that given the fact
that Tomcat does not do RepositorySelectors for me and also doesn't
give me control of the context, that it would be pretty difficult to
figure out how to write a custom RepositorySelector?  Are there any
examples that exist anywhere on this while I wait for my free copy of
your upcoming book (thank you for offering this, BTW. When do you
expect it to come out?)?

Thanks,

Jake

Thursday, May 30, 2002, 10:45:24 AM, you wrote:


CG> Jake,

CG> Very good question.

CG> Log4j 1.2 introduced the concept of RepositorySelectors specifically
CG> to deal with this problem. Unless the container does for you (which
CG> Tomcat does not) you'd have to write your own RepositorySelector.
CG> Writing a selector is trivial if you control the application
CG> context... which you don't.

CG> I am including a chapter on this subject in my log4j book. Remind me
CG> to send you a free copy when it comes out.

CG> At 07:51 30.05.2002 -0500, Jacob Kjome wrote:

>>I was reading the Log4j manual and it suggests that for each webapp, you 
>>should use a separate log4j jar file in each WEB-INF/lib to make sure that 
>>each log4j is in its own "log4j Universe".  However, this puts constraints 
>>on where I put my libraries that use log4j.  For instance, if I have log4j 
>>in WEB-INF/lib, I can't have libraries that use log4j in TOMCAT_HOME/lib 
>>because the libraries in the parent classloader won't find the Log4j 
>>libraries in the child classloader.  However, that is where I'd like to 
>>put some of my libraries since they are common to all my webapps.  In 
>>fact, Log4j is common to all my webapps so I'd like to put it in 
>>TOMCAT_HOME/lib as well.  However, this would cause conflicts becase Log4j 
>>would no longer be running in its own "Log4j Universe".
>>
>>So, in a manner of speaking, my libraries are being held hostage in 
>>WEB-INF/lib because Log4j is designed in a way that it needs to live on 
>>it's own and not be shared by multiple apps at once.
>>
>>Have I interpreted things wrong, or is this what was intended?  Is there 
>>anything I can do to keep my libraries from being "held hostage"?  Are 
>>there any tricks that I'm missing here?
>>
>>Jake

CG> --
CG> Ceki

CG> SUICIDE BOMBING - A CRIME AGAINST HUMANITY
CG> Sign the petition: http://www.petitiononline.com/1234567b
CG> I am signatory number 22106. What is your number?


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



-- 
Best regards,
 Jacobmailto:[EMAIL PROTECTED]


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

java.io.FileNotFoundException: /LOG/temp.log (The system cannot find the path specified)

[Rajan Annadurai]

Hi ,

 

RollingFileAppender peAppender = new
RollingFileAppender(defaultPattern,"/LOG/temp.log",true);

 

The above line throws java.io.FileNotFoundException if the directory is
not present. How do you make log4j create the directory if it is not
present?

 

Thanx,

Rajan

RE: java.io.FileNotFoundException: /LOG/temp.log (The system cannot find the path specified)

[Thomas Tuft Muller]

You have to code it yourself.

--

Thomas

| -Original Message-
| From: Rajan Annadurai [mailto:[EMAIL PROTECTED]]
| Sent: 30 May 2002 19:08
| To: [EMAIL PROTECTED]
| Subject: java.io.FileNotFoundException: /LOG/temp.log (The system cannot
| find the path specified)
| 
| 
| Hi ,
| 
|  
| 
| RollingFileAppender peAppender = new
| RollingFileAppender(defaultPattern,"/LOG/temp.log",true);
| 
|  
| 
| The above line throws java.io.FileNotFoundException if the directory is
| not present. How do you make log4j create the directory if it is not
| present?
| 
|  
| 
| Thanx,
| 
| Rajan
| 
| 


*
Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights reserved. 
The information supplied in this email should be treated in confidence.
No liability whatsoever is accepted for any loss or damage 
suffered as a result of accessing this message or any attachments.


This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com


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

Extending appenders, classpath issues

[Andrew Tumpach]

Hi all,

I've created a couple custom appenders, but when deployed with my app on
WebSphere, I realized I have a classpath issue:  Log4J is on the JVM classpath,
but the app is not.  Therefore, Log4J cannot see these custom appenders.

Our admins (for good reasons) may be hesitant to allow applications to be on
the JVM classpath.  Log4J can't be moved to application classpaths instead of
JVM because it is used by EJBs in some projects.

Does anyone else know of alternate solutions?

Thanks,
Andrew


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

RE: Extending appenders, classpath issues

[Matt Cox]

check out:
http://www.theserverside.com/resources/articles/ClassLoading/article.html It
speaks about j2ee 1.3 class loading scheme and the implementations provided
by weblogic 6.1 SP2, WebSphere 4.0, and HP-AS 8.  In it there is discussion
of adding  ejb dependant jars into the jar manifest class-path.

Hope this helps,
Matt

-Original Message-
From: Andrew Tumpach [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 2:55 PM
To: [EMAIL PROTECTED]
Subject: Extending appenders, classpath issues


Hi all,

I've created a couple custom appenders, but when deployed with my app on
WebSphere, I realized I have a classpath issue:  Log4J is on the JVM
classpath,
but the app is not.  Therefore, Log4J cannot see these custom appenders.

Our admins (for good reasons) may be hesitant to allow applications to be on
the JVM classpath.  Log4J can't be moved to application classpaths instead
of
JVM because it is used by EJBs in some projects.

Does anyone else know of alternate solutions?

Thanks,
Andrew


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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

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

Re: Extending appenders, classpath issues

[Rafael Alvarez]

Hello Andrew,

Check if websphere has a propietary method of specifiying additions to
the  classpath for each componet. That way you can put log4j in all
classpath without bothering the sysadmins.

Thursday, May 30, 2002, 2:55:27 PM, you wrote:

AT> Hi all,

AT> I've created a couple custom appenders, but when deployed with my app on
AT> WebSphere, I realized I have a classpath issue:  Log4J is on the JVM classpath,
AT> but the app is not.  Therefore, Log4J cannot see these custom appenders.

Rafael


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

Re: Extending appenders, classpath issues

[Ceki Gülcü]

Try log4j version 1.2.3. Depending on how WL sets the Thread
Context Loader you might not need to do anything. This is 1.2.3 only.

Let us know if it works.

At 11:55 30.05.2002 -0700, Andrew Tumpach wrote:
>Hi all,
>
>I've created a couple custom appenders, but when deployed with my app on
>WebSphere, I realized I have a classpath issue:  Log4J is on the JVM 
>classpath,
>but the app is not.  Therefore, Log4J cannot see these custom appenders.
>
>Our admins (for good reasons) may be hesitant to allow applications to be on
>the JVM classpath.  Log4J can't be moved to application classpaths instead of
>JVM because it is used by EJBs in some projects.
>
>Does anyone else know of alternate solutions?
>
>Thanks,
>Andrew

--
Ceki

SUICIDE BOMBING - A CRIME AGAINST HUMANITY
Sign the petition: http://www.petitiononline.com/1234567b
I am signatory number 22106. What is your number?


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

LogManager

[Anand M S]

HI all,
 I'm trying to use wrapper classes for logging, I have 5 different loggers, when I try 
to log, Logger.log(Priority, msg); then the message  is written to all log files, just 
before I'm printing logger name, but LogManager.getCurrentLoggers() returns all five 
loggers, what could be the possible reason, what is the significance of log manager?

Thanks,
Anand



-
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

RE: LogManager

[Klein, Scott @ TW]

can you put up your config file?

i think you are describing the same issue i had - it has to do with the
"appender additivity rule" perhaps.

-Original Message-
From: Anand M S [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 3:37 PM
To: [EMAIL PROTECTED]
Subject: LogManager



HI all,
 I'm trying to use wrapper classes for logging, I have 5 different loggers,
when I try to log, Logger.log(Priority, msg); then the message  is written
to all log files, just before I'm printing logger name, but
LogManager.getCurrentLoggers() returns all five loggers, what could be the
possible reason, what is the significance of log manager?

Thanks,
Anand



-
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

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

Re: Log4j and Tomcat apps

[Scott Farquhar]

Ceki,

Wouldn't this be another good example of a case where allowing your own 
repository selector is a good idea?

I discussed this before:

http://marc.theaimsgroup.com/?t=10148577083&r=1&w=2

I suggest that until 1.3 is released (which *should* deal with this 
problem by having separate logging domains?), being able to specify your 
own repository selector is the only valid work around.

Thoughts?

Cheers,
Scott

Ceki Gülcü wrote:
> 
> Jake,
> 
> Very good question.
> 
> Log4j 1.2 introduced the concept of RepositorySelectors specifically
> to deal with this problem. Unless the container does for you (which
> Tomcat does not) you'd have to write your own RepositorySelector.
> Writing a selector is trivial if you control the application
> context... which you don't.
> 
> I am including a chapter on this subject in my log4j book. Remind me
> to send you a free copy when it comes out.
> 
> At 07:51 30.05.2002 -0500, Jacob Kjome wrote:
> 
>> I was reading the Log4j manual and it suggests that for each webapp, 
>> you should use a separate log4j jar file in each WEB-INF/lib to make 
>> sure that each log4j is in its own "log4j Universe".  However, this 
>> puts constraints on where I put my libraries that use log4j.  For 
>> instance, if I have log4j in WEB-INF/lib, I can't have libraries that 
>> use log4j in TOMCAT_HOME/lib because the libraries in the parent 
>> classloader won't find the Log4j libraries in the child classloader.  
>> However, that is where I'd like to put some of my libraries since they 
>> are common to all my webapps.  In fact, Log4j is common to all my 
>> webapps so I'd like to put it in TOMCAT_HOME/lib as well.  However, 
>> this would cause conflicts becase Log4j would no longer be running in 
>> its own "Log4j Universe".
>>
>> So, in a manner of speaking, my libraries are being held hostage in 
>> WEB-INF/lib because Log4j is designed in a way that it needs to live 
>> on it's own and not be shared by multiple apps at once.
>>
>> Have I interpreted things wrong, or is this what was intended?  Is 
>> there anything I can do to keep my libraries from being "held 
>> hostage"?  Are there any tricks that I'm missing here?
>>
>> Jake
> 
> 
> -- 
> Ceki
> 
> SUICIDE BOMBING - A CRIME AGAINST HUMANITY
> Sign the petition: http://www.petitiononline.com/1234567b
> I am signatory number 22106. What is your number?
> 
> 
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


-- 
Scott Farquhar :: [EMAIL PROTECTED]

Atlassian :: http://www.atlassian.com
  Supporting YOUR J2EE World



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