+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?
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
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
