and is not present inside my WAR file. Is there any way to force MWS to use classes from one classloader or to exclude plugin (I tried to delete JAXBContext class from com.softwareag.ext.gf.javax.xml.bind_2.2.6.0000-0006.jar but it ended in MWS not starting at all).
You may include a OSGI-OPT/bnd.bnd file inside your CAF application with more specific instructions for the generation of the OSGi manifest, but that can be tricky to get correct.
Can you provide a simple test project that demonstrates the problem?
If so, then the best course of action would be to request a formal review through the official support channels.
You may want to file an SI (Support Incident) with GS (Global Support). Please include all the necessary information so that GS may record and also review for any other issues that match. If GS needs to create a bug report , then whichever R&D engineer handles this case will be expecting a clear description of the issue, logs and any other details in order to efficiently be able to help. Providing this info in the beginning will make the process go faster.
How can I tell MWS (in bnd.bnd) not to use bundle softwareag\common\runtime\bundles\ext\eclipse\plugins\com.softwareag.ext.gf.javax.xml.bind_2.2.6.0000-0006.jar ? I found in OSGI console that javax.xml.bind comes from this bundle (and I want it to come from one source: rt.jar)
From the OSGi console, you can verify that there are actually more than one version exported with the packages command like this:
osgi> packages javax.xml.bind
If the package is actually being exported from more than one place, then in theory, you could specify a version range on the Import-Package instruction of specific packages to match a specific exported version.
For example, in your WebContent/OSGI-OPT/bnd.bnd file the content could look something like this to match one whose exported version number is between 0.0 and 1.0:
# adjust some package imports that are used at runtime
Import-Package: javax.xml.bind;version="[0.0,1.0)",\
*
But, I can’t guarantee that it would work as there could be some other bundle in your BundleWiring solution that is wired to the other version which could produce an inconsistent class space and fail.
[quote=Eric Norman]
You may include a OSGI-OPT/bnd.bnd file inside your CAF application with more specific instructions for the generation of the OSGi manifest, but that can be tricky to get correct.
Hello Eric,
Thank for help.
Here is an example CAF project, which calls internet weather service on buton pressing.
And fails badly - with error as citated - when used. JaxwsPortletProject.zip (3.34 MB)
Hi Eric,
We tried removing our libs at the beginning, but it coused another problem: Calling Service “do not have a property of name …”
I found similar problem here:
and solution there was to add jax-ws-rt lib into application …
Regards,
Marcin Mulawa
we tried it with example bnd.bnd file, but only first deployment succeed.
Next deployments of this project didn’t succeed - with error:
“org.apache.axis2.AxisFault: com.webMethods.portal.bizPolicy.BizException: [POP.003.0139] Component “DamianProject.war” installation failed. System state is recovered by uninstalling the component. Original error: BundleContext is no longer valid
com.webMethods.portal.bizPolicy.BizException: [POP.003.0139] Component “DamianProject.war” installation failed. System state is recovered by uninstalling the component. Original error: BundleContext is no longer valid”
And we cannot even force proper deployment of the original project.
BTW. javax.xml.bind version we needed was 2.2.10
------------EDITED----------------------------------------
OK. Case resolved.
Proper redeploy - after remowing not only bnd.bnd file, but also whole OSGI folder from project. (when bnd file has wrong parameters inside)
Colleaque found a solution - in the file libraries unwanted have to be excluded - by ! sign at the line beginning, like
!javax.xml.bind; version=“2.2.6”,\