cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bosschaert (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DOSGI-20) Get rid of the DynamicImport-Package="*"
Date Fri, 15 Nov 2013 09:09:24 GMT

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

David Bosschaert commented on DOSGI-20:
---------------------------------------

Ok, let's zoom in on the actual problem...

If I'm not mistaken the problem lies in the first line of code in RemoteServiceAdminCore.proxifyMatchingInterface()
where it does:
  Class<?> iClass = bctx.getBundle().loadClass(interfaceName);
where interfaceName is the name of the interface of the remote service that needs to be proxied.

Currently the bctx bundle used to load this class seems to be always the CXF-DSW bundle, which
is why it needs DynamicImport-Package.
If we can get that line of code to use the right bundle (which has an import to that package)
to load the class that would probably fix this issue... (unless I'm missing something)

One option would be to use PackageAdmin, or better the Bundle Wiring API, to find the bundle
that exports the API in the right version and use its Bundle Context at the above line in
the code. There is an issue here in that if you find two exporters, who do you pick? If you
pick the wrong one the client may not be able to use the proxy...

Probably a better choice would be to use the bundle of the requesting class. 
bq.  The problem is that we do not know the bundle at the point in the code where we need
to create the class

this is true at the above line of code. However I think that we could delay the line of code
above to a later point where we do have the client bundle's context. Later in the proxifyMatchingInterface()
you can see that it registers a Service Factory: ClientServiceFactory. The first time you
actually really need that iClass is inside that ClientServiceFactory.getService(). That method
is invoked by the OSGi Service Registry with the actual requestingBundle as its first argument.
So if we could delay the loadClass to happen inside that getService() we could simply do requestingBundle.loadClass()
and can probably get rid of the DynamicImport-Package...

Note that proxifyMatchingInterface() also has a requestingContext parameter but this does
actually not contain the right value as it's always set to the CXF-DSW bundle context. That
parameter is confusing and should really be removed...

Anyway, I might have missed a point or two, but the above might help...

> Get rid of the DynamicImport-Package="*"
> ----------------------------------------
>
>                 Key: DOSGI-20
>                 URL: https://issues.apache.org/jira/browse/DOSGI-20
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>            Reporter: David Bosschaert
>
> The current DOSGi implementation uses DynamicImport-Package="*". While this is very convenient,
it is potentially unpredictable and could have serious performance side effects. Therefore
it would be better to remove this dependency and potentially use direct OSGi API to find the
required package potentially via the PackageAdmin only when we need to do this type of thing
i.e. when a proxy is created.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message