On Tue, Sep 13, 2011 at 12:29 AM, Daniel Kulp <[email protected]> wrote: > On Monday, September 12, 2011 6:01:46 PM Marc Giger wrote: >> Hi Colm et al., >> >> Because it seems it will be just a matter of time until swssf is >> getting into the main repo of the ASF > > Already there: > http://svn.apache.org/repos/asf/webservices/wss4j/branches/swssf/ > > >> I want to ask you what needs >> to be done to get it into the WSS4J trunk? > > Well, I guess we'd need to create a 1.6.x branch for the ongoing 1.6.x work. > At this point, however, it may make more sense to create a "temporary" "2.0" > branch to get things cleaned up a bit to prepare it to become the trunk. > > >> >> Colm, you mentioned that swssf could go in the WSS4J 2.0 release. Where >> does the development of WSS4J taking place (trunk?) and is there already >> an ongoing development progress? What are the plans for 2.0 and what >> will be the difference to the current 1.x releases? > > Right now, most of the development that is happening is on trunk which, right > now, is targeting 1.6.x. Obviously, as the development of 1.6.x winds down > and 2.0 winds up, that will need to change. > > > During development of swssf I tried hard to reuse existing projects >> like santuario, neethi, rampart etc. Unfortunately most of the code did >> not fit the requirements that swssf has and I haven't had the time to >> report and discuss possible solutions. This especially true for rampart. >> For some other parts it was probably be doable to reuse existing code >> but since I could do a clean room implementation I reimplemented >> everything which I disliked. This does not mean that my implementation >> is better, I just tried to bring in my experience. Particularly by the >> configuration and interface parts. >> >> That said, from my point of view the most important part to work on is >> WS-Policy. Now we have at minimum tree Rampart copies: The original >> Rampart code, CXF customized Rampart and swssf customized Rampart. CXF >> and my implementation/extension of Rampart have a lot in common. So if >> we could bring them back in one core Rampart implementation we will >> have a lot of duplicate code eliminated. To begin with, I could >> refactor the swssf WS-Policy code in an maven-submodule. This could >> help a little to understand and get the feeling for the streaming-based >> policy verification requirements. > > That may make sense. Updating to Neethi 3, removing the Axiom stuff (would be > a requirement for use with CXF), etc... is also a big step. We'd likely need > to look at the CXF policy model and double check on new things. We've added > support for a bunch of extra token types (like Kerberos and SAML and others) > that would likely need to be pulled back in. We've also added a bunch of > validation things (for post processing) that we'd likely want to make sure > work in the streaming cases as well. (like the XPath expressions and such)
Marc,Dan I am trying to figure out possible effects on apache rampart, with above change. Ideally we would like to plug swsf independently. I am having following concerns related to this. I am +1 for the idea of having a sub-module for WS-Policy code. Dan, i am bit concerned about "removing axiom stuff" First is this change going to be a custom development for CXF only or else are we planning to apply this to new (2.0) WSS4J framework ? After swiftly going through swsf code, i realised that it still uses axiom in its policy processing code. If we are planning to apply this change to WSS4J 2.0 framework, what are we going to use in-place of axiom ? Marc, in addition i also saw a dependency to cxf-rt-bindings-soap. Could you please explain the usage of this within swsf ? Thanks AmilaJ > > >> A further point is the configuration. A common configuration for WSS4J >> and swssf would also simplify things. >> >> What are your expectations? What do you dislike and should be changed? >> What are the next steps from your point of view? >> >> In my eyes it would be wrong if we simply adapt swssf to WSS4J and >> other projects so that it just fit. Refactoring and use the best >> concepts of the projects would be the wiser way and could lead to >> really superior major releases. > > +1 to that. :-) > > Couple more things to think about: > 1) Move everything into org.apache.ws.security namespace. One question to > all: should we do "ws.security2" or something so that it can co-exist with > wss4j 1.6.x in process? > > 2) Likewise, move the "generated" code out of the org.oasis and org.w3. Too > many potential conflicts when that is done. > > 3) Need to work on being able to use XMLStreamReader and XMLStreamWriter > implementations instead of just XMLEvent*. Likely can wrapper the Stream > versions with some sort of Event version, but I'm not 100% sure if that's > possible (haven't completely tried. There is some utilities in CXF that may > help here.). Proper integration with CXF will definitely need this. Maybe > for Axiom as well (not sure). > > 4) MTOM support - I haven't looked at this yet, but how does it handle MTOM > and other attachment related things? Does it? > > I definitely need to think a bit more and look into the code a bit more, but > those are my initial "top of my head" type thoughts. > > Dan > > >> But this is just my opinion and its ok >> with me whatever the community decides. >> >> Thank you >> >> Kind regrads >> >> Marc >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > Talend - http://www.talend.com > > --------------------------------------------------------------------- > 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]
