On Wednesday, September 14, 2011 9:52:48 PM Amila Jayasekara wrote: > 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 ?
As Marc just mentioned, the streaming stuff is currently based on Neethi 2.0.4 which requires Axiom. Part of the work will be to upgrade it to Neethi 3 which has a more pluggable mechanism. Neethi 3 can use DOM or XMLStreamReaders for reading policies just fine or can use Axiom if it's available. Since this will be used with CXF, I would insist on one of the first two options. Note: you can still feed Axiom things into Neethi so it has little impact on Rampart or Axis2. Neethi converts as needed to whatever target type the AssertionBuilder requires. Obviously a slight performance impact when conversions are triggered, but it's a startup cost on generally "small" policy documents and is thus fairly small. If we go DOM, we can likely copy most of the Policy model and builders straight out of CXF since they have been updated for Neethi 3 already. I think the base abstract class implements a subclass of the Neethi Assertion interface that adds an extra utility methods that CXF uses, but CXF doesn't require that method anymore either. Making it just subclass the Neethi3 Assertion just "works". (just tested it in CXF and ran our system tests. Unit tests fail that test that method as expected.) Anyway, one of the stated goals of Neethi 3 was to provide a framework for writing Policy assertion objects that can be usable by both CXF and Axis2 (as well as any other Neethi users). This is really just the next step in making this a reality and removing some of the duplicate code between CXF and Axis2. > Marc, in addition i also saw a dependency to cxf-rt-bindings-soap. > Could you please explain the usage of this within swsf ? That would likely move to CXF to replace/augment/update the current CXF ws- security module. Dan > > 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] -- 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]
