[ https://issues.apache.org/jira/browse/CMIS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576717#comment-14576717 ]
Sascha Homeier edited comment on CMIS-878 at 6/8/15 8:07 AM: ------------------------------------------------------------- Positively tested with following conditions (AP = AuthenticationProvider, OF = ObjectFactory): ||Bundles in framework||OpenCMIS Manifest Header||SessionParam||Test Result|| |No AP-Bundle, No OF-Bundle|-|No AP/OF classes|OpenCMIS Standard AP and OF was taken| |No AP-Bundle, No OF-Bundle|-| AUTHENTICATION_PROVIDER_CLASS set to own AP Impl|ClassNotFoundException for own AP Impl| |No AP-Bundle, No OF-Bundle|-| OBJECT_FACTORY_CLASS set to own OF Impl|ClassNotFoundException for own OF Impl| |No AP-Bundle, Own OF-Bundle|OF-Bundle: OpenCMIS-SPI set to own OF Impl|OBJECT_FACTORY_CLASS set to own OF Impl|Own OF Impl was taken by OpenCMIS| |No AP-Bundle, Own OF-Bundle|OF-Bundle: OpenCMIS-SPI set to non-existing class|OBJECT_FACTORY_CLASS set to own OF Impl|ClassNotFoundException for own OF Impl| |Own AP-Bundle, No OF-Bundle|AP-Bundle: OpenCMIS-SPI set to own AP Impl|AUTHENTICATION_PROVIDER_CLASS set to own AP Impl|Own AP was taken by OpenCMIS| |Own AP-Bundle, Own OF-Bundle|AP-Bundle: OpenCMIS-SPI set to own AP Impl; OF-Bundle: OpenCMIS-SPI set to own OF Impl|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Own AP and OF was taken by OpenCMIS| |Own AP-Bundle, Own OF-Bundle|AP-Bundle: No OpenCMIS-SPI set; OF-Bundle: OpenCMIS-SPI set to own OF Impl set|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|ClassNotFoundException for own AP Impl| |Own 2 in 1 Bundle containing Own AP and Own OF Impl|OpenCMIS-SPI String contains FQCN for Own AP and Own OF Impl Class (separaetd by comma)|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Own AP and Own OF Impl was taken by OpenCMIS| |Own 3 in 1 Bundle containing Two Own AP and Own OF Impl|OpenCMIS-SPI String contains FQCN for Both Own AP Impl and Own OF Impl Class (separated by comma)|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Proper Own AP Impl and Own OF Impl was taken by OpenCMIS| |No Bundle containing AP/OF Impl|-|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|ClassNotFoundException for Own AP| I could manage it to run my test code with Equinox Helios (Eclipse 3.6) which implements OSGi spec 4.2 (*< 4.3*): This leads to a BundleException for OpenCMIS OSGi Client Wrapper as assumed above (cause of missing *.wiring package) and therefore OpenCMIS OSGi Client bundle obviously never gets resolved. This is no problem for me in my environment (probably no problem for most OSGi clients) but I wanted mention it. >From my point of view you can resolve this issue ... *jippiee* ;) was (Author: shomeier): Positively tested with following conditions (AP = AuthenticationProvider, OF = ObjectFactory): ||Bundles in framework||OpenCMIS Manifest Header||SessionParam||Test Result|| |No AP-Bundle, No OF-Bundle|-|No AP/OF classes|OpenCMIS Standard AP and OF was taken| |No AP-Bundle, No OF-Bundle|-| AUTHENTICATION_PROVIDER_CLASS set to own AP Impl|ClassNotFoundException for own AP Impl| |No AP-Bundle, No OF-Bundle|-| OBJECT_FACTORY_CLASS set to own OF Impl|ClassNotFoundException for own OF Impl| |No AP-Bundle, Own OF-Bundle|OF-Bundle: OpenCMIS-SPI set to own OF Impl|OBJECT_FACTORY_CLASS set to own OF Impl|Own OF Impl was taken by OpenCMIS| |No AP-Bundle, Own OF-Bundle|OF-Bundle: OpenCMIS-SPI set to non-existing class|OBJECT_FACTORY_CLASS set to own OF Impl|ClassNotFoundException for own OF Impl| |Own AP-Bundle, No OF-Bundle|AP-Bundle: OpenCMIS-SPI set to own AP Impl|AUTHENTICATION_PROVIDER_CLASS set to own AP Impl|Own AP was taken by OpenCMIS| |Own AP-Bundle, Own OF-Bundle|AP-Bundle: OpenCMIS-SPI set to own AP Impl; OF-Bundle: OpenCMIS-SPI set to own OF Impl|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Own AP and OF was taken by OpenCMIS| |Own AP-Bundle, Own OF-Bundle|AP-Bundle: No OpenCMIS-SPI set; OF-Bundle: OpenCMIS-SPI set to own OF Impl set|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|ClassNotFoundException for own AP Impl| |Own 2 in 1 Bundle containing Own AP and Own OF Impl|OpenCMIS-SPI String contains FQCN for Own AP and Own OF Impl Class (separaetd by comma)|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Own AP and Own OF Impl was taken by OpenCMIS| |Own 2 in 1 Bundle containing Two Own AP and Own OF Impl|OpenCMIS-SPI String contains FQCN for Both Own AP Impl and Own OF Impl Class (separated by comma)|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|Proper Own AP Impl and Own OF Impl was taken by OpenCMIS| |No Bundle containing AP/OF Impl|-|OBJECT_FACTORY_CLASS and AUTHENTICATION_PROVIDER_CLASS set to own AP/OF Impl|ClassNotFoundException for Own AP| I could manage it to run my test code with Equinox Helios (Eclipse 3.6) which implements OSGi spec 4.2 (*< 4.3*): This leads to a BundleException for OpenCMIS OSGi Client Wrapper as assumed above (cause of missing *.wiring package) and therefore OpenCMIS OSGi Client bundle obviously never gets resolved. This is no problem for me in my environment (probably no problem for most OSGi clients) but I wanted mention it. >From my point of view you can resolve this issue ... *jippiee* ;) > Allow loading classes from other OSGi Bundles in OSGi Client Wrapper > -------------------------------------------------------------------- > > Key: CMIS-878 > URL: https://issues.apache.org/jira/browse/CMIS-878 > Project: Chemistry > Issue Type: Improvement > Components: opencmis-client > Affects Versions: OpenCMIS 0.12.0 > Environment: OSGi > Reporter: Sascha Homeier > Assignee: Florian Müller > Priority: Minor > > When using the OpenCMIS OSGi Client Wrapper it is hard to load classes from > other bundles. For example if you specify an own Authentication Provider > class as Session Parameter then the Wrapper will not find this class when it > is located inside another bundle. Same problem should occur when defining an > own Cache. > *1)* > It would be nice if other bundles could register their Classloaders so that > ClassLoaderUtil can use it when trying to load classes. > *2)* > Another simpler option would be to simply add "DynamicImport-Package: *" to > the Manifest of the Wrapper. By doing this the Wrapper will find all classes > which are exported by other bundles. Though this approach feels more like a > hack since it breaks modularity. > What do you think about it? > Cheers > Sascha -- This message was sent by Atlassian JIRA (v6.3.4#6332)