The classpath is what I am referring to. Extensions on the classpath may lead to subtle crapola in any jdk/app server/container that expects extensions to load via lib/ext, if, say the bc JAR happens to be on the classpath.
It was more of a thought. I guess someone will bring up the issue if they encounter any problem . . . :) Hans > -----Original Message----- > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 17, 2005 1:18 PM > To: Granqvist, Hans > Cc: Werner Dittmann; wss4j-dev@ws.apache.org > Subject: Re: Refactoring (Re: WSS4J future) > > Like which one? AFAIK, only additional thing we do is > register bc provider if it is available in the classpath. > > -- dims > > On 9/17/05, Granqvist, Hans <[EMAIL PROTECTED]> wrote: > > I'll check it out. Looks interesting. > > > > I have noticed that wss4j doesn't like to use java.security JCE > > provider list settings. Any scoop why? > > > > hans > > > > > -----Original Message----- > > > From: Davanum Srinivas [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, September 13, 2005 9:21 PM > > > To: Granqvist, Hans > > > Cc: Werner Dittmann; wss4j-dev@ws.apache.org > > > Subject: Refactoring (Re: WSS4J future) > > > > > > Hans, Werner, > > > > > > I've refactored a bunch of stuff and added a package called > > > processors (for processing dom elements that are > encountered by the > > > security > > > engine) and actions (things that the user has asked the > handler to > > > do). Could you guys please take a look? and comment? if it shows > > > promise i'll do more work when i get a change. Basically > it breaks > > > up all the stuff into pieces that are loaded when needed > (trying to > > > get a handle on #1 below) > > > > > > #2, wsdd's how services are configured in Axis. If we can write a > > > WS-SecurityPolicy Processor, we could replace the complicated > > > parameter stuff with a link to a single xml in the wsdd. > > > > > > #3, Folks pick up what they need and put them together. > > > Kirill is demo'ing SecureMTOM (with Axis2, WSS4J) and SecureRM > > > (Axis1.X, WSS4J, Sandesha, Addressing) more on that later :) > > > > > > thanks, > > > dims > > > > > > > > > On 9/13/05, Granqvist, Hans <[EMAIL PROTECTED]> 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. > > > > > > > > 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.) > > > > > > > > 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. > > > > > > > > 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? > > > > > > > > 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] > > > > > > > > > > > > > > > > > -- > > > Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service > > > Platform > > > > > > > > > > > -- > Davanum Srinivas : http://wso2.com/ - Oxygenating The Web > Service Platform > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]