[ 
https://issues.apache.org/jira/browse/CMIS-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534241#comment-14534241
 ] 

Sascha Homeier commented on CMIS-878:
-------------------------------------

Good catch. The OSGi services are set globally for the SessionFactory.
This issue also came to my mind yesterday evening and my first thought was 
about a 0..n binding of services and selecting the proper one via SessionParams.
(Also asked myself if this ever occurs in the wild but as you catched that 
problem that fast it seems to be a thinkable use case)

So lets take AuthenticationProvider for example:
Activator:
{code}
...
// get 0..n Authentication Providers services
List<AuthenticationProvider> authenticationProviders = 
getAuthenticationProviders(context);
...

// get new instance of SesisonFactory and inject the services
// if no services were found then lists with size = 0 are passed instead of null
SessionFactoryImpl sessionFactory = 
SessionFactoryImpl.newInstance(objectFactories, authenticationProviders,
                caches, typeDefCaches);
...
{code}

In SessionFactoryImpl:
{code}
...
public Session createSession(Map<String, String> parameters) {

        // placeholder for auth provider to use on this session
        AuthenticationProvider authProvider = null;

        // FQCN of the auth provider to use in this session (taken from 
SessionParameter)
        String authProviderClass = 
parameters.get(SessionParameter.AUTHENTICATION_PROVIDER_CLASS);

        // iterate over the bound auth provider services to find the proper one 
to use
        // for this session (class name must match the SessionParameter class 
name)
        // if no services were injected from OSGi activator then 
authenticationProviders list is empty and session is created with null 
authProvider
        for (AuthenticationProvider ap : this.authenticationProviders) {

            if (ap.getClass().getName().equals(authProviderClass)) {
                authProvider = ap;
            }
        }
        // if no match was found the session is created the old way with 
authProvider = null
        // this leads to loading the authProvider from SessionParameter via 
ClassUtil as usually
        
        // ... do the same of objectFactory, cache and typeDefCache
        
        return createSession(parameters, objectFactory, authProvider, cache, 
typeDefCache);
}
...
{code}

Does this makes sense?

Imho such an approach is much less intrusive then passing class loaders (I 
think that would lead to more code changes).
I can remove Cache and TypeDefCache because theses interfaces are not in 
public/exported packages.

> 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)

Reply via email to