Emmanuel J created FELIX-5285:
---------------------------------

             Summary: iPojo does not delegate to 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)

Reply via email to