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) > 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]
