[jira] [Commented] (FELIX-3159) src plugin hangs on "innocent" comment in java file
[ https://issues.apache.org/jira/browse/FELIX-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129547#comment-13129547 ] Carsten Ziegeler commented on FELIX-3159: - I've just deployed the latest snapshots > src plugin hangs on "innocent" comment in java file > --- > > Key: FELIX-3159 > URL: https://issues.apache.org/jira/browse/FELIX-3159 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.7.2 >Reporter: Andrei Pozolotin > > src plugin hangs on "innocent" comment in java file; > 1) test case project: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-003 > 2) test case command: > mvn org.apache.felix:maven-scr-plugin:scr > 3) the combination that kills it: > a) comment in java file: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-003/src/main/java/case_03/Comp2.java > b) setting in pom.xml false > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-003/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3170) scr-maven-plugin : incremental build mode for eclipse development?
[ https://issues.apache.org/jira/browse/FELIX-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129268#comment-13129268 ] Andrei Pozolotin commented on FELIX-3170: - Stuart: your comments are extremely valuable! I was using java annotations (felix scr, not javadoc, not bnd/osgi) from the start, but was under impression that I MUST run scr plugin to convert java annotations -> scr.xml; now I will try to see how your suggested bnd java annotations -> maven-bundle-plugin -> bnd -> src.xml path works and report back; thank you! Andrei. > scr-maven-plugin : incremental build mode for eclipse development? > -- > > Key: FELIX-3170 > URL: https://issues.apache.org/jira/browse/FELIX-3170 > Project: Felix > Issue Type: New Feature > Components: Maven SCR Plugin >Reporter: Andrei Pozolotin > > Hello; > SITUATION: > I am using scr-maven-plugin in eclipse 3.7 with m2e incremental mode; > project has some 1000 java files and 100 scr components; > on every java file save, eclipse runs JDT builder and then maven invokes SRC > plugin; > as project progressed, the responsiveness of eclipse continued to dwindle > down, > now to 3...5 seconds delay on each java file edit; > QUESTIONS: > 1) is it feasible to support incremental build in scr plugin? > for this, plugin would have to: > a) keep scr components parse/build cache > b) support a new goal, when only a single file with scr annotations is > requested for processing > but still produces complete scr xml; > 2) has anyone devised a better solution to this? > thank you; > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-3170) scr-maven-plugin : incremental build mode for eclipse development?
[ https://issues.apache.org/jira/browse/FELIX-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129252#comment-13129252 ] Stuart McCulloch edited comment on FELIX-3170 at 10/17/11 10:14 PM: You could consider switching over to Java annotations, rather than javadoc annotations. For example, bndlib 1.43.0 has some (non-standard) component annotations: http://www.aqute.biz/Blog/20091020 http://www.aqute.biz/Bnd/Components http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C1.43.0%7Cjar And the draft of forthcoming updates to the OSGi spec http://www.osgi.org/download/osgi-early-draft-2011-09.pdf contains a proposal for standard Java annotations for Declarative Services (RFC 0172). A preview of these annotations will soon be available in a new bndlib, which will be included in the next maven-bundle-plugin release. The benefit of using Java annotations is that you can then get incremental compilation by virtue of the Eclipse compiler. To see this in action, try updating to the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin and import your project into Eclipse using the latest version of m2e (came bundled with 3.7, but also available on the Eclipse Marketplace). Make sure you have the latest Tycho configurators installed... go to About Eclipse->Installation Details->Installed Software, you should see: Tycho Project Configurators 0.6.0.201110151902 org.sonatype.tycho.m2e.feature.feature.groupSonatype, Inc. If you don't have this installed, go to Preferences->Maven->Discovery->Open Catalog and find the Tycho entry, select the checkbox and press the Finish button. With the latest m2e + tycho and the latest maven-bundle-plugin snapshot you can do some cool stuff. For example you can add "true" to your maven-bundle-plugin configuration to get it to automatically unpack any extra files generated by bnd. That way as you edit the class file and add Java annotations, such as @Component, m2e will trigger a refresh of the manifest and unpack the updated component XML. You shouldn't then need to use the maven-scr-plugin, since bnd (via the maven-bundle-plugin) would be transforming your component annotations into XML. was (Author: mcculls): You could consider switching over to Java annotations, rather than javadoc annotations. For example, bndlib 1.43.0 has some (non-standard) component annotations: http://www.aqute.biz/Blog/20091020 http://www.aqute.biz/Bnd/Components http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C1.43.0%7Cjar And the draft of forthcoming updates to the OSGi spec http://www.osgi.org/download/osgi-early-draft-2011-09.pdf contains a proposal for standard Java annotations for Declarative Services (RFC 0172). A preview of these annotations will soon be available in a new bndlib, which will be included in the next maven-bundle-plugin release. The benefit of using runtime Java annotations is that you can then get incremental compilation by virtue of the Eclipse compiler. To see this in action, try updating to the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin and import your project into Eclipse using the latest version of m2e (came bundled with 3.7, but also available on the Eclipse Marketplace). Make sure you have the latest Tycho configurators installed... go to About Eclipse->Installation Details->Installed Software, you should see: Tycho Project Configurators 0.6.0.201110151902 org.sonatype.tycho.m2e.feature.feature.groupSonatype, Inc. If you don't have this installed, go to Preferences->Maven->Discovery->Open Catalog and find the Tycho entry, select the checkbox and press the Finish button. With the latest m2e + tycho and the latest maven-bundle-plugin snapshot you can do some cool stuff. For example you can add "true" to your maven-bundle-plugin configuration to get it to automatically unpack any extra files generated by bnd. That way as you edit the class file and add Java annotations, such as @Component, m2e will trigger a refresh of the manifest and unpack the updated component XML. You shouldn't then need to use the maven-scr-plugin, since bnd (via the maven-bundle-plugin) would be transforming your component annotations into XML. > scr-maven-plugin : incremental build mode for eclipse development? > -- > > Key: FELIX-3170 > URL: https://issues.apache.org/jira/browse/FELIX-3170 > Project: Felix > Issue Type: New Feature > Components: Maven SCR Plugin >Reporter: Andrei Pozolotin > > Hello; > SITUATION: > I am using scr-maven-plugin in eclipse 3.7 with m2e incremental mode; > project has some 1000 java files and 100 scr components; > on every java file save, eclipse run
[jira] [Issue Comment Edited] (FELIX-3170) scr-maven-plugin : incremental build mode for eclipse development?
[ https://issues.apache.org/jira/browse/FELIX-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129252#comment-13129252 ] Stuart McCulloch edited comment on FELIX-3170 at 10/17/11 10:10 PM: You could consider switching over to Java annotations, rather than javadoc annotations. For example, bndlib 1.43.0 has some (non-standard) component annotations: http://www.aqute.biz/Blog/20091020 http://www.aqute.biz/Bnd/Components http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C1.43.0%7Cjar And the draft of forthcoming updates to the OSGi spec http://www.osgi.org/download/osgi-early-draft-2011-09.pdf contains a proposal for standard Java annotations for Declarative Services (RFC 0172). A preview of these annotations will soon be available in a new bndlib, which will be included in the next maven-bundle-plugin release. The benefit of using runtime Java annotations is that you can then get incremental compilation by virtue of the Eclipse compiler. To see this in action, try updating to the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin and import your project into Eclipse using the latest version of m2e (came bundled with 3.7, but also available on the Eclipse Marketplace). Make sure you have the latest Tycho configurators installed... go to About Eclipse->Installation Details->Installed Software, you should see: Tycho Project Configurators 0.6.0.201110151902 org.sonatype.tycho.m2e.feature.feature.groupSonatype, Inc. If you don't have this installed, go to Preferences->Maven->Discovery->Open Catalog and find the Tycho entry, select the checkbox and press the Finish button. With the latest m2e + tycho and the latest maven-bundle-plugin snapshot you can do some cool stuff. For example you can add "true" to your maven-bundle-plugin configuration to get it to automatically unpack any extra files generated by bnd. That way as you edit the class file and add Java annotations, such as @Component, m2e will trigger a refresh of the manifest and unpack the updated component XML. You shouldn't then need to use the maven-scr-plugin, since bnd (via the maven-bundle-plugin) would be transforming your component annotations into XML. was (Author: mcculls): You could consider switching over to Java annotations, rather than javadoc annotations. For example, bndlib 1.43.0 has some (non-standard) component annotations: http://www.aqute.biz/Blog/20091020 http://www.aqute.biz/Bnd/Components http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C1.43.0%7Cjar And the draft of forthcoming updates to the OSGi spec http://www.osgi.org/download/osgi-early-draft-2011-09.pdf contains a proposal for standard Java annotations for Declarative Services (RFC 0172). A preview of these annotations will soon be available in a new bndlib, which will be included in the next maven-bundle-plugin release. The benefit of using runtime Java annotations is that you can then get incremental compilation by virtue of the Eclipse compiler. To see this in action, try updating to the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin and import your project into Eclipse using the latest version of m2e (came bundled with 3.7, but also available on the Eclipse Marketplace). Make sure you have the latest Tycho configurators installed... go to About Eclipse->Installation Details->Installed Software, you should see: Tycho Project Configurators 0.6.0.201110151902 org.sonatype.tycho.m2e.feature.feature.groupSonatype, Inc. If you don't have this installed, go to Preferences->Maven->Discovery->Open Catalog and find the Tycho entry, select the checkbox and press the Finish button. With the latest m2e + tycho and the latest maven-bundle-plugin snapshot you can do some cool stuff. For example you can add "true" to your maven-bundle-plugin configuration to get it to automatically unpack any extra files generated by bnd. That way as you edit the class file and add Java annotations, such as @Component, m2e will trigger a refresh of the manifest and unpack the updated component XML. > scr-maven-plugin : incremental build mode for eclipse development? > -- > > Key: FELIX-3170 > URL: https://issues.apache.org/jira/browse/FELIX-3170 > Project: Felix > Issue Type: New Feature > Components: Maven SCR Plugin >Reporter: Andrei Pozolotin > > Hello; > SITUATION: > I am using scr-maven-plugin in eclipse 3.7 with m2e incremental mode; > project has some 1000 java files and 100 scr components; > on every java file save, eclipse runs JDT builder and then maven invokes SRC > plugin; > as project progressed, the responsiveness of eclipse continued to dwindle > down, > now to
[jira] [Commented] (FELIX-3170) scr-maven-plugin : incremental build mode for eclipse development?
[ https://issues.apache.org/jira/browse/FELIX-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129252#comment-13129252 ] Stuart McCulloch commented on FELIX-3170: - You could consider switching over to Java annotations, rather than javadoc annotations. For example, bndlib 1.43.0 has some (non-standard) component annotations: http://www.aqute.biz/Blog/20091020 http://www.aqute.biz/Bnd/Components http://search.maven.org/#artifactdetails%7Cbiz.aQute%7Cbndlib%7C1.43.0%7Cjar And the draft of forthcoming updates to the OSGi spec http://www.osgi.org/download/osgi-early-draft-2011-09.pdf contains a proposal for standard Java annotations for Declarative Services (RFC 0172). A preview of these annotations will soon be available in a new bndlib, which will be included in the next maven-bundle-plugin release. The benefit of using runtime Java annotations is that you can then get incremental compilation by virtue of the Eclipse compiler. To see this in action, try updating to the latest 2.4.0-SNAPSHOT of the maven-bundle-plugin and import your project into Eclipse using the latest version of m2e (came bundled with 3.7, but also available on the Eclipse Marketplace). Make sure you have the latest Tycho configurators installed... go to About Eclipse->Installation Details->Installed Software, you should see: Tycho Project Configurators 0.6.0.201110151902 org.sonatype.tycho.m2e.feature.feature.groupSonatype, Inc. If you don't have this installed, go to Preferences->Maven->Discovery->Open Catalog and find the Tycho entry, select the checkbox and press the Finish button. With the latest m2e + tycho and the latest maven-bundle-plugin snapshot you can do some cool stuff. For example you can add "true" to your maven-bundle-plugin configuration to get it to automatically unpack any extra files generated by bnd. That way as you edit the class file and add Java annotations, such as @Component, m2e will trigger a refresh of the manifest and unpack the updated component XML. > scr-maven-plugin : incremental build mode for eclipse development? > -- > > Key: FELIX-3170 > URL: https://issues.apache.org/jira/browse/FELIX-3170 > Project: Felix > Issue Type: New Feature > Components: Maven SCR Plugin >Reporter: Andrei Pozolotin > > Hello; > SITUATION: > I am using scr-maven-plugin in eclipse 3.7 with m2e incremental mode; > project has some 1000 java files and 100 scr components; > on every java file save, eclipse runs JDT builder and then maven invokes SRC > plugin; > as project progressed, the responsiveness of eclipse continued to dwindle > down, > now to 3...5 seconds delay on each java file edit; > QUESTIONS: > 1) is it feasible to support incremental build in scr plugin? > for this, plugin would have to: > a) keep scr components parse/build cache > b) support a new goal, when only a single file with scr annotations is > requested for processing > but still produces complete scr xml; > 2) has anyone devised a better solution to this? > thank you; > Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: please keep moderately up to date publishing snapshots
On 17 Oct 2011, at 22:12, David Jencks wrote: > Could someone with the appropriate permissions please deploy snapshots of > utils and bundlerepository? For some reason my build keeps pulling down the > antique snapshots in apache nexus and I have to rebuild the projects every > day. ...done > thanks > david jencks
please keep moderately up to date publishing snapshots
Could someone with the appropriate permissions please deploy snapshots of utils and bundlerepository? For some reason my build keeps pulling down the antique snapshots in apache nexus and I have to rebuild the projects every day. thanks david jencks
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129115#comment-13129115
]
Rob Walker commented on FELIX-3160:
---
Might take me a couple of days to get to it but will see if I can figure what
sequence of start, restart and uninstall are needed to trigger this every time.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3148) ipojo - auto handlers - issue in plugging the auto-handler to a particular component ( without making any changes in POJO component)
[ https://issues.apache.org/jira/browse/FELIX-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128994#comment-13128994 ] sadishkumar commented on FELIX-3148: Hi, If we use LDAP filter, is it possible to change the "LDAP filter String or Value" dynamically during runtime? If it’s not dynamic during runtime, it will not be helpful for us. But we have an alternate proposal to achieve this scenario, Can I send as a document to your email? (only In case, it could not be dynamic) Thanks, Sadish > ipojo - auto handlers - issue in plugging the auto-handler to a particular > component ( without making any changes in POJO component) > > > Key: FELIX-3148 > URL: https://issues.apache.org/jira/browse/FELIX-3148 > Project: Felix > Issue Type: Improvement > Components: iPOJO >Affects Versions: iPOJO-1.8.0 >Reporter: sadishkumar > Labels: features > > To avoid the problem of attaching the Auto-handlers (which are listed in the > system property) to all the component's instances unnecessarily. To make it > more specific & dynamic to particular components, > The auto-handlers can have annotations like this "@handle (component-1, > component-2,...)". > This ipojo annotations can be used by handlers to be automatically plugged > into instances of the specific list of components given as parameter in the > bracket (here for example: component-1, component-2..;etc. are component > names). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3159) src plugin hangs on "innocent" comment in java file
[ https://issues.apache.org/jira/browse/FELIX-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128963#comment-13128963 ] Andrei Pozolotin commented on FELIX-3159: - Carsten: any chance to push out a snapshot? https://repository.apache.org/content/groups/snapshots/org/apache/felix/maven-scr-plugin/ > src plugin hangs on "innocent" comment in java file > --- > > Key: FELIX-3159 > URL: https://issues.apache.org/jira/browse/FELIX-3159 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin-1.7.2 >Reporter: Andrei Pozolotin > > src plugin hangs on "innocent" comment in java file; > 1) test case project: > https://github.com/carrot-garden/carrot-bugger/tree/master/carrot-bug-scr-maven-plugin-003 > 2) test case command: > mvn org.apache.felix:maven-scr-plugin:scr > 3) the combination that kills it: > a) comment in java file: > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-003/src/main/java/case_03/Comp2.java > b) setting in pom.xml false > https://github.com/carrot-garden/carrot-bugger/blob/master/carrot-bug-scr-maven-plugin-003/pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Java 5 generics
On 10/17/11 11:20 , Lucas Galfaso wrote: Hi all, I've been looking into the framework code and there are large parts of it that do not use Java 5 generics. Is there some interest in changing the code so the type erasure versions are not used? This is a task that I would be willing to take. There wasn't any attempt to convert everything over to generic, I've just converted over various pieces as I went along. If you are interested in contributing to this, feel free. Just open up an issue and attach patches. I'd recommend doing your patches in smaller chunks to make them easier to review. If you end up having questions, just asking on the issue you create. Thanks! And a question to people that have access to the standard committee; are there any plans to compile without the -target jsr14 flag? Not of which I'm aware. There'd have to be a decision to no longer support older/smaller VMs first. -> richard Thanks, Lucas
[jira] [Created] (FELIX-3170) scr-maven-plugin : incremental build mode for eclipse development?
scr-maven-plugin : incremental build mode for eclipse development? -- Key: FELIX-3170 URL: https://issues.apache.org/jira/browse/FELIX-3170 Project: Felix Issue Type: New Feature Components: Maven SCR Plugin Reporter: Andrei Pozolotin Hello; SITUATION: I am using scr-maven-plugin in eclipse 3.7 with m2e incremental mode; project has some 1000 java files and 100 scr components; on every java file save, eclipse runs JDT builder and then maven invokes SRC plugin; as project progressed, the responsiveness of eclipse continued to dwindle down, now to 3...5 seconds delay on each java file edit; QUESTIONS: 1) is it feasible to support incremental build in scr plugin? for this, plugin would have to: a) keep scr components parse/build cache b) support a new goal, when only a single file with scr annotations is requested for processing but still produces complete scr xml; 2) has anyone devised a better solution to this? thank you; Andrei. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Java 5 generics
Hi all, I've been looking into the framework code and there are large parts of it that do not use Java 5 generics. Is there some interest in changing the code so the type erasure versions are not used? This is a task that I would be willing to take. And a question to people that have access to the standard committee; are there any plans to compile without the -target jsr14 flag? Thanks, Lucas
[jira] [Closed] (FELIX-3166) Make Felix compile within Eclipse
[ https://issues.apache.org/jira/browse/FELIX-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lucas Galfaso closed FELIX-3166. Thanks > Make Felix compile within Eclipse > - > > Key: FELIX-3166 > URL: https://issues.apache.org/jira/browse/FELIX-3166 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso >Assignee: Richard S. Hall >Priority: Minor > Fix For: framework-4.2.0 > > Attachments: FELIX-3166.diff > > > Even when javac using -target jsr14 does take care of the type erasure, > Eclipse is not as cleaver and does not compile > EventDispatcher::createWhitelistFromHooks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128917#comment-13128917
]
Richard S. Hall commented on FELIX-3160:
I'm still not able to recreate, so I guess we'll have to try to recreate the
exact scenario. If you can come up with something, let me know. Otherwise, I'll
tinker around with it later and see if I can come up with something.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128896#comment-13128896
]
Richard S. Hall commented on FELIX-3160:
Yeah, I think Karl is correct. I'll look into it again later, thanks.
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3166) Make Felix compile within Eclipse
[ https://issues.apache.org/jira/browse/FELIX-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall resolved FELIX-3166. Resolution: Fixed Fix Version/s: framework-4.2.0 Assignee: Richard S. Hall I've applied your patch, please close if satisfied. Thanks. > Make Felix compile within Eclipse > - > > Key: FELIX-3166 > URL: https://issues.apache.org/jira/browse/FELIX-3166 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.0.0 >Reporter: Lucas Galfaso >Assignee: Richard S. Hall >Priority: Minor > Fix For: framework-4.2.0 > > Attachments: FELIX-3166.diff > > > Even when javac using -target jsr14 does take care of the type erasure, > Eclipse is not as cleaver and does not compile > EventDispatcher::createWhitelistFromHooks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128819#comment-13128819
]
Karl Pauls commented on FELIX-3163:
---
Look, having your policy bundle be the one that you don't trust doesn't sound
like a good idea. Try to follow the steps I outlined above (and yes, that
implies to create a separate bundle that does set-up your policy).
Regarding ordering, yes, the order (i.e., sequence) is important. Regarding,
material to read: http://www.manning.com/hall/ has a chapter on security that
walks you through what you need to know and do as well as example code for what
you are trying to do (full disclosure: I'm one of the authors and in this case
the author of the chapter).
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.gogo.command [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wir
> ing.package;
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=pro
> visional)(version>=0.10.0)(!(version>=1.0.0)))
>
[jira] [Created] (FELIX-3169) Add support for new PASSWORD attribute type of Metatype service
Add support for new PASSWORD attribute type of Metatype service
Key: FELIX-3169
URL: https://issues.apache.org/jira/browse/FELIX-3169
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr annotations 1.6.0, scr generator 1.1.2
Reporter: Felix Meschberger
To complement support for the new PASSWORD attribute type of the Metatype
service (see FELIX-3167) the SCR plugin should add support for this type, too:
Probably by adding a new
String[] passwordValue() default {};
definition which causes the metatype descriptor to use the PASSWORD type and
the DS descriptor to use String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128806#comment-13128806
]
Yanni Yan commented on FELIX-3163:
--
Actually, the policy bundle and the bundle without filepermission is the same
one(file\:plugins/First_1.0.0.0.jar).
What you mean is about the sequence of permission?
I changed the sequence, cpa.txt:
0-5284605870180915488=DENY {
[org.osgi.service.condpermadmin.BundleLocationCondition
"file\:plugins/First_1.0.0.0.jar"] (java.io.FilePermission "<>"
"write") } "5284605870180915488"
1--8749409404439381141=ALLOW {
[org.osgi.service.condpermadmin.BundleLocationCondition "file\:*"]
(java.security.AllPermission "*" "*") } "-8749409404439381141"
But it's still not work. I wonder if I should give all permission to all
bundles except my bundle(file\:plugins/First_1.0.0.0.jar).
I want to know how the felix check the permission. Do you have any metrial to
read?
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.gogo.command [
Please test latest maven-bundle-plugin snapshot
Hi folks, The latest snapshot of the maven-bundle-plugin (2.4.0-20111017.104855-8) contains several fixes as well as a fresh update to bndlib (this update is not yet published to maven central, so I've just included it locally for the moment). The current bnd fixes are listed under https://github.com/bnd/bnd/issues?state=closed and the bundleplugin fixes are listed underhttps://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12318541&projectId=12310100 We'd like to get people to test this snapshot as early as possible on their projects so we can iron out any potential issues and make sure this is a rock-solid release. To try this snapshot, either build the plugin locally from trunk or add the following entry to your pom.xml: apache.snapshots snapshot plugins http://repository.apache.org/snapshots false true Then just update the maven-bundle-plugin version in your pom.xml to 2.4.0-SNAPSHOT and rebuild to test it out. Report any regressions/problems to https://issues.apache.org/jira/browse/FELIX/component/12311143 ... the sooner they're reported, the sooner they can be fixed :) -- Cheers, Stuart
[jira] [Resolved] (FELIX-3037) Plugin does not work with Java 5
[ https://issues.apache.org/jira/browse/FELIX-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch resolved FELIX-3037. - Resolution: Fixed Fixed in trunk (included local copy of bndlib 1.47 - this will be replaced by a proper dependency in the pom once bndlib has been fully tested and published to central). > Plugin does not work with Java 5 > > > Key: FELIX-3037 > URL: https://issues.apache.org/jira/browse/FELIX-3037 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.3.5 >Reporter: Carsten Ziegeler >Assignee: Stuart McCulloch > Fix For: maven-bundle-plugin-2.3.6 > > > When trying to build projects with the latest maven bundle plugin and Java 5, > I get: > INFO] > [INFO] --- maven-bundle-plugin:2.3.5:bundle (default-bundle) @ > org.apache.felix.eventadmin --- > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 19.227s > [INFO] Finished at: Wed Jul 13 16:01:41 CEST 2011 > [INFO] Final Memory: 8M/21M > [INFO] > > [ERROR] Failed to execute goal > org.apache.felix:maven-bundle-plugin:2.3.5:bundle (default-bundle) on project > org.apache.felix.eventadmin: Execution default-bundle of goal > org.apache.felix:maven-bundle-plugin:2.3.5:bundle failed: An API > incompatibility was encountered while executing > org.apache.felix:maven-bundle-plugin:2.3.5:bundle: > java.lang.NoSuchMethodError: > java.lang.String.getBytes(Ljava/nio/charset/Charset;)[B > [ERROR] - > [ERROR] realm =plugin>org.apache.felix:maven-bundle-plugin:2.3.5 > [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > [ERROR] urls[0] = > file:/Users/cziegeler/.m2/repository/org/apache/felix/maven-bundle-plugin/2.3.5/maven-bundle-plugin-2.3.5.jar > [ERROR] urls[1] = > file:/Users/cziegeler/.m2/repository/biz/aQute/bndlib/1.43.0/bndlib-1.43.0.jar > [ERROR] urls[2] = > file:/Users/cziegeler/.m2/repository/org/apache/felix/org.apache.felix.bundlerepository/1.6.6/org.apache.felix.bundlerepository-1.6.6.jar > [ERROR] urls[3] = > file:/Users/cziegeler/.m2/repository/org/osgi/org.osgi.core/4.1.0/org.osgi.core-4.1.0.jar > [ERROR] urls[4] = > file:/Users/cziegeler/.m2/repository/org/easymock/easymock/2.4/easymock-2.4.jar > [ERROR] urls[5] = > file:/Users/cziegeler/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.0.7/maven-reporting-api-2.0.7.jar > [ERROR] urls[6] = > file:/Users/cziegeler/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar > [ERROR] urls[7] = > file:/Users/cziegeler/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > [ERROR] urls[8] = > file:/Users/cziegeler/.m2/repository/commons-cli/commons-cli/1.0/commons-cli-1.0.jar > [ERROR] urls[9] = > file:/Users/cziegeler/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar > [ERROR] urls[10] = > file:/Users/cziegeler/.m2/repository/org/apache/maven/maven-archiver/2.4.1/maven-archiver-2.4.1.jar > [ERROR] urls[11] = > file:/Users/cziegeler/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0/plexus-archiver-1.0.jar > [ERROR] urls[12] = > file:/Users/cziegeler/.m2/repository/org/codehaus/plexus/plexus-io/1.0/plexus-io-1.0.jar > [ERROR] urls[13] = > file:/Users/cziegeler/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.13/plexus-interpolation-1.13.jar > [ERROR] urls[14] = > file:/Users/cziegeler/.m2/repository/org/apache/maven/shared/maven-dependency-tree/1.2/maven-dependency-tree-1.2.jar > [ERROR] urls[15] = > file:/Users/cziegeler/.m2/repository/org/codehaus/plexus/plexus-utils/2.1/plexus-utils-2.1.jar > [ERROR] Number of foreign imports: 1 > [ERROR] import: Entry[import from realm > ClassRealm[project>org.apache.felix:org.apache.felix.eventadmin:1.2.13-SNAPSHOT, > parent: ClassRealm[maven.api, parent: null]]] > This can be reproduced for example with the Felix EventAdmin project > Switching to Java 6 solves the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128788#comment-13128788
]
Karl Pauls commented on FELIX-3163:
---
Well, you give all permission first -- hence, all bundles have allpermission.
Give only your policy bundle allpermission, then deny the filepermission to
your plugin, and finally give all permission to all bundles. That should make
it work.
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.gogo.command [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wir
> ing.package;
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=pro
> visional)(version>=0.10.0)(!(version>=1.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(Fra
[jira] [Resolved] (FELIX-2872) Provide a way to have an easier to read manifest
[
https://issues.apache.org/jira/browse/FELIX-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch resolved FELIX-2872.
-
Resolution: Fixed
Fix Version/s: maven-bundle-plugin-2.3.6
Fixed in trunk
> Provide a way to have an easier to read manifest
>
>
> Key: FELIX-2872
> URL: https://issues.apache.org/jira/browse/FELIX-2872
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Reporter: Guillaume Nodet
>Assignee: Stuart McCulloch
> Fix For: maven-bundle-plugin-2.3.6
>
>
> It should be possible to have a easier to read generated manifest, with
> newlines after commas in comma separated list.
> We'd still have to abide by the 80 charachters (or so) per line rule,
> something like:
> {code}
> Require-Bundle: org.eclipse.ui,
> org.eclipse.core.databinding,
> org.eclipse.core.databinding.beans
> {code}
> This of course could be made optional / configurable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128784#comment-13128784
]
Yanni Yan commented on FELIX-3163:
--
Thanks, I followed your suggested step, the problem has been solved.
But I found another problem.
The following is my cpa.txt
0-5574490310197831951=ALLOW {
[org.osgi.service.condpermadmin.BundleLocationCondition "file\:*"]
(java.security.AllPermission "*" "*") } "5574490310197831951"
1--215009982731039061=DENY {
[org.osgi.service.condpermadmin.BundleLocationCondition
"file\:plugins/First_1.0.0.0.jar"] (java.io.FilePermission "<>"
"write") } "-215009982731039061"
I want to prohibit my bundle to write files. But when I enable the security
setting. It's not work.
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.gogo.command [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wir
> ing.package;
> (&(osgi.wiring.package=org.apache.felix.service.command)(status=pro
> visional)(version>=0.10.0)(!(version>=1.0.0
[jira] [Created] (FELIX-3167) Add support for new PASSWORD attribute type
Add support for new PASSWORD attribute type --- Key: FELIX-3167 URL: https://issues.apache.org/jira/browse/FELIX-3167 Project: Felix Issue Type: Improvement Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Felix Meschberger OSGi Residential Specification 4.3 includes an update to the Metatype service supporting a new attribute type PASSWORD.  -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3168) Add support for new PASSWORD attribute type of Metatype service
Add support for new PASSWORD attribute type of Metatype service --- Key: FELIX-3168 URL: https://issues.apache.org/jira/browse/FELIX-3168 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Felix Meschberger OSGi Residential Specification 4.3 includes an update to the Metatype service supporting a new attribute type PASSWORD. The WebConsole configuration admin page must be extended to support this new attribute type with an appropriate input field (probably password and not maybe even not transferring the actual configuration value to the client ...) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3039) SCR cleans up delayed service components too aggressively
[ https://issues.apache.org/jira/browse/FELIX-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-3039. -- Resolution: Fixed Fix Version/s: scr-1.6.2 Assignee: Felix Meschberger In Rev. 1185082: Added new ds.delayed.keepInstances configuration property which allows to prevent delayed components from being clean up. By default this property is false (to implement the spec suggestion). The property can be set as a framework property or as part of the org.apache.felix.scr.ScrService configuration. Also updated documentation at http://felix.apache.org/site/apache-felix-service-component-runtime.html#ApacheFelixServiceComponentRuntime-Configuration > SCR cleans up delayed service components too aggressively > - > > Key: FELIX-3039 > URL: https://issues.apache.org/jira/browse/FELIX-3039 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Neil Bartlett >Assignee: Felix Meschberger >Priority: Minor > Fix For: scr-1.6.2 > > > In the case of an ordinary delayed service component, SCR immediately > deactivates and destroys the component when its service is released by the > consumer. In cases where a consumer occasionally binds and invokes the > service (e.g. EventAdmin) this can cause the component to be continuously > destroyed and recreated. > Note that Equinox's DS offers a little more control, we can choose either to > immediately clean up or never clean up (and the default is never). This is > still not very satisfactory though. > I think ideally there should be a configurable timeout, so that a component > will be cleaned up only if it is not used for some time. I also think the > default should be quite long, e.g. many minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128727#comment-13128727
]
Rob Walker edited comment on FELIX-3160 at 10/17/11 8:51 AM:
-
Now that would be quite funny ... but I have an odd sense of humour ;)
There are 2 aspects I wonder if could be different in our setup.
* Our sweeper bundle runs at a start level of 2. The bundles being uninstalled
have a start level of 1, but, they used START_TRANSIENT in the previous
framework start. On the restart, they never get beyond a start state of
INSTALLED due do the transient start option.
* The original JAR from which these bundles were started was a temporary file
and will not be accessible on restarted (it's been deleted). The cached JAR and
settings are of course still present. I don't recall any OSGi rule that says
the original location/file that a bundle was installed from has to always be
available, but maybe I forgot this?
- Rob
was (Author: walkerr):
Now that would be quite funny ... but I have an odd sense of humour ;)
There are 2 aspects I wonder if could be different in our setup.
* Our sweeper bundle runs at a start level of 2. The bundles being uninstalled
have a start level of 1, but, they used START_TRANSIENT in the previous
framework start. On the restart, they never get beyond a start level of
INSTALLED due do the transient start option.
* The original JAR from which these bundles were started was a temporary file
and will not be accessible on restarted (it's been deleted). The cached JAR and
settings are of course still present. I don't recall any OSGi rule that says
the original location/file that a bundle was installed from has to always be
available, but maybe I forgot this?
- Rob
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128727#comment-13128727
]
Rob Walker commented on FELIX-3160:
---
Now that would be quite funny ... but I have an odd sense of humour ;)
There are 2 aspects I wonder if could be different in our setup.
* Our sweeper bundle runs at a start level of 2. The bundles being uninstalled
have a start level of 1, but, they used START_TRANSIENT in the previous
framework start. On the restart, they never get beyond a start level of
INSTALLED due do the transient start option.
* The original JAR from which these bundles were started was a temporary file
and will not be accessible on restarted (it's been deleted). The cached JAR and
settings are of course still present. I don't recall any OSGi rule that says
the original location/file that a bundle was installed from has to always be
available, but maybe I forgot this?
- Rob
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3160) NPE in BundleRevisionImpl.close() when uninstalling a bundle
[
https://issues.apache.org/jira/browse/FELIX-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128720#comment-13128720
]
Karl Pauls commented on FELIX-3160:
---
Richard, did you test with the current trunk? Rob commited a quick fix to it so
if you are trying to reproduce you'd need to test against a revision before his
commit ...
> NPE in BundleRevisionImpl.close() when uninstalling a bundle
>
>
> Key: FELIX-3160
> URL: https://issues.apache.org/jira/browse/FELIX-3160
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.0.0
>Reporter: Rob Walker
>Assignee: Rob Walker
>Priority: Minor
> Fix For: framework-4.2.0
>
>
> There seems to be a case where m_content can be null when uninstalling a
> bundle, causing the following code to throw an NPE:
> synchronized void close()
> {
> try
> {
> resolve(null);
> }
> catch (Exception ex)
> {
> ((BundleImpl) m_bundle).getFramework().getLogger().log(
> Logger.LOG_ERROR, "Error releasing revision: " +
> ex.getMessage(), ex);
> }
>
>m_content.close();
> I've added a simple check for null around the close in my version to avoid
> the exception, which I'll check in.
> I'm not sure of the scenarios where this can legally be null at this point,
> and whether there's some nastier underlying circumstance that needs
> investigating. We see it under the following circumstances:
> * we register a listener that looks for framework STARTED
> * when triggered, this iterates all bundles and performs an uninstall on ones
> which we determine are zombies leftover from a previous run
> Aside from the fact we're calling uninstall from inside an event handling
> method, there doesn't anything else unusual about this code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3163) Failed in use ConditionalPermissionAdmin
[
https://issues.apache.org/jira/browse/FELIX-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128718#comment-13128718
]
Karl Pauls commented on FELIX-3163:
---
This is where you are wrong. If you assigned some permission there is no
default allpermission for the rest. They get no permission from that point on
(btw., you don't need to give the system bundle allpermission - the system
bundle has allpermission no matter what). Typically, the first thing you want
to do is to give allpermission to your policy bundle (otherwise, it can't
change the permission table anymore). Next, you want to create a rule for your
trusted bundles. What you base that on depends on your situation. A typical
example is a certain location prefix (like file:/trusted/* or
https://my.domain.com/bundles/* or something) or signing all trusted bundles
with a given certificate and use the BundleSignerCondition to give them
allpermission. After that, you can start to selectively give permissions to
3rd-party bundles...
> Failed in use ConditionalPermissionAdmin
>
>
> Key: FELIX-3163
> URL: https://issues.apache.org/jira/browse/FELIX-3163
> Project: Felix
> Issue Type: Bug
> Components: Framework Security
>Affects Versions: framework-4.0.0, framework.security-2.0.0
>Reporter: Yanni Yan
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> I test ConditionalPermissionAdmin as follow:
> private void setLocalCPA() throws Exception {
> ServiceReference srf =
> context.getServiceReference(ConditionalPermissionAdmin.class.getName());
> if (null == srf){
> throw new BundleException("Not found service: " +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionAdmin cpa =
> (ConditionalPermissionAdmin)context.getService(srf);
> if (null == cpa){
> throw new BundleException("Failed to get service :" +
> ConditionalPermissionAdmin.class.getName());
> }
>
> ConditionalPermissionUpdate cpu =
> cpa.newConditionalPermissionUpdate();
> // clear all exist permissions
> cpu.getConditionalPermissionInfos().clear();
>
> // assign all permission to all bundles
> ConditionalPermissionInfo cpi =
> cpa.newConditionalPermissionInfo(null, new ConditionInfo[]{
> new
> ConditionInfo(BundleLocationCondition.class.getName(),new String[]
> {context.getBundle(0).getLocation()})
> }, new PermissionInfo[]{
> new
> PermissionInfo(AllPermission.class.getName(), "*", "*")
> }, ConditionalPermissionInfo.ALLOW);
> cpu.getConditionalPermissionInfos().add(cpi);
> // deny FilePermission to current bundle
>
> cpu.commit();
> }
> After my bundle start, felix hunged. I restart felix, felix print as follow:
> D:\Workspace\Felix>java -Djava.security.policy=all.policy -Dorg.osgi.fr
> amework.security=osgi -jar bin/felix.jar
> ERROR: Bundle org.apache.felix.bundlerepository [1] Error starting
> file:/D:/Work
> space/UniAgent/Felix/bundle/org.apache.felix.bundlerepository-1.6.6.jar
> (org.osg
> i.framework.BundleException: Unresolved constraint in bundle
> org.apache.felix.bu
> ndlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi.wiring
> .package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(version>=
> 2.0.0
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.apache.f
> elix.bundlerepository [1]: Unable to resolve 1.0: missing requirement [1.0]
> osgi
> .wiring.package;
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.4.0)(!(ve
> rsion>=2.0.0)))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:381
> 8)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStart
> LevelImpl.java:295)
> at java.lang.Thread.run(Unknown Source)
> ERROR: Bundle org.apache.felix.gogo.command [3] Error starting
> file:/D:/Workspac
> e/UniAgent/Felix/bundle/org.apache.felix.gogo.command-0.12.0.jar
> (org.osgi.frame
> work.BundleException: Unresolved constraint in bundle
> org.apache.felix.gogo.comm
> and [3]: Unable to resolve 3.0: missing requirement [3.0]
> osgi.wiring.package; (
> &(osgi.wiring.package=org.apache.felix.service.command)(status=provisional)(vers
> ion>=0.10.0)(!(version>=1.0.0
> org.osgi.framework.Bund
