Hi, > Already there: > http://svn.apache.org/repos/asf/webservices/wss4j/branches/swssf/
Do we need the trunk code available here? http://svn.apache.org/viewvc/webservices/wss4j/branches/swssf/streaming-webservice-security/trunk/ or just the Apache branch? http://svn.apache.org/viewvc/webservices/wss4j/branches/swssf/streaming-webservice-security/branches/apache-contribution/ > 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. I'll get 1.6.3 out fairly shortly. After that I can create a 1.6.x-fixes branch. I agree that it might make more sense to clean the swssf branch up a bit more before it gets merged to trunk. > Couple more things to think about: I'm +1 to all of your suggestions Dan. Marc, what do you think of the idea of creating an initial maven module which only contains the core "Santuario" operations of signature creation/verification, encryption/decryption, c14n, etc. Would it be possible to separate out the code in this way first? I'd like to get a clearer idea of whether it would be possible to move this code to Santuario. If not, it might still be a good idea to have it in a separate module. Colm. On Mon, Sep 12, 2011 at 7:59 PM, 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) > > >> 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] > > -- Colm O hEigeartaigh http://coheigea.blogspot.com/ Talend - http://www.talend.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
