So far I see two solutions a) profiles b) changes in jre.properties Both are fine for me. But from my understanding we should not limit a standard jre. We can just put a jaxb in export packages for jre 1.6. and 1.7. If it is a standard packages for these JVM versions, why we wouldn't allow to use them?
Best regards, Lukasz Wiadomość napisana przez Guillaume Nodet w dniu 2011-12-27, o godz. 22:33: > 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
