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]

Reply via email to