Hi Joel, 2009/11/2 Joel Schuster <[email protected]>
> You might not have to include it in the one bundle... but then you have CM > issues with an entirely different bundle which actually makes the problem > that much worse. Embedding it in a different bundle doesn't get around the > configuration issues... it just moves them. > Well, the idea is that this other bundle could effectively just be a configuration file. Granted, it's packaged as a bundle, but you could make it such that it only contains a config file. I would think that this does have some extra benefits as it would only have to exist for the deployer... > > The DOSGi does use the service properties on the service side to expose any > particular service as a web service just by including the > osgi.remote.configuration.type & such as service properties. In the iPojo > world these can be run-time configured in conjunction with FileInstaller in > a simple cfg name=value properties file. This makes it much simpler to CM > and then distribute and change from one run to the next. I wish that DOSGi > would work exactly the same way on the client side when using the service. > It just seems odd that it would be inconsistent. > > - Joel > I'm not sure how you could take the exact same approach on the client side. Would you manually create a service on the client side that represents the client proxy and then expect the DOSGi implementation to use that? That would be quite tricky. One idea that we did actually support somewhat in CXF-DOSGi is to configure your client side oroxies using the OSGi Config Admin Service. I'm not sure how well this works today, but it certainly makes sense to me. If you think it would be worth pursuing that, please file an enhancement bug for it. And again, if you use a Discovery system like the Zookeeper-based one that comes with CXF-DOSGi, none of these problems should exist. Your remote service will just appear on the client side with all its properties through the Discovery system... Cheers, David
