commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl
Date Sun, 05 Jun 2005 00:56:49 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34661>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34661





------- Additional Comments From b_stansberry@hotmail.com  2005-06-05 02:56 -------
(In reply to comment #27)
> (In reply to comment #26)
> 
> On related matters, I would prefer not to take the approach:
>  * try context
>  * try classloader of the LogFactoryImpl.
> 
> I think it would be better to start at the context classloader and walk up the
> classloader inheritance tree until reaching the classloader that loaded the
> LogFactoryImpl. I've been playing with various ways of achieving this, but it
> isn't easy when you also need to treat exceptions as fatal or recoverable along
> the way. Opinions?
(In reply to comment #27)
> (In reply to comment #26)
>
> On related matters, I would prefer not to take the approach:
>  * try context
>  * try classloader of the LogFactoryImpl.
> 
> I think it would be better to start at the context classloader and walk up the
> classloader inheritance tree until reaching the classloader that loaded the
> LogFactoryImpl. I've been playing with various ways of achieving this, but it
> isn't easy when you also need to treat exceptions as fatal or recoverable along
> the way. Opinions?

I'm not sure there is a situation where trying _any_ other classloader will work
better.  I think there are four possible relationships between the thead context
classsloader (hereafter called TCCL) and LogFactoryImpl's classloader (hereafter
called LFICL).

1) TCCL is a child of LFICL.

In this case, no Log adapter class defined by any intermediate classloader
between TCCL and LFICL will be compatible with LFI.  Log adapter must be defined
by LFICL or a parent of LFICL.

No logging library class defined by any intermediate classloader between TCCL
and LFICL will be compatible with any compatible Log adapter.  Logging adapter
must be defined by the log adapter's classloader or a parent of it.

Therefore, no class defined by any intermediate classloader between TCCL and
LFICL will be useful.  Falling back to discovery using LFICL is the most
efficient next step if TCCL fails.

2) TCCL is a parent of LFICL.

In this situation, the only reason discovery using the TCCL would have failed is
if LFICL or an intermediate loader between it and TCCL uses child-first loading
and loaded a different version of Log directly.

It is possible to walk _down_ the classloader hierarchy from TCCL to LFICL,
trying to find a classloader that works, but in the end you'll get the same
result as if you'd just tried LFICL.  So, again falling back to discovery using
LFICL is the most efficient next step if TCCL fails.

3) TCCL is LFICL.

Not much we can do here ;)

4) TCCL is a sibling or cousin of LFICL.

The only other classloader that could possibly work is a classloader that is a
common parent of both TCCL and LFICL.  But, classes loaded by such a classloader
will only be compatible if there is no intermediate loader between it and LFICL
that uses child-first loading and can load a different version of Log directly.
 Trying to find such a "common-parent" classloader is possible, but in the end
you'll get the same result as if you'd just tried LFICL.  So, again falling back
to discovery using LFICL is the most efficient next step if TCCL fails.


I believe most of the above is outside the scope of what you'd mentioned, but
thought it might be useful to cover all the cases.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message