[rt-pmc] [CQ 4086] logback classic Version: 0.9.18 (PB CQ3651)

[emo-ip-team@xxxxxxxxxxx]

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4086





--- Comment #3 from Glyn Normington <gnormington@xxxxxxxxxx>  2010-05-11 12:07:40 ---
(In reply to comment #2)
> (In reply to comment #0)
> > Description:    The Virgo medic component depends on logback classic. Although
> > the
> > source code of logback classic is not modified by Virgo, a Virgo aspect is
> > woven
> > into logback classic to enable Virgo\'s in-memory logging function. For this
> > reason, this CQ is flagged as modifying the code. Note that it is not
> > appropriate or necessary to contribute the aspect to the LogBack project as the
> > aspect is adding orthogonal function.
> 
> I'm not sure this has come up before.  I would approve the cq based on the
> approval of the piggyback CQ already approved but I am not sure what EPL
> requires as far as weaving classes to add functionality vs. patching the source
> and rebuilding the classes to include new functionality (orthogonal or not). 
> The end result seems to be the same.  We will ship class files that are
> modified from the original to add some bit of function.
> 
> To me it seems like the changes we make to the class files would need to be
> contributed back and it makes no difference what mechanism we used to modify
> the actual class files.  Am I missing something? 
> 

It wouldn't be appropriate to contribute back the aspects that weave in
functionality to LogBack because that function is Virgo-specific and the
weaving is done in quite a general way so as to migrate relatively easily as
LogBack evolves. I think the best analogy is to subclassing a 3rd party class
and adding "before" and "after" calls around the calls to the super method.

In general, AOP adds function to a class in a non-intrusive way, so the
"changes" don't need to be contributed back. The base function is unaware of
being "advised" and it should stay that way to avoid conflating the base
function with the advice.

Perhaps another angle is to focus on the source, which is unmodified. In
practical terms, we can only really contribute source changes back.

Perhaps it would also help to consider a more obvious example. If we use an
aspect to weave method entry/exit logging calls into a class, then there is no
reason to contribute those logging calls back to the original base code.
Indeed, we might want to vary the aspect over time or use multiple aspects with
different function to advise the same base code. Also, the owners of the base
code could well consider the logging code an unnecessary overhead and clutter,
which is why AOP is often an elegant solution to logging.

In this case, we are adding in-memory logging on top of LogBack, which is
similar in philosophy. The owners of LogBack would probably regard this as
Virgo-specific and inefficient for the general use case of LogBack.

I hope that helps?


-- 
Configure CQmail: http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the CQ.