[
https://issues.apache.org/jira/browse/TUSCANY-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Edwards resolved TUSCANY-3547.
-----------------------------------
Resolution: Fixed
Resolved along the lines described in the description in 941719
- required the fixing of a couple of testcases in addition to the mainline
code, since the initialization sequence is changed to require a Registry object
to be supplied, used when creating the ContextClassLoader....
> databinding-sdo module does not execute under OSGi
> --------------------------------------------------
>
> Key: TUSCANY-3547
> URL: https://issues.apache.org/jira/browse/TUSCANY-3547
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Databinding-SDO
> Affects Versions: Java-SCA-2.0-M4
> Reporter: Mike Edwards
> Assignee: Mike Edwards
> Fix For: Java-SCA-Next
>
>
> The databinding-sdo code does not work under OSGi and fails with a
> NullPointerException.
> databinding-sdo unsurprisingly uses the Tuscany SDO module, which uses a
> classic API / Provider pattern using META-INF/services, with the provider
> classes in a different JAR from the API classes.
> The provider classes are discovered through a lookup for a META-INF/services
> declaration for "commonj.sdo.impl.HelperProvider".
> The regular OSGi classloading will fail since the declaration is in a
> separate bundle from that of the API class. It is not correct to make the
> API bundle depend on the provider bundle, so instead Tuscany has a different
> classloading approach that must be used.
> This requires some special treatment in order to work under OSGi
> The class within databinding-sdo that is affected is the SDOHelperContext
> class and the getDefaultHelperContext method in particular. This method
> causes the loading of the HelperProvider implementation class and then
> accesses that class to obtain the defaultHelperContext.
> This is done with a simple call to HelperProvider.getDefaultContext();
> Under OSGi, this must instead be done using a Context ClassLoader created
> using:
> ClassLoaderContext.setContextClassLoader(SDOContextHelper.class.getClassLoader(),
>
> registry.getServiceDiscovery(),
> // SDO Helper Provider
>
> "commonj.sdo.impl.HelperProvider"
> );
> The actual loading of the HelperProvider class is unfortunately complex due
> to a static initializer in the API class (** NB we should get this changed
> ASAP - it is evil code from an OSGi perspective). The following code is
> necessary in order to force the use of the Context ClassLoader created by the
> above Tuscany method:
> ClassLoader tccl =
> Thread.currentThread().getContextClassLoader();
> HelperProvider.setDefaultInstance(tccl);
> defaultHelperContext = HelperProvider.getDefaultContext();
> ...note the accessing of the class loader
> - followed by the setting of the default instance for the HelperProvider -
> this does not avoid the static initializer of the HelperProvider class but it
> assumes that the initializer will fail to find the provider (under OSGi) and
> instead the setDefaultInstance call using the tccl will instead successfuly
> load the right provider class.
> This then permits successful use of the getDefaultContext method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
