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
