On Wed, 14 Sep 2011 16:03:56 -0400 Daniel Kulp <dk...@apache.org> wrote:
> 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 ~~~~~~ Do you mean rampart, don't you? > 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: dev-unsubscr...@ws.apache.org > > > >> For additional commands, e-mail: dev-h...@ws.apache.org > > > > > > > > -- > > > > Daniel Kulp > > > > dk...@apache.org > > > > http://dankulp.com/blog > > > > Talend - http://www.talend.com > > > > > > > > -------------------------------------------------------------------- > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org > > > > For additional commands, e-mail: dev-h...@ws.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org > > > For additional commands, e-mail: dev-h...@ws.apache.org > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org > For additional commands, e-mail: dev-h...@ws.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org