On Tue June 16 2009 1:58:51 am Nandana Mihindukulasooriya wrote: > +1, I also agree that Security Policy stuff should be ideally in WSS4J or > Neethi and eventually we should make WSS4J security policy aware. Both > Rampart and CXF will benefit from that.
The first step is to just get a common set of policy objects. The CXF model and builders for the WS-SecurityPolicy stuff is pretty much a port of the Rampart model, but cleaned up a lot (to avoid a lot of duplicate code), updated to Java 5, and additional policy objects created for some of the stuff Rampart doesn't yet handle (like KeyValueToken). Getting those into a shareable state is a good thing. I think it would eliminate the entire rampart-policy module. As far as making WSS4J security policy aware and using those policies, definitely doable long term, but not really a huge priority at THIS point. Possibly just pulling the *BindingBuilder stuff from CXF. Not really sure as I haven't thought enough about it. It definitely could have benefits for other users of WSS4J (like Spring WebServices and others). Basically, the steps for that are: 1) Agree on changes to Neethi to allow for: 2) Create the common/shareable WS-SecurityPolicy model 3) Use (2) in wss4j to make it policy aware. I'm more concerned right now with the first two bullets. One (or maybe two) steps at a time. :-) Dan > thanks, > Nandana > > On Mon, Jun 15, 2009 at 8:19 PM, Daniel Kulp <dk...@apache.org> wrote: > > 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
