You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Fred Dushin <fa...@apache.org> on 2008/04/15 01:50:42 UTC
WSS-54
Hi Ruchith,
Could I ask you to take a look at Colm's patch for WSS-54?
https://issues.apache.org/jira/browse/WSS-54
I'm +1 on the change, but I see you had some important comments in the
Jira trail, and before committing the change (or asking you to), I'd
like to make sure you're in agreement with it.
Thanks!
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Wiki page for WSS4j 2.0 ideas [was: AW: 2.0 ideas]
Posted by "Dittmann, Werner (NSN - DE/Muenich)" <we...@nsn.com>.
All,
just to start the actions I've created some entries into the
WS-FX Wiki (inside the Apache Wiki farm). Here the link:
http://wiki.apache.org/ws/FrontPage/WsFx
At the bootom of the page you see the entires to two pagee. I've
populated these pages using input from Fred and George. Feel free
to add and discuss.
You need to register to be able to edit the pages (but this is
straightforward). You may also enable notification in case pages
changes. I haven't checked support for RSS :-)
Regards,
Werner
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: 2.0 ideas [was: AW: WSS-54]
Posted by Fred Dushin <fa...@apache.org>.
I'm partial to the callback approach, myself.
I've been trying to think about a callback mechanism on the processing
side, as well. I see we've gotten a few requests for being able to
track the data that's been signed or encrypted, and I think using
callbacks gives the user a lot more flexibility than by providing data
structures, after an event has occurred.
I definitely think we could do some cool stuff along those lines in 2.0.
-Fred
On Apr 15, 2008, at 11:48 AM, George Stanchev wrote:
> Hi,
>
> I've thrown this around for a while now - there is even a JIRA
> opened on
> the issue - RAMPART-15 on the rampart side,
> though it is likely not rampart issue but a combined wss4j/rampart.
>
> Here is the use case - I have build a WS-Trust client and in some
> cases
> I need to be
> able to refer from the body of the message to security tokens
> genarated
> by wss4j (for
> example X509 certs in signature, username tokens, etc). The particular
> case I have is
> the wst:OnBehalfOf element which can either contain the token or
> have a
> wss:SecurityTokenReference pointing to the wsu:Id of the token. I
> think
> wss4j should
> provide a way to either use pre-generated pool of wsu:Ids for
> identifying wss nodes
> or has a callback may be that allows the client to supply wsu:Id at
> process time.
>
> If we can agree on architectural approach, I can do some work on it.
>
> Best Regards,
> George
>
> -----Original Message-----
> From: Fred Dushin [mailto:fadushin@apache.org]
> Sent: Tuesday, April 15, 2008 8:36 AM
> To: Dittmann, Werner (NSN - DE/Muenich)
> Cc: wss4j-dev
> Subject: 2.0 ideas [was: AW: WSS-54]
>
> On Apr 15, 2008, at 6:35 AM, Dittmann, Werner (NSN - DE/Muenich)
> wrote:
>> For the planned V2.0 :
>> shall we start some e-mail thread (or using the wiki?) to gather some
>> ideas and proposals what to address in V2.0?
>
> Definitely a good idea -- email is fine by me, but if folks prefer the
> wiki, that's fine by me, as well (as long as it supports RSS feeds :)
>
> To seed the discussion, some things to consider in the near term might
> be:
>
> * mavenize the build/test/deploy/release cycle
> * checkstyle/pmd the source tree
> * Split the build into a few components -- core, handler, and axis
> come to mind
> * Port to 1.5 (using 1.5 language features -- this might be a problem
> for some users)
> * OSGI bundling
>
> Perhaps more controversial, and longer term:
>
> * Consider enhancements to the APIs
> * Support JAX-B generated types from WS-Security schema
> * Study feasibility of signature/encr without need for DOM (stax?)
> * Use WS-SecurityPolicy as a configuration API?
>
> I'm sure there are lots more things we could do, but I'd like to start
> out with a relatively small and achievable set.
>
> -Fred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply e-mail and destroy all copies of
> the original message.
> **********************************************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: 2.0 ideas [was: AW: WSS-54]
Posted by George Stanchev <Gs...@serena.com>.
Hi,
I've thrown this around for a while now - there is even a JIRA opened on
the issue - RAMPART-15 on the rampart side,
though it is likely not rampart issue but a combined wss4j/rampart.
Here is the use case - I have build a WS-Trust client and in some cases
I need to be
able to refer from the body of the message to security tokens genarated
by wss4j (for
example X509 certs in signature, username tokens, etc). The particular
case I have is
the wst:OnBehalfOf element which can either contain the token or have a
wss:SecurityTokenReference pointing to the wsu:Id of the token. I think
wss4j should
provide a way to either use pre-generated pool of wsu:Ids for
identifying wss nodes
or has a callback may be that allows the client to supply wsu:Id at
process time.
If we can agree on architectural approach, I can do some work on it.
Best Regards,
George
-----Original Message-----
From: Fred Dushin [mailto:fadushin@apache.org]
Sent: Tuesday, April 15, 2008 8:36 AM
To: Dittmann, Werner (NSN - DE/Muenich)
Cc: wss4j-dev
Subject: 2.0 ideas [was: AW: WSS-54]
On Apr 15, 2008, at 6:35 AM, Dittmann, Werner (NSN - DE/Muenich) wrote:
> For the planned V2.0 :
> shall we start some e-mail thread (or using the wiki?) to gather some
> ideas and proposals what to address in V2.0?
Definitely a good idea -- email is fine by me, but if folks prefer the
wiki, that's fine by me, as well (as long as it supports RSS feeds :)
To seed the discussion, some things to consider in the near term might
be:
* mavenize the build/test/deploy/release cycle
* checkstyle/pmd the source tree
* Split the build into a few components -- core, handler, and axis
come to mind
* Port to 1.5 (using 1.5 language features -- this might be a problem
for some users)
* OSGI bundling
Perhaps more controversial, and longer term:
* Consider enhancements to the APIs
* Support JAX-B generated types from WS-Security schema
* Study feasibility of signature/encr without need for DOM (stax?)
* Use WS-SecurityPolicy as a configuration API?
I'm sure there are lots more things we could do, but I'd like to start
out with a relatively small and achievable set.
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: 2.0 ideas [was: AW: WSS-54]
Posted by "O hEigeartaigh, Colm" <Co...@iona.com>.
For the 2.0 release, we should "officially" support the 1.1 version of
the UsernameToken, Message Protection and X.509 specifications.
I've already done a good bit of this for the 1.5.4 release, here's the
current status of things in a nutshell:
- X.509 1.1: Currently supported.
- Message Protection 1.1: Signature confirmation is possible atm, but a
small amount of work is required to tidy it up, test etc. Our support
for encrypted SOAP headers looks partial and is untested.
- UsernameToken 1.1: Key derivation is partially supported, we don't
have any code for properly processing/caching nonces etc.
On top of this work, there's properly supporting and testing 1.1
functionality through the WSHandler architecture.
Colm.
-----Original Message-----
From: Fred Dushin [mailto:fadushin@apache.org]
Sent: 15 April 2008 15:36
To: Dittmann, Werner (NSN - DE/Muenich)
Cc: wss4j-dev
Subject: 2.0 ideas [was: AW: WSS-54]
On Apr 15, 2008, at 6:35 AM, Dittmann, Werner (NSN - DE/Muenich) wrote:
> For the planned V2.0 :
> shall we start some e-mail thread (or using the wiki?)
> to gather some ideas and proposals what to address in V2.0?
Definitely a good idea -- email is fine by me, but if folks prefer the
wiki, that's fine by me, as well (as long as it supports RSS feeds :)
To seed the discussion, some things to consider in the near term might
be:
* mavenize the build/test/deploy/release cycle
* checkstyle/pmd the source tree
* Split the build into a few components -- core, handler, and axis
come to mind
* Port to 1.5 (using 1.5 language features -- this might be a
problem for some users)
* OSGI bundling
Perhaps more controversial, and longer term:
* Consider enhancements to the APIs
* Support JAX-B generated types from WS-Security schema
* Study feasibility of signature/encr without need for DOM (stax?)
* Use WS-SecurityPolicy as a configuration API?
I'm sure there are lots more things we could do, but I'd like to start
out with a relatively small and achievable set.
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
2.0 ideas [was: AW: WSS-54]
Posted by Fred Dushin <fa...@apache.org>.
On Apr 15, 2008, at 6:35 AM, Dittmann, Werner (NSN - DE/Muenich) wrote:
> For the planned V2.0 :
> shall we start some e-mail thread (or using the wiki?)
> to gather some ideas and proposals what to address in V2.0?
Definitely a good idea -- email is fine by me, but if folks prefer the
wiki, that's fine by me, as well (as long as it supports RSS feeds :)
To seed the discussion, some things to consider in the near term might
be:
* mavenize the build/test/deploy/release cycle
* checkstyle/pmd the source tree
* Split the build into a few components -- core, handler, and axis
come to mind
* Port to 1.5 (using 1.5 language features -- this might be a
problem for some users)
* OSGI bundling
Perhaps more controversial, and longer term:
* Consider enhancements to the APIs
* Support JAX-B generated types from WS-Security schema
* Study feasibility of signature/encr without need for DOM (stax?)
* Use WS-SecurityPolicy as a configuration API?
I'm sure there are lots more things we could do, but I'd like to start
out with a relatively small and achievable set.
-Fred
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSS-54
Posted by Ruchith Fernando <ru...@gmail.com>.
+1
Revised patch looks good. IMHO delegating authentication to the
callback handler in the plain text case essential.
Thanks,
Ruchith
On Tue, Apr 15, 2008 at 4:05 PM, Dittmann, Werner (NSN - DE/Muenich)
<we...@nsn.com> wrote:
> Colm,
>
> the revised patch seems ok to me.
>
> For the planned V2.0 :
> shall we start some e-mail thread (or using the wiki?)
> to gather some ideas and proposals what to address in V2.0?
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: ext O hEigeartaigh, Colm [mailto:Colm.OhEigeartaigh@iona.com]
> > Gesendet: Dienstag, 15. April 2008 12:09
> > An: Dittmann, Werner (NSN - DE/Muenich); ext Fred Dushin; wss4j-dev
> > Betreff: RE: WSS-54
>
>
> >
> > Hi Werner,
> >
> > Please consider the revised patch for WSS-54. I think that
> > for the 2.0 timeframe we need to revisit the way things are
> > handled in UsernameTokenProcessor, as delegating
> > authentication to the password callback handler is not a good
> > solution.
> >
> > In the meantime, the revised patch preserves the old
> > functionality, along with some extra bits and pieces, mainly
> > the addition of an extra variable to control whether password
> > types other than plaintext or digested are allowed.
> >
> > Thanks,
> >
> > Colm.
> >
> > -----Original Message-----
> > From: Dittmann, Werner (NSN - DE/Muenich)
> > [mailto:werner.dittmann@nsn.com]
> > Sent: 15 April 2008 08:13
> > To: ext Fred Dushin; wss4j-dev
> > Subject: AW: WSS-54
> >
> > Fred, Ruchith, all,
> >
> > first of all - thanks to Fred to take actions on all the open
> > issues :-)
> >
> > As for WSS-54: in the orginal implementation the
> > "handleUsernameToken()"
> > checked the both types of passwords. After some discussions
> > on the mailing
> > list (back in 2004, WSS4J's stoneage :-) ) we modified the
> > behaviour to
> > check only the hashed passwords. The main reason was (as far
> > as I can remember):
> > - only for hashed passwords the WS-Security specs define how
> > the validate
> > it (using nonce, created time etc)
> > - the plain password is just "plain" text - no validation is
> > specified, thus
> > we decided not to implement a check into the handler but to
> > leave the
> > check to ther server application. You may refer to the
> > follwoing archived
> > e-mail discussion:
> >
> > http://mail-archives.apache.org/mod_mbox/ws-fx-dev/200409.mbox
> > /%3C4135FF52.70908@mitre.org%3E
> >
> > IMHO implementing this patch brakes a behaviour that WSS4J
> > provides since long
> > and thus may break applications.
> >
> > Regards,
> > Werner
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: ext Fred Dushin [mailto:fadushin@apache.org]
> > > Gesendet: Dienstag, 15. April 2008 01:51
> > > An: wss4j-dev
> > > Betreff: WSS-54
> > >
> > > Hi Ruchith,
> > >
> > > Could I ask you to take a look at Colm's patch for WSS-54?
> > >
> > > https://issues.apache.org/jira/browse/WSS-54
> > >
> > > I'm +1 on the change, but I see you had some important
> > comments in the
> > > Jira trail, and before committing the change (or asking you to), I'd
> > > like to make sure you're in agreement with it.
> > >
> > > Thanks!
> > > -Fred
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road,
> > Dublin 4, Ireland
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
http://blog.ruchith.org
http://wso2.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
AW: WSS-54
Posted by "Dittmann, Werner (NSN - DE/Muenich)" <we...@nsn.com>.
Colm,
the revised patch seems ok to me.
For the planned V2.0 :
shall we start some e-mail thread (or using the wiki?)
to gather some ideas and proposals what to address in V2.0?
Regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: ext O hEigeartaigh, Colm [mailto:Colm.OhEigeartaigh@iona.com]
> Gesendet: Dienstag, 15. April 2008 12:09
> An: Dittmann, Werner (NSN - DE/Muenich); ext Fred Dushin; wss4j-dev
> Betreff: RE: WSS-54
>
> Hi Werner,
>
> Please consider the revised patch for WSS-54. I think that
> for the 2.0 timeframe we need to revisit the way things are
> handled in UsernameTokenProcessor, as delegating
> authentication to the password callback handler is not a good
> solution.
>
> In the meantime, the revised patch preserves the old
> functionality, along with some extra bits and pieces, mainly
> the addition of an extra variable to control whether password
> types other than plaintext or digested are allowed.
>
> Thanks,
>
> Colm.
>
> -----Original Message-----
> From: Dittmann, Werner (NSN - DE/Muenich)
> [mailto:werner.dittmann@nsn.com]
> Sent: 15 April 2008 08:13
> To: ext Fred Dushin; wss4j-dev
> Subject: AW: WSS-54
>
> Fred, Ruchith, all,
>
> first of all - thanks to Fred to take actions on all the open
> issues :-)
>
> As for WSS-54: in the orginal implementation the
> "handleUsernameToken()"
> checked the both types of passwords. After some discussions
> on the mailing
> list (back in 2004, WSS4J's stoneage :-) ) we modified the
> behaviour to
> check only the hashed passwords. The main reason was (as far
> as I can remember):
> - only for hashed passwords the WS-Security specs define how
> the validate
> it (using nonce, created time etc)
> - the plain password is just "plain" text - no validation is
> specified, thus
> we decided not to implement a check into the handler but to
> leave the
> check to ther server application. You may refer to the
> follwoing archived
> e-mail discussion:
>
> http://mail-archives.apache.org/mod_mbox/ws-fx-dev/200409.mbox
> /%3C4135FF52.70908@mitre.org%3E
>
> IMHO implementing this patch brakes a behaviour that WSS4J
> provides since long
> and thus may break applications.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: ext Fred Dushin [mailto:fadushin@apache.org]
> > Gesendet: Dienstag, 15. April 2008 01:51
> > An: wss4j-dev
> > Betreff: WSS-54
> >
> > Hi Ruchith,
> >
> > Could I ask you to take a look at Colm's patch for WSS-54?
> >
> > https://issues.apache.org/jira/browse/WSS-54
> >
> > I'm +1 on the change, but I see you had some important
> comments in the
> > Jira trail, and before committing the change (or asking you to), I'd
> > like to make sure you're in agreement with it.
> >
> > Thanks!
> > -Fred
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: WSS-54
Posted by "O hEigeartaigh, Colm" <Co...@iona.com>.
Hi Werner,
Please consider the revised patch for WSS-54. I think that for the 2.0 timeframe we need to revisit the way things are handled in UsernameTokenProcessor, as delegating authentication to the password callback handler is not a good solution.
In the meantime, the revised patch preserves the old functionality, along with some extra bits and pieces, mainly the addition of an extra variable to control whether password types other than plaintext or digested are allowed.
Thanks,
Colm.
-----Original Message-----
From: Dittmann, Werner (NSN - DE/Muenich) [mailto:werner.dittmann@nsn.com]
Sent: 15 April 2008 08:13
To: ext Fred Dushin; wss4j-dev
Subject: AW: WSS-54
Fred, Ruchith, all,
first of all - thanks to Fred to take actions on all the open issues :-)
As for WSS-54: in the orginal implementation the "handleUsernameToken()"
checked the both types of passwords. After some discussions on the mailing
list (back in 2004, WSS4J's stoneage :-) ) we modified the behaviour to
check only the hashed passwords. The main reason was (as far as I can remember):
- only for hashed passwords the WS-Security specs define how the validate
it (using nonce, created time etc)
- the plain password is just "plain" text - no validation is specified, thus
we decided not to implement a check into the handler but to leave the
check to ther server application. You may refer to the follwoing archived
e-mail discussion:
http://mail-archives.apache.org/mod_mbox/ws-fx-dev/200409.mbox/%3C4135FF52.70908@mitre.org%3E
IMHO implementing this patch brakes a behaviour that WSS4J provides since long
and thus may break applications.
Regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: ext Fred Dushin [mailto:fadushin@apache.org]
> Gesendet: Dienstag, 15. April 2008 01:51
> An: wss4j-dev
> Betreff: WSS-54
>
> Hi Ruchith,
>
> Could I ask you to take a look at Colm's patch for WSS-54?
>
> https://issues.apache.org/jira/browse/WSS-54
>
> I'm +1 on the change, but I see you had some important comments in the
> Jira trail, and before committing the change (or asking you to), I'd
> like to make sure you're in agreement with it.
>
> Thanks!
> -Fred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
AW: WSS-54
Posted by "Dittmann, Werner (NSN - DE/Muenich)" <we...@nsn.com>.
Fred, Ruchith, all,
first of all - thanks to Fred to take actions on all the open issues :-)
As for WSS-54: in the orginal implementation the "handleUsernameToken()"
checked the both types of passwords. After some discussions on the mailing
list (back in 2004, WSS4J's stoneage :-) ) we modified the behaviour to
check only the hashed passwords. The main reason was (as far as I can remember):
- only for hashed passwords the WS-Security specs define how the validate
it (using nonce, created time etc)
- the plain password is just "plain" text - no validation is specified, thus
we decided not to implement a check into the handler but to leave the
check to ther server application. You may refer to the follwoing archived
e-mail discussion:
http://mail-archives.apache.org/mod_mbox/ws-fx-dev/200409.mbox/%3C4135FF52.70908@mitre.org%3E
IMHO implementing this patch brakes a behaviour that WSS4J provides since long
and thus may break applications.
Regards,
Werner
> -----Ursprüngliche Nachricht-----
> Von: ext Fred Dushin [mailto:fadushin@apache.org]
> Gesendet: Dienstag, 15. April 2008 01:51
> An: wss4j-dev
> Betreff: WSS-54
>
> Hi Ruchith,
>
> Could I ask you to take a look at Colm's patch for WSS-54?
>
> https://issues.apache.org/jira/browse/WSS-54
>
> I'm +1 on the change, but I see you had some important comments in the
> Jira trail, and before committing the change (or asking you to), I'd
> like to make sure you're in agreement with it.
>
> Thanks!
> -Fred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org