On Wednesday, September 14, 2011 2:33:00 PM Daniel Kulp wrote: > 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.)
Just to clarify a little bit.... the Model and builders in CXF do depend on a couple other CXF utility classes like StringUtils and DOMUtils and such which would need some adjusting/copying to pull into wss4j2, but the main chunks of real code can likely be pulled in with little adjustment. Dan > > 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]
