[
https://issues.apache.org/jira/browse/CMIS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14547223#comment-14547223
]
Sascha Homeier edited comment on CMIS-878 at 5/17/15 4:27 PM:
--------------------------------------------------------------
So if you are ok with this approach in general I implemented a first try which
hopefully is a good starting point.
Please see my fork here:
https://github.com/shomeier/chemistry-opencmis
(Only touched
[Activator|https://github.com/shomeier/chemistry-opencmis/blob/trunk/chemistry-opencmis-client/chemistry-opencmis-client-impl/src/main/java/org/apache/chemistry/opencmis/client/osgi/Activator.java]
and
[SessionFactoryImpl|https://github.com/shomeier/chemistry-opencmis/blob/trunk/chemistry-opencmis-client/chemistry-opencmis-client-impl/src/main/java/org/apache/chemistry/opencmis/client/runtime/SessionFactoryImpl.java])
I used the same approach as in ServiceMix Specs Bundle but adjusted that
approach a bit to use Manifest-Header instead of ServiceLoaders (if you prefer
SL we can also use that). I also put the OsgiClassLoaderLocator inside the
SessionFactoryImpl (to not introduce dependency from SessionFactory to *.osgi
package).
Please let me know what you think.
I set up a small OSGi test environment with Mock ObjectFactories and
AuthenticationProviders here:
https://github.com/shomeier/chemistry-opencmis-osgi-client-itest
Setup explained in README.md.
(Maybe later it might be nice to add some automated junit itests (PaxExam or
so) to prevent regression)
_Edit:_
I did not yet remove the Sysouts which I used for debugging when testing with
stopping/uninstalling bundles in the OSGi console.
The jar which is used inside the OSGi test environment is build with current
codebase in my chemistry fork. So you can trace where the log was done...
was (Author: shomeier):
So if you are ok with this approach in general I implemented a first try which
hopefully is a good starting point.
Please see my fork here:
https://github.com/shomeier/chemistry-opencmis
(Only touched
[Activator|https://github.com/shomeier/chemistry-opencmis/blob/trunk/chemistry-opencmis-client/chemistry-opencmis-client-impl/src/main/java/org/apache/chemistry/opencmis/client/osgi/Activator.java]
and
[SessionFactoryImpl|https://github.com/shomeier/chemistry-opencmis/blob/trunk/chemistry-opencmis-client/chemistry-opencmis-client-impl/src/main/java/org/apache/chemistry/opencmis/client/runtime/SessionFactoryImpl.java])
I used the same approach as in ServiceMix Specs Bundle but adjusted that
approach a bit to use Manifest-Header instead of ServiceLoaders (if you prefer
SL we can also use that). I also put the OsgiClassLoaderLocator inside the
SessionFactoryImpl (to not introduce dependency from SessionFactory to *.osgi
package).
Please let me know what you think.
I set up a small OSGi test environment with Mock ObjectFactories and
AuthenticationProviders here:
https://github.com/shomeier/chemistry-opencmis-osgi-client-itest
Setup explained in README.md.
(Maybe later it might be nice to add some automated junit itests (PaxExam or
so) to prevent regression)
> 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
> 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)
