On Wed, 14 Sep 2011 16:03:56 -0400
Daniel Kulp <[email protected]> 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: [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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
