hi, however replacing the following line
SOAPEnvelope env = Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true); with SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement(); causes some test case failures. Also we found this info message. May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify INFO: Verification successful for URI "#id-613" May 19, 2010 6:13:13 PM org.apache.xml.security.signature.Reference verify INFO: Verification successful for URI "#My ticket Id" thanks, Amila. On Wed, May 19, 2010 at 5:23 PM, Amila Suriarachchi < [email protected]> wrote: > hi, > > We have started looking into rampart performance issues using the bench > mark provided by Denis. > > We did some testing using the current axis2 and rampart trunks with the > this[1] performance enhancement. > In this case for small messages both cxf and Axis2 shows similar > performance values while cxf shows better performance for larger messages. > > By looking at the rampart code I found these lines. > > SOAPEnvelope env = > Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true); > > if(dotDebug){ > t2 = System.currentTimeMillis(); > } > > //Convert back to llom since the inflow cannot use DOOM > msgCtx.setEnvelope(env); > Axis2Util.useDOOM(false); > > This shows it again builds OM elements which apparently invalidate the use > of DOOM. I think the whole point of > DOOM is to use it as a AXIOM as well. > > this is documented in rampart developer guide as well. > > "When Rampart is engaged and configured, the incoming SOAP messages are > converted to DOOM. Since DOOM implements the DOM interface it is possible > for WSS4J to process messages. After performing the security validations, > before flushing the message down the message inflow, the DOOM SOAP message > is converted back to OM. At the outgoing flow, the message is converted to > DOOM and then the security functions are performed using WSS4J." > > Thoughts? have I miss something? > > thanks, > Amila. > > [1] > http://blog.rampartfaq.com/2010/05/how-to-cache-crypto-objects-in-rampart.html > > > On Tue, May 4, 2010 at 4:47 PM, Andreas Veithen <[email protected] > > wrote: > >> On Mon, May 3, 2010 at 17:19, Sanka Samaranayake <[email protected]> >> wrote: >> > On Sun, May 2, 2010 at 11:37 PM, Andreas Veithen >> > <[email protected]> wrote: >> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <[email protected]> >> wrote: >> >>> Yes, I think it'd make much more sense to base a build-on-demand >> document >> >>> model on the DOM API than to try to modify all the WSS4J and related >> code to >> >>> use Axiom. Especially since Axiom is a mess and has had performance >> issues >> >>> from the beginning (including using way too much memory as the model >> is >> >>> expanded). >> >> >> >> Each of the two approaches (porting WSS4J to Axiom / building a new >> >> optimized Axiom+DOM implementation) have their pros and cons and I >> >> think there is enough room for the two. They could even be >> >> complementary provided that the new Axiom+DOM implementation has a >> >> lower memory footprint and better performance. >> >> >> >>> As a radical suggestion, how about just implementing a build-on-demand >> DOM >> >>> subset suitable for use by WSS4J and other tools? This wouldn't need >> to >> >>> support all the DOM operations (including those using NodeList). >> >> >> >> That part is actually almost ready [1] (with more than just a subset >> >> suitable for WSS4J). However, to work with Axis2 we have no other >> >> choice than to support the Axiom API as well, at least the object >> >> model part of it (while getting rid of what you called the "mess"). >> >> >> >> [1] http://code.google.com/p/ddom/ >> > >> > Just for curiosity, have you done any performance comparison with your >> > implementation with any other implementation ? >> >> Not yet. BTW, do you know of any existing (performance) test suite >> that tests WS-Security processing in isolation, i.e. without the need >> for a full SOAP stack (my project is ready for integration with WSS4J, >> but far from being ready to support Axis2)? >> >> > Sanka >> > >> > >> >> >> >>> Daniel Kulp wrote: >> >>>> >> >>>> The "normal" way to traverse a DOM doesn't use the NodeList thing. >> The >> >>>> NodeList stuff isn't even threadsafe in Xerces. >> >>> >> >>> Actually, *no* access operations are threadsafe in Xerces. As far as >> I'm >> >>> concerned that's a really bad design for general purpose use, >> ironically >> >>> going back to the deferred node expansion feature that Xerces has on >> by >> >>> default. It's always irked me that I have to use a synchronization >> lock >> >>> around read-only operations with a (Xerces) DOM. >> >>> >> >>> That said, any form of build-on-demand document model is probably not >> going >> >>> to be threadsafe. But for our purposes in using it with web services >> there's >> >>> not much need for threadsafety. >> >>> >> >>> - Dennis >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> > >> > >> > -- >> > Sanka Samaranayake >> > >> > http://sankas.blogspot.com/ >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
