You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Cory Updyke <cu...@part.net> on 2001/08/24 21:09:04 UTC
re: Revised Log4j interfaces
I have a couple of questions about an implementation detail in the
"Revised log4j interfaces" proposal.
I am just finishing up an implementation that tries to solve the problem
discussed in the proposal. It does so by providing a way to store the
current thread name and requested category name when a category is
created (using the getInstance(name, factory) method), which in turn
allows all classes within this thread to simply call getInstance() or
getInstance(nameToAppendToOriginalCatgoryName) rather than having to be
configured for each application. This functionality is performed in a
subclass of the Category class. Also included in this subclass is a
CategoryKey, that can be retrieved by calling getCategoryKey. The
CategoryKey quite simply holds the name of the thread that created the
Category. This key should then be retrieved when the Category is first
created (by the getInstance(name, CategoryFactory) method) and used by
different threads to reference the original Category, using a
getInstance(CategoryKey) method (i.e. allow all classes in used by new
thread to also use the same Category). An entirely new Category, based
on the original Category, could be created with a
getInstance(nameToAppendToOriginalCatgoryName, CategoryKey) method.
My questions are: At what level will applicationContext be assigned
(thread I am assuming)?... If so, how will multithreaded applications be
able to associate different threads with the same Category (for servlets,
a Category might be first created in the init() method).
As I have been working with this implementation I began to think how much
of a role the NDC might be able to play in this type of thing. Maybe it
could be fully or partially responsible for handling this.
Cory Updyke
cupdyke@part.net
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
re: Revised Log4j interfaces
Posted by Cory Updyke <cu...@part.net>.
I guess what I am talking about is not neccesarily a problem, but here is
the situation I am
talking about.
There are two servlets that I want to log have log to a file. Servlet1
should use a category called com.whatever.servlet1. Servlet2 should a
category called com.whatever.servlet2. Servlet1 and Servlet2 instantiate
and use the same class (say Class1). When Class1 is being used by
Servlet1 it should use Servlet1's category (com.whatever.servlet1) and
when it is being used by Servlet2 it should use Servlet2's category
(com.whatever.servlet2). It should do so without having to know anything
about which Servlet is using it. In other words, Class1 logs messages
using the Category returned by either a getInstance() or
getInstance("Class1") method. The most simple solution (in my mind) is
to subclass Category and provide some logic to assocate a Category with a
thread. If we do this, when Servlet1 and Servlet2 create their Category
for the first time we will keep track of the thread that created it and
the name of the category that was created. And when Class1 calls
getInstance(), we will use the current thread to see if there is any
category already created. If there is, we will look up the Category
using the stored category name.
Although this solves the Class1 issue, there is a problem that arises
here is when the init() method is used to create the Category the first
time. Let me give you an example.
With the above solution, when the category is first created, the name of
the thread invoking init() will used to store the category name. Because
Servlets can be multithreaded we can not be sure that when the service()
method is invoked, it will be invoked in the same thread (we could
specify that the Servlet is SingleThreaded, but we would take a
performance hit... and performance hits are no fun). The other thing (in
my mind) that could be done, is to create a key that can be used each
time a new thread wishes to create a new category. The code would look
something like this...
public
void init(...) {
...
Category originalCategory = SubClassedCategory.getInstance(name,
factory);
this.categoryKey = originalCategory.getCategoryKey();
...
}
public
void service(...) {
...
Category originalCategory =
SubClassesCategory.getInstance(this.categoryKey);
...
}
Applied to our Servlet1/Servlet2 scenario, when Servlet1.thread0 used the
factory
to create the originalCategory, its CategoryKey was created with that
information. This allows us to turn around and request a Category using
the key, knowing when we do that 2 things will happen.
- The original category name will be used to lookup the Category.
- The current thread will be also be associated with this category so
that Class1 can just call getInstance().
...
Hopefully, this is more clear.
My original question was, is the applicationContext that is referred to
in the proposal
this type of applicationContext. If so, if there is no CategoryKey, how
would one reference
the originally created Category.
Cory Updyke
cupdyke@part.net
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 8/24/01, 3:00:33 PM, "Ceki Gülcü" <cg...@qos.ch> wrote regarding re:
Revised Log4j interfaces:
> Cory,
> I don't understand. What is the problem you are trying to solve? Can you
please describe the problem? Regards, Ceki
> At 19:09 24.08.2001 +0000, Cory Updyke wrote:
> >I have a couple of questions about an implementation detail in the
> >"Revised log4j interfaces" proposal.
> >I am just finishing up an implementation that tries to solve the problem
> >discussed in the proposal. It does so by providing a way to store the
> >current thread name and requested category name when a category is
> >created (using the getInstance(name, factory) method), which in turn
> >allows all classes within this thread to simply call getInstance() or
> >getInstance(nameToAppendToOriginalCatgoryName) rather than having to be
> >configured for each application. This functionality is performed in a
> >subclass of the Category class. Also included in this subclass is a
> >CategoryKey, that can be retrieved by calling getCategoryKey. The
> >CategoryKey quite simply holds the name of the thread that created the
> >Category. This key should then be retrieved when the Category is first
> >created (by the getInstance(name, CategoryFactory) method) and used by
> >different threads to reference the original Category, using a
> >getInstance(CategoryKey) method (i.e. allow all classes in used by new
> >thread to also use the same Category). An entirely new Category, based
> >on the original Category, could be created with a
> >getInstance(nameToAppendToOriginalCatgoryName, CategoryKey) method.
> >My questions are: At what level will applicationContext be assigned
> >(thread I am assuming)?... If so, how will multithreaded applications be
> >able to associate different threads with the same Category (for
servlets,
> >a Category might be first created in the init() method).
> >As I have been working with this implementation I began to think how
much
> >of a role the NDC might be able to play in this type of thing. Maybe it
> >could be fully or partially responsible for handling this.
> >Cory Updyke
> >cupdyke@part.net
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> --
> Ceki Gülcü - http://qos.ch
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
re: Revised Log4j interfaces
Posted by Ceki Gülcü <cg...@qos.ch>.
Cory,
I don't understand. What is the problem you are trying to solve? Can you please describe the problem? Regards, Ceki
At 19:09 24.08.2001 +0000, Cory Updyke wrote:
>I have a couple of questions about an implementation detail in the
>"Revised log4j interfaces" proposal.
>I am just finishing up an implementation that tries to solve the problem
>discussed in the proposal. It does so by providing a way to store the
>current thread name and requested category name when a category is
>created (using the getInstance(name, factory) method), which in turn
>allows all classes within this thread to simply call getInstance() or
>getInstance(nameToAppendToOriginalCatgoryName) rather than having to be
>configured for each application. This functionality is performed in a
>subclass of the Category class. Also included in this subclass is a
>CategoryKey, that can be retrieved by calling getCategoryKey. The
>CategoryKey quite simply holds the name of the thread that created the
>Category. This key should then be retrieved when the Category is first
>created (by the getInstance(name, CategoryFactory) method) and used by
>different threads to reference the original Category, using a
>getInstance(CategoryKey) method (i.e. allow all classes in used by new
>thread to also use the same Category). An entirely new Category, based
>on the original Category, could be created with a
>getInstance(nameToAppendToOriginalCatgoryName, CategoryKey) method.
>My questions are: At what level will applicationContext be assigned
>(thread I am assuming)?... If so, how will multithreaded applications be
>able to associate different threads with the same Category (for servlets,
>a Category might be first created in the init() method).
>As I have been working with this implementation I began to think how much
>of a role the NDC might be able to play in this type of thing. Maybe it
>could be fully or partially responsible for handling this.
>Cory Updyke
>cupdyke@part.net
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org