[
https://issues.apache.org/jira/browse/FELIX-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel J updated FELIX-5285:
------------------------------
Summary: iPojo does not delegate to the right classloader for Nullable
Proxy instantiation (was: iPojo does not delegate to right classloader for
Nullable Proxy instantiation)
> iPojo does not delegate to the right classloader for Nullable Proxy
> instantiation
> ---------------------------------------------------------------------------------
>
> Key: FELIX-5285
> URL: https://issues.apache.org/jira/browse/FELIX-5285
> Project: Felix
> Issue Type: Bug
> Components: iPOJO
> Reporter: Emmanuel J
>
> iPojo runtime & api: 1.12.1
> Felix framework: 4.2.1
> This issue is similar to https://issues.apache.org/jira/browse/FELIX-2093
> This interface exist in v1.0 of an api and is exported by the system bundle
> (felix) A
> {code}package com.data.service
> public interface DataService
> {
> public void search(String condition);
> }{code}
> A bundle, B, imports com.data.service;version=1.0:
> {code}@Requires(optional = true)
> private DataServiceImpl dataServiceImpl;{code}
> where DataServiceImpl only implements the interface
> All is working well at this point.
> Then, the api evolves with a new method:
> {code}package com.data.service
> import com.data.service.conditions.Condition;
> public interface DataService
> {
> public void search(String condition);
> public void search(Condition condition);
> }{code}
> still exported by system bundle A but now as version 1.1
> The bundle B is not recompiled against this new version and does not import
> the new package com.data.service.conditions
> Now, when bundle B runs with v1.1 of the api, the requires of DataServiceImpl
> is failing in Dependency.createNullableObject()
> (http://felix.apache.org/ipojo/api/1.12.1/src-html/org/apache/felix/ipojo/handlers/dependency/Dependency.html
> line 433) when creating the proxy: the proxy class is created w/o issue but
> when an instance of this proxy class is done, there is a Class.forName() done
> that fails to load the class Condition because it is not imported
> Since the class Condition is already available and allows to create the proxy
> class, it would make sense to use it instead of trying to load it thru the
> bundle classloader
> To achieve this, the methods of the specification could be browsed, for each
> parameters and return types the classloader could be collected and given to
> the NullableClassLoader. All classloaders could be asked to load the class.
> At some point, the classloader of Condition would be queried and would return
> the class
> I don't know if this is breaking OSGi principles but I think it can fix this
> issue
> NB: I also tried to export the new api with uses directive:
> com.data.service;version=1.1;uses:="com.data.service.conditions"
> with no result. If I understand correctly uses directive is not supposed to
> add implicit package import to bundle B, but are only used by the OSGi
> framework to help it on the wiring process
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
