chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sascha Homeier (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CMIS-878) Allow loading classes from other OSGi Bundles in OSGi Client Wrapper
Date Fri, 08 May 2015 09:59:00 GMT

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

Mime
View raw message