On Wed June 17 2009 11:16:36 pm Sanjiva Weerawarana wrote: > +1 for OSGi enabling everything. On the particular approach, I have to > defer to more OSGi experts .. I thought using declarative services allows > you to avoid having bundle activators but I'm prolly off!
From my understanding, it kind of depends on the the target audience and how much "work" you want people writing their own policies to go through to get them registered and how much they will need to know about OSGi. Currently, all they need to do is add a file in META-INF/services that lists their builder classes. That's it. With a BundleActivator/Listener, we can use that same approach and it will "just work". All they need to do is make sure their jar is loadable in OSGi. (mavne bundle plugin would work for example) With DS, they would need to write an XML file that describes their "services" (assertion builders). Then they need to register that by adding an entry into the manifest. Most common way to do that would be to configure the maven- bundle-plugin. Those would require some extra "knowledge" and expertise in OSGi. For example, let's say for a minute that we don't put the WS-SecPol stuff into a common area, then porting Rampart would involve creating XML entries describing ALL the builders in Rampart (a bunch of them) as well as configuring the OSGi stuff. Definitely a bit of work. I guess if the target audience for Neethi 3 would ALWAYS be OSGi experts, then DS is probably the way to go. However, my gut feeling is that that isn't ALWAYS the case and the "simple" META-INF/services stuff that is there now is a bit easier. (and certainly easier to port older code) Caveat: I'm by no means an "OSGi expert". Dan > > Sanjiva. > > 2009/6/17 Daniel Kulp <dk...@apache.org> > > > One more thing to add to the list: > > > > 7) Add an OSGi BundleActivator and BundleListener to have allow it to > > find the > > policy providers and stuff in an OSGi environment where the > > META-INF/services > > lookup method doesn't really work very well. > > > > Dan > > > > On Mon June 15 2009 10:49:59 am Daniel Kulp 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
