Hans, just see inline comments :-) .
Regards, Werner Granqvist, Hans wrote: >>>I would really like to have a discussion/exchange of ideas how to >>>improve the code, add a "plugin" feature for various functions like >>>SAML, Kerberos, etc (Dims asked about that a time ago). > > > First of all: I don't want to step on anyone's toes. Don't get > discouraged. Just some ideas and thoughts below. Werner: that's one reason of open source: others may have better ideas, more experience, etc. So the implementation just gets better > > 1) I'd like to see if I can re-architect a few areas of WSS4J and > make some portions less coupled. Some of the handlers seem > monolithic and too hard to understand. The code is somewhat too > relaxed in syntax, javadoc, etc., and makes a sloppy impression > (which is bad since the code doesn't seem that bad once you look > closer, but it probably scares off potential developers they way > it looks now.) Werner: blame that to my 20+ years of C (_not_ C++) histroy :-) . > > 2) There is something about the wsdd files that bothers me, but I > can't figure out if it's a vestige of Axis. Anyone feel the same? > Quite a few questions to the list relate to these deployment files. > All the "XML situps" seem error prone and a security risk, too. > These files could be pre-packaged and signed, and somehow mapped > to policies, perhaps. Werner: fully aggreed. When we started we just had a handful of parameters. Now its a nuisance - need to restructure to cover new features, make it more user friendly, etc. I just replied to a mail from Dims addressing this topic. > > 3) I lack a "user's vision" how all the ws.apache.org projects work > together. For example, if I want to use, say, WS-Trust, would I (as > a WSS4J user) collate the various ws.apache.org project JARs that > WS-Trust depend on, or would there be separate deployment steps to > get, say, the WS-Addressing parts needed? There seems too much > fragmentation. But perhaps I exaggerate? Werner: True. But putting it together in one big piece would IMHO break the way it is developed now. Question, mainly to Dims: is there any overview how the various WS projects relate to each other and/or use each other. Maybe we can then setup two/three ZIPs that contain the most used jars like we did it for WSS4J 1.1.0. This could help in a first step. > > Okay, my chin is out. Feel free to pound on it :) > > Hans > > > > >>-----Original Message----- >>From: Werner Dittmann [mailto:[EMAIL PROTECTED] >>Sent: Monday, September 12, 2005 11:48 PM >>To: Granqvist, Hans >>Cc: wss4j-dev@ws.apache.org >>Subject: Re: WSS4J future >> >>Hans, >> >>just forgot: >>the WSS4J core library does not depend on Axis. It is >>possible to use other SOAP stacks / SOAP engines as well. >>AFAIK there are other implementations for other SOAP engines. >> >>Only the handlers depend on the underlying SOAP engines. >>Currently we provide handlers for Axis and JAX-RPC SOAP >>engines. The handlers use the WSS4J library / methods. >> >>This decoupling of core and handler was one of the first >>steps during WSS4J development. >> >>Regards, >>Werner >> >>Werner Dittmann wrote: >> >>>Hans, >>> >>>ther are is real roadmap / versions planning. We try to >> >>keep up with >> >>>the specs, interop problems with .Net etc. The whole developer team >>>for the core are just 2-3 people, all really part time. Thus it was >>>just not possible to do more as to keep up with specs and interop >>>problems. >>> >>>For sure there are some areas that need code improvements, in >>>partiular the whole error/exception handling needs to be >> >>cleaned up. >> >>>Also to make it more compliant the the specs in terms of >> >>error code, messages etc. >> >>>Axis2: AFAIK the Axis2 guys try to have WSS4J as standard in their >>>project, maybe Dims as "the master" :-) can give you more info. >>> >>>Sandbox: Dims did it and put code in it that is not yet part of the >>>official WSS4J release (Trust, Secure Conversation). See the README. >>> >>>As for DOM centic: yes, you are right. IMHO it is not easy >> >>to use SAX >> >>>or pull parsers or other optimizations. Several reasons: >>>- during Security processing you often must alter existing elements, >>> e.g. in the Body, replace elements, insert new elements >>>- The scurity elements need to refer to elements in the Body and >>> elsewhere. >>>- if you need to sign/encrypt you need the real content and, in case >>> of encryption, replace it with the encrypted data. >>>- depeding on the order of the security actions to perform you may >>> again need to reference / sign these elements >>>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are >>> also based on DOM. >>> >>>Many of these things need a "full tree" to be able to >> >>navigate inside >> >>>the tree and modify it where needed. >>> >>>While it may be possible to rewrite WSS4J to use SAX or >> >>pull parsers >> >>>it will introduce additional logic to keep track of references, >>>element replacements etc. These functions are available in >> >>DOM. Thus, >> >>>IMHO, it would not be simpler - maybe even more complex >> >>from the WSS4J >> >>>code point of view. >>> >>>Thoughts? >>> >>>Regards, >>>Werner >>> >>>Granqvist, Hans wrote: >>> >>> >>>>Hi developers, >>>> >>>>I currently work on the a ws.apache.org incubation project >> >>[1], and I >> >>>>want to see how I can contribute to wss4j and ws.apache.org. >>>> >>>>I've spent some time going through the wss4j source, but I lack an >>>>overall view of what you all currently work on, or what you plan to >>>>work on, now and in the close future. Is there a roadmap? >> >>Is there >> >>>>also a list of who's involved with which standards bodies >> >>development? >> >>>>Are there areas in the wss4j code that you feel could be improved? >>>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but >>>>I'd like to know what you think the real itches are (there must be >>>>some? ;) >>>> >>>>Are there any ideas in the core/plugin/addon structure of >> >>[1] that you >> >>>>think makes sense to use/work on in wss4j? (Please note that the >>>>javadocs link in [1] is somewhat out-of-date currently.) >>>> >>>>What does Axis2 mean for the wss4j development? Are there Axis v1 >>>>areas of wss4j that I should not waste time on because of something >>>>else, something better in the works? I'd hate to start working on >>>>something that is slated to go away. >>>> >>>>Part of my personal drive is to try to implement the >> >>identity system >> >>>>(see more info in [2]) and that would involve some work implementing >>>>WS-* standards, plus potentially some interesting end-user APIs. >>>>Previous emails [3] on for example WS-Trust sound promising, but >>>>directions are somewhat unclear. Comments, ideas, prioritizations, >>>>etc., mucho welcome. >>>> >>>>The various ws.apache.org projects working together in a non-Axis >>>>setting -- is that concept out-of-scope? >>>> >>>>wss4j is currently quite DOM-centric. Do we want to get away from >>>>that? SAX, push-pull, etc.? >>>> >>>> >>>>Thanks for your time, >>>>Hans >>>> >>>>PS. I have to end with a perhaps naïve question: What >> >>exactly is meant >> >>>>by the wss4j "sandbox"? Sorry, this may be obvious, but I can't >>>>figure it out. >>>> >>>>[1] http://incubator.apache.org/tsik >>>>[2] http://incubator.apache.org/tsik/roadmap.html >>>>[3] >>>>http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508 >> >>.mbox/%3C5 >> >>>>[EMAIL PROTECTED] >>>> >>>>------------------------------------------------------------ >> >>--------- >> >>>>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] >>> >>> >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
