On Tue, Dec 27, 2011 at 21:02, Christian Schneider <[email protected]> wrote: > Am 27.12.2011 19:16, schrieb Guillaume Nodet: > >> On Tue, Dec 27, 2011 at 19:08, Christian Schneider >> <[email protected]> wrote: >>> >>> Hi Guillaume, >>> >>> I am trying to solve the problem that you can not unexport a package the >>> system bundle exports. >>> So it is not possible to override packages that system bundle already >>> exports. >> >> Why ? You can modify the jre.properties. That's easy to do. >> And why would you want to hide them for the sole purpose of exposing >> the exact same packages through a fragment ? >> >>> If we do not export the packages cxf needs using the properties then the >>> user can decide which to use simply by installing a feature instead of >>> changing the >>> properties. This fits a typical deployment process much better. >> >> You're talking about spec packages or implementations ? >> We mostly always use the same packages, so wether they come from the >> system bundle directly or from a fragment has no effect. >> The problem could be the version associated to those packages, but >> they can be specified in both cases. >> >> If we provide the needed packages by default, there's no need to >> deploy any fragments, right ? >> >> > Not really. The idea is to install the fragment if you want the default jre > packages and to install > other bundles if you need special versions. > > Of course changing the jre.properties also does the job but it can not be > done with a command in karaf. At least > not without replacing the whole file which is too coarse grained.
Well, in that case, we could also write a command to change the jre.properties or use the profiles that JB is working on. In all cases, I really want those packages to be available by default. Any other solution would fall into tweaking the container for deploying CXF, and I would be against it, as it would make all other users' life more difficult. Also, the nature of OSGi should allow multiple versions of the same package to be present in the same container. I think some problems come from the fact that the system bundle does not provide any uses clause on its export, thereby creating some problems when wiring packages provided by the system bundle and packages provided by other bundles, but it might be fixable. Before going into a (imho) bad direction, maybe we can identify the real use cases that cause problems and analyse them, then try to fix the real causes. > > Christian > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
