[
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:00 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 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).
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).
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)
