Hi Ganapathi,
in EJB it's okay to use static varables if they are final.
So, I think I will do it this way:
public class A
{
private static final Category cat =
Category.getInstance(A.class.getName());
public void MyMethode()
{
cat.info("...");
...
}
}
If your beans are distributed over more than one virtual machine (EJB
container cluster) you will have more than one Category hierarchies (one for
each JVM) but since thay are all created the same way (with the same
property file, hopefully) they are all equal, (equal() not ==).
Bye,
Martin.
> -----Original Message-----
> From: Ganapathi Raman [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, September 10, 2001 6:57 AM
> To: LOG4J Users Mailing List
> Subject: RE: Logging in a Multi threaded environment - EJB-Container
>
> Hi Martin.
>
> I also share ur view when it comes to logging in an EJB...but I have a
> basic doubt there also
>
> EJB- spec does not encourage us to have static class level objects /
> variables...so inside EJBs how do we get a Category object...in other
> programs i get a static Category object with a unique name passed as a
> parameter. But what in case of an EJB? I feel that u shud not create a
> static class level instance of the category object?? any suggestions /
> comments..
>
> I have a thought but am not sure whether this will work...since log4j
> says that u get the same reference of the Category object when u call the
> getCategory() method from anywhere in the code, can we safely put the
> Category object as a non-static object inside the class?
>
> Need help reg this concept esp when using log4j in EJBs..is there any
> article available for going thru reg log4j in EJBs??
>
> Thanks in Advace,
>
> Regards,
>
> Ganapathi.
>
>
>
> "Diehl_Martin,_Köln" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> how does this interact with the transparent thread handling in an
> EJB-Container.
> In such a situation, when the container handles the threads that use
> my
> classes, do I have to fear dead lock situations?
>
> I think the only case where there could be a problem is when we call
> any
> bean method inside the logging-call, which could be the case if the
> message
> itself performs such a call to be evaluated.
> E.g:
> logger.info("Withdrawing " + amount + " $ from account " +
> anotherBean.getAccountName(id));
>
> The EJB-Spec prohibits 'the use of thread synchronization
> primitives', but
> explains that this is due to the fact that the container may
> distribute my
> beans over more than one address spaces. In that case we wouldn't
> have a
> problem since we would als have more than one category hierarchies.
>
> Any comment on that?
>
>
> > -----Original M! essage-----
> > From: Jon Skeet [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, September 06, 2001 3:01 PM
> > To: LOG44J Users Mailing List
> > Subject: RE: Logging in a Multi threaded environment
> >
> > > Currently we are considering log4j for our application
> > > logger and so I have tried out the basic features of log4j ....
> >
> > > But i have a doubt when i try to log in a multithreaded
> > > environment...DOES log4j PROVIDE A SYNCHRONIZED LOGGING
> MECHANISM??
> >
> > Yes - or rather, it depends on the appender in question, but any
> > appender inheriting from AppenderSkeleton (which most will)
> synchronize
> > there.
> >
> > > say a thread A is logging some message in a class at
> > > the same time when another thread of the same class is
> > > also busy logging!! In such an event my HO is that since
> > > the Category object that they share is a static one w! ith
> > > the same name, messages from both the threads would go to
> > > the same Category object..am i right?
> >
> > Yes.
> >
> > > Also, consider a situation wherein my thread A has a big
> > > message and has called its cat.info(message)...similarly
> > > thread B had called its cat.info(message) but has only a
> > > smaller message. In such a case, which will appear first,
> > > say in my file if i use a FileAppender, message of thread A or
> B???
> >
> > Whichever gets to the appender.doAppend() first.
> >
> > Jon
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]! e.org
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> _____
>
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
> Messenger <http://rd.yahoo.com/mail_us/tag/?http://im.yahoo.com/>.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
