Re: Felix support rfp-153-resource-management

Hi, The implement of the chapter 144 does not depend on vm or classpath? Now we used jamVM and GNU classpath for VM environment. Regards, Yanfei 2015-08-03 16:21 GMT+08:00 David Bosschaert : > Hi, > > In the end the 'management' portion of RFP 153 was discontinued > because it is impossib

[jira] [Resolved] (FELIX-4990) Only first factoy configuration is used

[ https://issues.apache.org/jira/browse/FELIX-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4990. - Resolution: Fixed Fixed in rev 1693990 > Only first factoy configuration is used > --

[jira] [Created] (FELIX-4990) Only first factoy configuration is used

Carsten Ziegeler created FELIX-4990: --- Summary: Only first factoy configuration is used Key: FELIX-4990 URL: https://issues.apache.org/jira/browse/FELIX-4990 Project: Felix Issue Type: Bug

[jira] [Commented] (FELIX-4988) ResolverImpl uses an internal ExecutorService

[ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652598#comment-14652598 ] Thomas Watson commented on FELIX-4988: -- Sorry, attached the patch to the wrong issue.

[jira] [Updated] (FELIX-4989) CopyOnWriteList.removeAll(Collection) is incorrect causing failures for multiple cardinality resolution

[ https://issues.apache.org/jira/browse/FELIX-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-4989: - Attachment: CopyOnWriteList.patch Possible fix. > CopyOnWriteList.removeAll(Collection) is incorr

[jira] [Updated] (FELIX-4988) ResolverImpl uses an internal ExecutorService

[ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-4988: - Attachment: (was: CopyOnWriteList.patch) > ResolverImpl uses an internal ExecutorService > ---

[jira] [Commented] (FELIX-4976) Coordinations are always ORPHANED if they only are on the thread stack

[ https://issues.apache.org/jira/browse/FELIX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652532#comment-14652532 ] Christian Schneider commented on FELIX-4976: Ok will adapt my code for it. In

[jira] [Updated] (FELIX-4988) ResolverImpl uses an internal ExecutorService

[ https://issues.apache.org/jira/browse/FELIX-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-4988: - Attachment: CopyOnWriteList.patch Possible fix. > ResolverImpl uses an internal ExecutorService >

[jira] [Created] (FELIX-4989) CopyOnWriteList.removeAll(Collection) is incorrect causing failures for multiple cardinality resolution

Thomas Watson created FELIX-4989: Summary: CopyOnWriteList.removeAll(Collection) is incorrect causing failures for multiple cardinality resolution Key: FELIX-4989 URL: https://issues.apache.org/jira/browse/FELIX-4

[jira] [Resolved] (FELIX-4976) Coordinations are always ORPHANED if they only are on the thread stack

[ https://issues.apache.org/jira/browse/FELIX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4976. - Resolution: Won't Fix Assignee: (was: Carsten Ziegeler) After some discussion in

[jira] [Updated] (FELIX-4976) Coordinations are always ORPHANED if they only are on the thread stack

[ https://issues.apache.org/jira/browse/FELIX-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4976: Fix Version/s: (was: coordinator-1.0.2) > Coordinations are always ORPHANED if they only

[jira] [Updated] (FELIX-4987) Dynamic package resolution with unresolvable or fragment package exports can lead to invalid wirings

[ https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Watson updated FELIX-4987: - Summary: Dynamic package resolution with unresolvable or fragment package exports can lead to inva

[jira] [Commented] (FELIX-4987) Dynamic package resolution with fragment package exports can lead to invalid wirings

[ https://issues.apache.org/jira/browse/FELIX-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652341#comment-14652341 ] Thomas Watson commented on FELIX-4987: -- There is a third case that is failing that in

[jira] [Created] (FELIX-4988) ResolverImpl uses an internal ExecutorService

Thomas Watson created FELIX-4988: Summary: ResolverImpl uses an internal ExecutorService Key: FELIX-4988 URL: https://issues.apache.org/jira/browse/FELIX-4988 Project: Felix Issue Type: Bug

[jira] [Created] (FELIX-4987) Dynamic package resolution with fragment package exports can lead to invalid wirings

Thomas Watson created FELIX-4987: Summary: Dynamic package resolution with fragment package exports can lead to invalid wirings Key: FELIX-4987 URL: https://issues.apache.org/jira/browse/FELIX-4987 Pr

Re: Move org.osgi.* modules to attic?

On 8/1/15 05:47 , Carsten Ziegeler wrote: Am 29.07.15 um 14:32 schrieb Richard S. Hall: On 7/29/15 02:31 , Carsten Ziegeler wrote: Hi, we have modules for R4 of org.osgi.core, org.osgi.compendium and org.osgi.foundation. As these are officially available in the maven repo, I guess we can get r

Apache felix console unsatisfied bundle status

Hello, Request your input regarding following issue I am facing. I am deploying Jackrabbit oak core jar with felix and wildfly.But felix console shows DocumentNodestore as unsatisfied status. Reason shows reference javax.sql.Datasource not bound. Note: DocumentNodestore using default mongo uri

Re: Felix support rfp-153-resource-management

Hi, In the end the 'management' portion of RFP 153 was discontinued because it is impossible to implement this with an ordinary VM (you need a special type of VM). The monitoring part of RFP 153 is now available in the Proposed Final Draft of the OSGi Residential R6 specification (chapter 144) [1]