On Thu, Jun 18, 2009 at 9:10 PM, Daniel Kulp <dk...@apache.org> wrote:
> 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. The requirement here is to use neethi with other libraries which have domain specific policy builders in normal java applications and OSGi enviroments. IMHO, DS approach is the clean way to solve this problem. Say foo.jar which can also behave as a bundle, contains policy builders and they are listed under META-INF/services. When foo.jar is in standard java application, neethi can access the policy builder list. But neethi does not have access to the META-INF/services, when it is running in an OSGi environment. Therefore foo.jar has to inform neethi explicitly that I have some policy builders. Say we expose AssertionBuilderFactory as an OSGi service using DS component. We only need to write an xml file here. Or else we can use Maven SCR plugin [1]. And we need to add a method to the AssertionBuilderFactory with the following signature. This method accepts a class loader and it can be used to search for META-INF/services and load builders if any. *public void registerBuilders(ClassLoader cl); *In this case, what foo.jar has to do is, accuire the AssertionBuilderFactory and invoke the registerBuilders() method by giving the bundle class loader as a parameter. Writing a DS component which has a dependency on AssertionBuilderFactory service, with a component implementation class will do the rest here. Thanks Sameera [1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html > > > 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. > > > > > -- > Sameera Jayasoma > Software Engineer > WSO2 Inc. > Oxygenating the Web Service Platform. > http://wso2.org/ > > blog: http://tech.jayasoma.org > > > > 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 >
