Bug 40880

Summary: Ability to override DocumentBuilderFactory.newInstance in XMLCipher
Product: Security - Now in JIRA Reporter: Davanum Srinivas <dims>
Component: EncryptionAssignee: XML Security Developers Mailing List <security-dev>
Status: NEW ---    
Severity: enhancement    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: other   
URL: http://issues.apache.org/jira/browse/AXIS2-1570
Attachments: Services API approach to fix Bug 40880

Description Davanum Srinivas 2006-11-02 12:51:04 UTC
Hi Team,

We have a showstopper in Axis2/WSS4J/Rampart:

We have our own DOM3 Implementation based on AXIOM and we need to be able to
specify that when a new document gets created in XMLCipher. After a lot of
analysis, the simplest way seems to add a new method that can be overriden by
wss4j. I've checked in a fix here:

Please kindly ok this fix for inclusion in the pending release.

Comment 1 Ruchith Fernando 2006-11-03 05:07:13 UTC
Hi Dims,

IMHO http://svn.apache.org/viewvc?view=rev&rev=470407 will not help since
parseFragment() method is inside Serializer which is a private class. :-(

How ever I tried a different approach using the Services API according to the
JAR specification. Will attach a patch. I was able to successfully run
org.apache.rampart.RampartTest in Axis2 with these changes in my IDE. This
approach does not require us to change the way we use XML-Security at all.

Please review and send your comments.

Comment 2 Ruchith Fernando 2006-11-03 05:10:36 UTC
Created attachment 19077 [details]
Services API approach to fix Bug 40880

Patch mentioned here :
Comment 3 Davanum Srinivas 2006-11-03 05:13:39 UTC
Please don't use sun.misc.Service. Let's leave the current code as-is.

Comment 4 Raul Benito 2006-11-04 03:42:24 UTC
(In reply to comment #2)
> Created an attachment (id=19077) [edit]
> Services API approach to fix Bug 40880
> Patch mentioned here :
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40880#c1

I like the patch idea even we have a TODO to get rid of all the DBF.
We could think of applying it(or any derivate) after 1.4 release.

Perhaps it can be even simpler. And let the registration phase go by Init
methods, instead of providers.

What do you all think?
Comment 5 Scott Cantor 2006-11-04 13:05:13 UTC
I'm a little confused by what you're trying to fix, and I'm very concerned about
any non-JAXP technique that would be used override the DOM implementation. There
are lots of software packages out there, and people expect JAXP to be used as
Sun defines it to specify the DOM classes to use, or any other XML classes for
that matter.

As it is, we have to do ugly things with endorsement because of bugs in things
like Xerces when it comes to overriding functionality according to the JAXP
system properties. I wouldn't want xmlsec to invent its own parser override

If I'm misunderstanding the problem here, sorry for interjecting.
Comment 6 Davanum Srinivas 2006-11-04 13:29:00 UTC

Please review this fix. There is absolutely no change in functionality to
xml-sec. A small block of code was refactored into a protected method. That's it!. 

If you are interested more in the problem we are facing with WSS4J/Rampart, i
can explain that off this bug list. That discussion could be on wss4j-dev or

Comment 7 Scott Cantor 2006-11-04 13:49:17 UTC
I was reacting more to the other proposed patch (using sun.misc is totally
unacceptable) and the last comment about Init methods and such.

Your original patch is a different animal.