Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <2001631650.17181267568547191.JavaMail.jira@brutus.apache.org>
Date: Tue, 2 Mar 2010 22:22:27 +0000 (UTC)
From: "Guillaume Nodet (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-1531) Mandatory directive is ignored on
 the Export-Package when it comes to resolve the bundles
In-Reply-To: <1503763543.1251322319282.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840357#action_12840357 ] 

Guillaume Nodet commented on FELIX-1531:
----------------------------------------

You're right.  And sorry about not describing the behavior, I did not meant to be harsh.

I agree that the current approach is flawed, but I think I also understand why it was taken.  The main reason (I think) is that in the repository xml, we don't have the full manifest header for the imported packages, we only have a filter.    The meaning of the mandatory directive is to ensure that any attribute marked as mandatory will be requested by the importer.  This implies  that to be able to satisfy the mandatory directive, we'd have to understand what the filter means and how it is composed.
I think that's way easier in your case because you don't have a real filter, you actually build it from the manifest in a way where verifying that the attribute is requested is actually easily doable.

I originally wanted to modify the filter to add the missing clause, i.e. in case where the mandatory directive isn't verified, build a new filter like:
   (&(old-filter)(!(mandatory:=*)))
but modifying the filter did not really sound a good idea is I did not want to make that visible to the user.

It may be possible to actually verify if the filter includes tests on the mandatory attributes, but at the end if would still make some assumption about how the filter has been generated.  

So we have multiple ways to solve the problem imho:
  * keep the current hack (i.e. either the filter test the mandatory attribtues or there are no mandatory attributes)
  * modify bindex / maven bundle plugin to add the missing clause for testing there are no mandatory attributes
  * try to verify that the filter includes tests on all mandatory attributes

I don't have a strong opinion for any solution.  I just thought the first one would minimize the overhead at runtime.

> Mandatory directive is ignored on the Export-Package when it comes to resolve the bundles
> -----------------------------------------------------------------------------------------
>
>                 Key: FELIX-1531
>                 URL: https://issues.apache.org/jira/browse/FELIX-1531
>             Project: Felix
>          Issue Type: Bug
>          Components: Bundle Repository (OBR)
>    Affects Versions: bundlerepository-1.4.3
>         Environment: not applicable
>            Reporter: hehe ji
>            Assignee: Guillaume Nodet
>             Fix For: bundlerepository-1.6.0
>
>
> When I try to resolve a bundle (bundleFooImport.jar) with the following manifest:
> Import-Package: a.b.c;company=foo
> In the bundle repository, I have a bundle (bundleFoo.jar) with the following manifest:
> Export-Package:a.b.c;version=3;company=foo;security=true;mandatory:="company,security"
> The repository.xml for the bundleFoo.jar 
> <capability name='package'>
>       <p n='company' v='foo'/>
>         <p n='mandatory:' t='set' v='company,security'/>
>       <p n='package' v='a.b.c'/>
>       <p n='security' v='true'/>
>       <p n='version' t='version' v='3.0.0'/>
>     </capability>
> For some reason, the felix resolve resolves the bundleFooImport.jar with bundle bundleFoo.jar, which is wrong. According to the osgi specification, bundleFoo.jar bundle insists the bundle imports specifying company and security attributes, which was not the case of bundleFooImport.jar. Clearly, the felix implementation of the mandatory directive is NOT correct.
> Please let me know if you need any more details.
> Thanks
> Hehe

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.