DO NOT REPLY [Bug 47002] junitreport: expose classpath of internal XSLTProcess task

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=47002





--- Comment #1 from Martin von Gagern <Ma...@gmx.net>  2009-04-09 02:27:52 PST ---
Created an attachment (id=23470)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23470)
Expose classpath and factory

This patch creates the nested XSLTProcess at creation of the
AggregateTransformer, not upon execution of the transformation. This way it is
much easier to simply wrap parts of the interface I'd like to expose, like the
new <classpath> and <factory> nested elements, but also the existing <param>
elements.

I haven't called XSLTProcess.init(), as the previous code didn't do that
either. I don't fully understand the difference between init() and a
constructor, but it might be a good thing to init the task somewhere.

The approach I chose is something like a whitelist delegation: the XSLTProcess
is a private member, and only selected methods of its interface are wrapped and
thus exposed to be configured. As an alternative, one could do something like a
blacklist delegation by deriving a class from XSLTProcess and forbidding access
to certain settings by ovverriding the corresponding methods and throwing
exceptions therein. In that case, one might even turn the class derived from
XSLTProcess into a nested <xslt> element, which would be probably much clearer,
as it would be configured in the same way that a top-level <xslt> task is. I
didn't choose this approach in my patch for now, but if you prefer it, I can
implement that as well.

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