Hi Team, We have a showstopper in Axis2/WSS4J/Rampart: http://issues.apache.org/jira/browse/AXIS2-1570 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: http://svn.apache.org/viewvc?view=rev&rev=470407 Please kindly ok this fix for inclusion in the pending release. thanks, dims
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. Thanks, Ruchith
Created attachment 19077 [details] Services API approach to fix Bug 40880 Patch mentioned here : http://issues.apache.org/bugzilla/show_bug.cgi?id=40880#c1
Please don't use sun.misc.Service. Let's leave the current code as-is. thanks, dims
(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?
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 mechanism. If I'm misunderstanding the problem here, sorry for interjecting.
Scott, 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 axis-dev. Thanks, dims
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.