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
