On Wed, May 19, 2010 at 6:36 PM, Amila Suriarachchi
wrote:
> hi,
>
> however replacing the following line
>
> SOAPEnvelope env =
> Axis2Util.getSOAPEnvelopeFromDOMDocument(rmd.getDocument(), true);
>
> with
>
> SOAPEnvelope env = (SOAPEnvelope)rmd.getDocument().getDocumentElement();
>
> causes som
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).
>> >>
>>
ith 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 curi
gt;>
>> 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 c
On Tue, May 4, 2010 at 11:21, Dennis Sosnoski wrote:
> Andreas Veithen wrote:
>>
>> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski wrote:
>>
>>>
>>> ...
>>>
>>> The nice thing about using a slightly-hacked and simplified DOM is that
>>> everything would be automatic - as it is with Axiom
On Tue, May 4, 2010 at 03:31, Daniel Kulp wrote:
> On Monday 03 May 2010 3:20:36 am Dennis Sosnoski wrote:
>> Whoops, meant to have this in my first response...
>>
>> Andreas Veithen wrote:
>> > Each of the two approaches (porting WSS4J to Axiom / building a new
>> > optimized Axiom+DOM implementa
Andreas Veithen wrote:
On Tue, May 4, 2010 at 04:05, Dennis Sosnoski wrote:
...
The nice thing about using a slightly-hacked and simplified DOM is that
everything would be automatic - as it is with Axiom now, but with
considerably less memory and processor overhead (because this appr
On Tue, May 4, 2010 at 04:05, Dennis Sosnoski wrote:
> Daniel Kulp wrote:
>>
>> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>> ...
>>
>>>
>>> From what I've seen CXF always builds the DOM representation of the
>>> entire message and passes it to WSS4J anytime WS-Security is configure
Daniel Kulp wrote:
On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
...
From what I've seen CXF always builds the DOM representation of the
entire message and passes it to WSS4J anytime WS-Security is configured,
just as Axis2 does (though Dan did add a check to disable response
me
e 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
implement
Just a note on Axiom based implementation of Rampart. As Ruchith have
pointed out the implementation is fairly supports the majority of use cases.
Obviously, it may need refinements, but a working implementation of XML-C14N
to SOAP security is there in this. An earlier version of Axiom based C14N i
Andreas Veithen wrote:
On Mon, May 3, 2010 at 07:02, Dennis Sosnoski wrote:
...
So rather than an incremental build-on-demand model, I think an approach
which just flipped DOM on or off at the message level would work just as
well for web services. On the inbound side, if a SOAP Header is p
On Mon, May 3, 2010 at 10:19, Amila Suriarachchi
wrote:
> Is (or was) there any reason to Axiom to come up with an new API rather than
> using DOM API?
I guess that one of the goals was also to provide an API that is more
convenient than DOM.
> I was thinking that Dom does not support differed b
On Mon, May 3, 2010 at 07:02, Dennis Sosnoski wrote:
> Andreas Veithen wrote:
>>
>> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski wrote:
>>
>>>
>>> ...
>>>
>>
>> Each of the two approaches (porting WSS4J to Axiom / building a new
>> optimized Axiom+DOM implementation) have their pros and cons and
Is (or was) there any reason to Axiom to come up with an new API rather than
using DOM API?
I was thinking that Dom does not support differed building and that seems to
be wrong.
There are some axis2 specific methods to get under line xml stream etc...
But they would have added by
extending the DO
Whoops, meant to have this in my first response...
Andreas Veithen wrote:
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
Andreas Veithen wrote:
On Sat, May 1, 2010 at 09:12, Dennis Sosnoski wrote:
...
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
complementa
On Sat, May 1, 2010 at 09:12, Dennis Sosnoski 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 be
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
I think it goes deeper than that. When I checked just the time spent in
the Rampart/WSS4J code it didn't account for all the overhead. It looks
to me like there are some stream to String or stream to OM conversions
going on even outside of the Rampart handlers.
- Dennis
Ruchith Fernando wro
On Fri, Apr 30, 2010 at 3:53 AM, Andreas Veithen
wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> wrote:
> > This overhead is mainly due to OM<->DOM conversion that was
> > unavoidable because we used WSS4J (which uses Apache XML-Sec) which is
> > based on DOM.
> >
> > This following ef
On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen
wrote:
> On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
> wrote:
>> This overhead is mainly due to OM<->DOM conversion that was
>> unavoidable because we used WSS4J (which uses Apache XML-Sec) which is
>> based on DOM.
>>
>> This following effort
On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando
wrote:
> This overhead is mainly due to OM<->DOM conversion that was
> unavoidable because we used WSS4J (which uses Apache XML-Sec) which is
> based on DOM.
>
> This following effort by Saliya et al. is a project where they tried
> to implement thos
As I have observed both Axis2 (adb, jaxbri) and CXF gives equal performance
(without security) which slightly varies with the performance bench mark
being used. And also both of them provides well enough performance for any
business application.
But this problem is with the rampart as Ruchith has
This overhead is mainly due to OM<->DOM conversion that was
unavoidable because we used WSS4J (which uses Apache XML-Sec) which is
based on DOM.
This following effort by Saliya et al. is a project where they tried
to implement those base libraries based on OM:
http://wssecforaxis2.blogspot.com/
T
Perhaps we may want to do some performance tuning[1] before the
release of Axis2 version 1.6
Sanka
[1]
http://www.ibm.com/developerworks/webservices/library/j-jws14/index.html?ca=drs
-
To unsubscribe, e-mail: java-dev-unsubscr.
26 matches
Mail list logo
