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.
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 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? 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? 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 > -- 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/
