Hi Colm, On Tue, 13 Sep 2011 17:08:45 +0100 Colm O hEigeartaigh <[email protected]> wrote:
> 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/ Just this branch. The trunk is there because of the svn history. I can move it to http://svn.apache.org/viewvc/webservices/wss4j/branches/swssf/ and drop the rest if wished... > > > 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. I have to think about it. Just moving these core operations does not make any sense to me at the moment, since it will be useless without the whole infrastructure around it. As already mentioned, if it is still wished we have to move most of swssf to santuario and just a small part will be stay in WSS4J. In my eyes it makes only sense if it is usable within santuario for XML-Security processing. No? But give me some time to consider... Marc > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
