On Dec 27, 2011, at 4:16 PM, Łukasz Dywicki wrote: > 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?
i don't know about jre 1.7. For jre 1.6, the stax and jaxb packages are currently exported from the framework with no version. The spec (non-osgi/package) versions however are 1.0 or 1.1 (stax) and 2.0 or 2.1 (jaxb). I think most people using xml want the more up to date 1.2 stax and 2.2 jaxb - for instance I think cxf needs it. Neither osgi nor oracle have come up with recommended package versions for these stax and jaxb packages. Both the servicemix and geronimo spec jars have taken it upon themselves to export the packages at the spec version level, which is probably wrong. Deploying the specs as bundles doesn't seem to work. Guillaume has pointed out a problem with javax.xml.transform in the jre not being able to find the stax classes in a bundle. For my part, I've found that you get all sorts of bizarre problems with jaxb. So it looks like we have to follow the oracle mandated route of putting the spec jars in endorsed so they override the jre classes. Then we have a problem of how such a spec jar can find an implementation that's in a bundle. IIUC the karaf-activator is supposed to solve this problem. The remaining bit is that since there are no official package versions for these packages, we should not add them to jre.properties and we should recompile all the bundles that have been compiled against servicemix and geronimo spec jars that specify package versions. I hope that osgi alliance eventually suggests package version numbers for these packages. At that time we'll have the problem of how to specify them in jre.properties depending on which specs are actually in use. For now, the only approach that I think is plausible is to remove versions from jre.properties, use the karaf-activator approach to spec jars in endorsed, and recompile anything that expects a stax or jaxb package version. We wont need to modify jre.properties at all. thanks david jencks > > 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 >> <ch...@die-schneider.net> wrote: >>> Am 27.12.2011 19:16, schrieb Guillaume Nodet: >>> >>>> On Tue, Dec 27, 2011 at 19:08, Christian Schneider >>>> <ch...@die-schneider.net> 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 >
