On Tue June 16 2009 11:29:05 pm Sanjiva Weerawarana wrote:
> +1 from me.
>
> So WSS4J is currently not really policy- aware .. that's done in Rampart.
> I'd say that that's a WSS4J2 we're talking about right?
Possibly. Since pulling code from CXF/Rampart could just be additions to
WSS4J, it could be a 1.6 type thing as well. Not really sure at this point.
Dan
>
> Sanjiva.
>
> 2009/6/17 Daniel Kulp <dk...@apache.org>
>
> > The more I think about this, the more I like it. Porting existing code
> > to 3.0 becomes quite easy: just change:
> >
> > public class MyBuilder implements AssertionBuilder{
> >
> > to
> >
> > public class MyBuilder implements AssertionBuilder<OMEelement>{
> >
> > and it should be fine. Obviously, those builders would only work when
> > Axiom
> > is available (ex: in Axis2) but that should be fine. For builders we
> > "build
> > in" to Neethi or WSS4J, we can use either Element (if easier/complex) or
> > StAX
> > (simple things) to make them usable when Axiom isn't there.
> >
> > Anyway, I change my #3 proposal to this idea. :-)
> >
> > Dan
> >
> > On Tue June 16 2009 2:45:54 pm Daniel Kulp wrote:
> > > Since we're going Java 5, the other option COULD be to make the
> > > AssertionBuilder interface something like:
> > >
> > > public interface AssertionBuilder<T> {
> > > Assertion build(T element, AssertionBuilderFactory factory)
> > > ...
> > > }
> > > where T could be Element, XMLStreamReader, or OEElement (or others in
> > > the future) and do some "magic" in the AssertionBuilderFactory to do
> > > conversions back and forth as needed depending on what the registered
> > > Builder requires and what gets passed in. Quite a bit more complex,
> > > but definitely more flexible.
> > >
> > > Dan
> > >
> > > On Tue June 16 2009 2:41:14 pm Daniel Kulp wrote:
> > > > On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > > > > The way Neethi works is that it basically uses Axiom only to
> >
> > implement
> >
> > > > > the policy-domain specific parser to create the policy-domain
> >
> > specific
> >
> > > > > object model. That is, it is TOTALLY internal.
> > > >
> > > > Not entirely. The PolicyEngine object has public methods like:
> > > > Policy getPolicy(OMElement element)
> > > > that make it NOT totally internal.
> > > >
> > > > > Its of course possible to do without it, but that would make it
> > > > > that much harder to write a security policy parser for example as
> >
> > everything
> >
> > > > > would have to be done directly in StAX instead of Axiom - a tree
> > > > > API
> >
> > is
> >
> > > > > of course easier to deal with than a streaming API.
> > > >
> > > > That's a matter of opinion. I personally find dealing with StAX
> > > > quite easy, but I'm completely used to it by now. :-)
> > > >
> > > > That said, if you want to keep it a tree, I'm QUITE OK with using
> > > > org.w3c.dom.Element. That would make my life MUCH easier as all the
> >
> > CXF
> >
> > > > builders are already using it. :-) I mostly suggested StAX
> >
> > since
> >
> > > > the writers are already using it. Kind of a mirror thing.
> > > >
> > > > > That could could easily be factory'ed away but that would still
> >
> > require
> >
> > > > > CXF and Axis2 to have their own domain specific builders. Have you
> > > > > evaluated the pain level of going down to StAX to do the building?
> > > >
> > > > The main point of what I'm trying to do with 3.0 is to make it so CXF
> >
> > and
> >
> > > > Axis2 don't need their own domain specific builders. We can share
> > > > the policy model objects, the builders that go with them, etc....
> > > > For example, I know that several of the Rampart builders don't
> > > > properly record some of the attributes into the model. I know cause
> > > > I fixed
> >
> > them
> >
> > > > in the CXF builders. It would be good to have a single set of
> > > > builders and models where we can both benefit from fixes such as
> > > > that.
> > > >
> > > > However, that cannot happen until we agree on an API for the
> > > > builders. Using Axiom is a non-starter for me. StAX or DOM Element
> > > > is OK by me. Doesn't matter which. You have a preference between
> > > > those two? I'd
> >
> > be
> >
> > > > happy either way.
> > > >
> > > > > I'm not sure what MEX impacts here .. Axis2 has a MEX module and
> > > > > there's no overlap/issue with Neethi's parsing model there. What am
> > > > > I missing?
> > > >
> > > > It mostly has to do if you get a Policy as an InputStream (MEX or
> > > > from
> >
> > a
> >
> > > > Policy repository via REST or similar), what is the most efficient
> > > > way
> >
> > of
> >
> > > > converting that stream into a usable Policy object. InputStream ->
> >
> > StAX
> >
> > > > -> builders is quite efficient requiring near 0 memory overhead
> > > > during the conversion. However, policy docs are "generally" fairly
> > > > smallish (unless you are really nuts and LOVE policy docs ;-) so
> > > > doing an InputStream -> some infoset model like Axiom/DOM -> builders
> > > > is really not THAT big of a deal.
> > > >
> > > > Dan
> > > >
> > > > > Sanjiva.
> > > > >
> > > > > 2009/6/16 Daniel Kulp <dk...@apache.org>
> > > > >
> > > > > > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > > > > > +1 Dan. Can you clarify #3 a bit please?
> > > > > >
> > > > > > Sure. Basically, in order to make this workable at all (and
> > > > > > worth my time to
> > > > > > proceed down this course), we need to have an API that is
> > > > > > palatable by everyone involved. The PRIMARY reason for the fork
> > > > > > of some of the Neethi stuff in CXF is the Axiom dependency which
> > > > > > is not acceptable for our core use
> > > > > > cases. If that is eliminated, the fork in CXF can go away.
> >
> > There
> >
> > > > > > were two
> > > > > > main options I considered:
> > > > > >
> > > > > > 1) DOM element - this is currently what the CXF version uses.
> >
> > This
> >
> > > > > > is because things like WSDL4J DOM parses extensor elements (by
> > > > > > default) and spring provides configuration things as DOM elements
> >
> > and
> >
> > > > > > such. Thus, it worked best for us. However, for Axis2, that
> > > > > > would require flipping the Axiom stuff over to DOM mode which has
> > > > > > performance issues.
> > > > > >
> > > > > > 2) StAX - The proposal below is to use StAX. The Policy objects
> > > > > > themselves
> > > > > > already use StAX for writing XML. Thus, using it to read the
> > > > > > xml would make
> > > > > > it consistent. Also, that makes it pretty easy for both Axis2
> > > > > > and CXF to work with it. Creating an XMLStreamReader from a DOM
> > > > > > or Axiom thing is "trivial" so whatever path you choose should
> > > > > > work fairly well. Plus, as we
> > > > > > go down the route of WS-MEX and other remote policy retrieval
> > > > > > mechanisms, it
> > > > > > would allow direct StAX streaming. (like directly from the HTTP
> > > > > > InputStream)
> > > > > >
> > > > > > Anyway, switching to StAX seemed to be the most palatable by both
> > > > > > parties. If we can agree on that, then the common policy objects
> >
> > and
> >
> > > > > > stuff can become a
> > > > > > reality.
> > > > > >
> > > > > > Dan
> > > > > >
> > > > > > > Sanjiva.
> > > > > > >
> > > > > > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > > > > > >
> > > > > > > > Some of you have noticed some discussions on WSCOMMONS-299.
> > > > > > > > I've also been
> > > > > > > > thinking about some of those issues and I DID have a
> > > > > > > > discussion with
> > > > > >
> > > > > > Glen
> > > > > >
> > > > > > > > Daniels at TSSJS about the possibility of starting work on a
> > > > > > > > Neethi
> > > > > >
> > > > > > 3.0.
> > > > > >
> > > > > > > > With the comments and stuff on WSCOMMONS-299, it might be
> > > > > > > > time
> >
> > to
> >
> > > > > > really
> > > > > >
> > > > > > > > start
> > > > > > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch
> > > > > > > > for future maintenance and start making trunk 3.0.
> > > > > > > >
> > > > > > > > Things I'd like tackled for 3.0:
> > > > > > > >
> > > > > > > > 1) Java 5 - make the collections and everything typed. Use
> >
> > Enums
> >
> > > > > > > > where appropriate, etc.... Basically, general cleanup.
> > > > > > > > Also,
> >
> > I
> >
> > > > > > > > see that
> > > > > >
> > > > > > many
> > > > > >
> > > > > > > > operations aren't threadsafe due to use of HashMap's with no
> > > > > > > > synchronization.
> > > > > > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > > > > > >
> > > > > > > > 2) Better support for the nested policies as described in
> > > > > >
> > > > > > WSCOMMONS-299.
> > > > > >
> > > > > > > > 3) Change the builders to use XMLStreamReader. The Policies
> >
> > use
> >
> > > > > > > > XMLStreamWriter. For consistency, using the reader is
> >
> > preferred.
> >
> > > > > > This
> > > > > >
> > > > > > > > also
> > > > > > > > removes Axiom as a dependency making the requirement list
> > > > > > > > smaller.
> > > > > > > >
> > > > > > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF
> > > > > > > > can be
> > > > > >
> > > > > > ported
> > > > > >
> > > > > > > > back. CXF has a few utilities and such that would be good to
> > > > > > > > push back and then remove from CXF.
> > > > > > > >
> > > > > > > > 5) Once all of that is done, it would open up the door to
> > > > > > > > allow some
> > > > > >
> > > > > > more
> > > > > >
> > > > > > > > "common" Policies objects for standard policies. Some could
> >
> > be
> >
> > > > > > > > in Neethi directly (things like policies objects for
> > > > > > > > WS-Addressing assertions, mtom stuff, etc...). Others,
> > > > > > > > like the
> > > > > > > > WS-SecurityPolicy stuff could either go into Neethi or might
> > > > > > > > be better in WSS4J. This could help eliminate a BUNCH of
> > > > > > > > duplicate code between users of Neethi, particularly CXF and
> > > > > >
> > > > > > Rampart.
> > > > > >
> > > > > > > > (maybe if I keep pushing similar code down into commons, we
> > > > > > > > can have a big merger in the future. Acxfis 3? Maybe not.
> > > > > > > > :-) )
> > > > > > > >
> > > > > > > > 6) Support for WS-Policy 1.5.
> > > > > > > >
> > > > > > > > Anyway, if no one really objects to starting the 3.0 work,
> > > > > > > > I'd like to create
> > > > > > > > the 2.x branch later this week. Thoughts?
> > > > > > > >
> > > > > > > > BTW: This is also why I STRONGLY am in favor of Neethi
> > > > > > > > staying
> >
> > in
> >
> > > > > > commons
> > > > > >
> > > > > > > > and
> > > > > > > > not going to an Axis2 TLP.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Kulp
> > > > > > > > dk...@apache.org
> > > > > > > > http://www.dankulp.com/blog
> > > > > >
> > > > > > --
> > > > > > Daniel Kulp
> > > > > > dk...@apache.org
> > > > > > http://www.dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > dk...@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
