ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Neethi 3.0
Date Tue, 16 Jun 2009 13:11:18 GMT

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 


> Sanjiva.
> 2009/6/15 Daniel Kulp <>
> > 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
> >
> >

Daniel Kulp

View raw message