[
https://issues.apache.org/jira/browse/CMIS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298705#comment-14298705
]
Sascha Homeier commented on CMIS-878:
-------------------------------------
Yes, noticed that with tears in my eyes for server side library ;)
But thx for the info. I thought maybe the cause for this is a lack of time
and/or OSGi experience. Thats why I proposed that enhancement.
So maybe in that case it does not make sense to introduce such an enhancement?
For me it is more like a minor nice-to-have feature.
Until now, I am really impressed especially about the performance of the
Chemistry OpenCmis framework that I do not dare to do the low-level stuff on my
own in a more OSGi compliant manner. I was really disappointed about the
performance of the Adobe Drive CMIS Connector implementation which uses low
level Apache Abdera stuff and is simply not usable for our use case with ten
thousands of assets into one folder. With OpenCmis incl. paging and chunking
performance is great.
So in that case I can live with the fact to use workarounds to build my own
wrapper or fragments for new versions.
> 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)
