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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
**********************************************************************
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
