[jira] [Commented] (FELIX-3469) Type mismatch JS error using the memoryusage plugin
[
https://issues.apache.org/jira/browse/FELIX-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257381#comment-13257381
]
Felix Meschberger commented on FELIX-3469:
--
Apparently the problem occurs in this code at the end of the createElement
function:
for (var i=0; i children.length; i++) {
element.appendChild( children[i] );
}
Looks like the children.length method reports a wrong size and thus at the end
an non-existing child should be added. The fix is to simply guard against
non-existing array entry.
Type mismatch JS error using the memoryusage plugin
---
Key: FELIX-3469
URL: https://issues.apache.org/jira/browse/FELIX-3469
Project: Felix
Issue Type: Bug
Components: Web Console
Affects Versions: webconsole-3.1.2
Environment: Microsoft IE 8
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: webconsole-3.4.0
When showing the Memory Usage page, IE8 reports a type mismatch error in the
support.js script.
For example when clicking the Heap Dump button:
Result: Type mismatch error in
http://localhost:4502/system/console/res/lib/support.js (line: 257, char: 4)
Expected: no error, GC and heap dump to execute
Also the detail information is not properly listed.
--
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-3471) Support Schema validation for MetaData XML documents
[ https://issues.apache.org/jira/browse/FELIX-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257475#comment-13257475 ] Felix Meschberger commented on FELIX-3471: -- That would be quite heavy to do relying on at least one 3rd party library. What would be the benefit ? Support Schema validation for MetaData XML documents Key: FELIX-3471 URL: https://issues.apache.org/jira/browse/FELIX-3471 Project: Felix Issue Type: Bug Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Alexandre Castro Alves MetaData XML documents are not being W3C Schema-validated. Provide option for doing so. Thanks Alex -- 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-3468) Restarting the framework from the web console does not work
[
https://issues.apache.org/jira/browse/FELIX-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256280#comment-13256280
]
Felix Meschberger commented on FELIX-3468:
--
Yes, the only issue with the Web Console is, that it may not be appropriate to
have such functionality. Other than that, this is what's being done:
Restart: BundleContext.getBundle(0).update();
Shutdown: BundleContext.getBundle(0).stop();
In the Sling Launcher we overwrite the Felix class to implement our own update
method and to restart the framework in a fresh class loader. This works
perfectly but has the drawback of not being portable
Restarting the framework from the web console does not work
---
Key: FELIX-3468
URL: https://issues.apache.org/jira/browse/FELIX-3468
Project: Felix
Issue Type: Bug
Components: Karaf
Affects Versions: webconsole-3.1.8
Reporter: Hugh Rodgers
I am running Karaf v2.2.5 (which uses felix web console v3.1.8) on Windows 7.
Once I start karaf (using the karaf.bat script), I go to the web console and
click on the System Information tab. I then click the Restart button and Ok
in its popup. I see in the Karaf command line console that Karaf shuts down
and restarts. When I click in the command line console and press return (to
get a prompt), the command line console window disappears and Karaf shuts
down.
When I try this with Karaf v2.2.5 and only install the webconsole feature,
when I click Restart, the Karaf command line console disappears and Karaf
shuts down (never comes back up).
I have reproduced this issue with Karaf v2.2.5 and only loading the following
bundles:
feature name=saxon version=${saxon.bundle.plugin}
bundlemvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saxon/${saxon.bundle.plugin}/bundle
/feature
feature name=commons-io version=${commons-io.version}
bundlemvn:commons-io/commons-io/${commons-io.version}/bundle
/feature
feature name=slf4j-ext version=${org.slf4j-ext.version}
bundlemvn:org.slf4j/slf4j-ext/${org.slf4j-ext.version}/bundle
/feature
feature name=ops4j-base-lang version=${org.ops4j-base-lang}
bundle
start-level='70'mvn:org.ops4j.base/ops4j-base-lang/${org.ops4j-base-lang}/bundle
/feature
feature name=ops4j-swissbox version=${org.ops4j.pax.swissbox.version}
feature version=${org.ops4j-base-lang}ops4j-base-lang/feature
bundle
start-level='70'mvn:org.ops4j.pax.swissbox/pax-swissbox-lifecycle/${org.ops4j.pax.swissbox.version}/bundle
bundle
start-level='70'mvn:org.ops4j.pax.swissbox/pax-swissbox-optional-jcl/${org.ops4j.pax.swissbox.version}/bundle
bundle
start-level='70'mvn:org.ops4j.pax.swissbox/pax-swissbox-extender/${org.ops4j.pax.swissbox.version}/bundle
/feature
The dev:restart command works from the Karaf command line console, and it
works if I issue it from a second terminal window using the Karaf client.bat
script.
At this point, I have yet to see the Restart button in the web console work
properly.
Thanks.
--
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-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254080#comment-13254080 ] Felix Meschberger commented on FELIX-3456: -- A colleague tried a completely asynchronous model for service events in scr and although start seemed to work, stopping resulted in a lot of work on stopped bundles and component objects Been there done that ... SCR was fully asynchronous at one point in time. Stopping failed miserably because services have been gone when the component was about to be stopped and expected statically bound services to still be available. Startup worked correctly and the spec does not favor one or the other (I think there is nothing about synchronicity in the spec). I converted to synchronous startup to have better control during system startup (namely to have all components activated when the FRAMEWORK_STARTED event is fired by the framework). In fact, it is quite nice to have all components fuly handled once the bundle's STARTED or STOPPED event is fired. (This is one of my concerns with blueprint which is asynchronous and makes it hard to reason about system state). Overall and in hindsight it looks like synchronous startup is preferable to asynchronous startup. BTW: The last time I checked, Equinox DS was also fully synchronous. We might have an internal and external state. In your proposal thread 2 waits for the lock and thus thread 1 and thread 2 are susceptive to deadlocks. Particularly if you take another service into account The reason for this is, that when a service is supplied we are called back from the framework and thus have to be extremely carefull since the framework may still hold locks (for example bundle locks during bundle start) Component ignores required static service addition when in Activating state --- Key: FELIX-3456 URL: https://issues.apache.org/jira/browse/FELIX-3456 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Environment: Using org.apache.felix.scr svn rev 1298268 on Mac Reporter: Richard Ellis Priority: Critical Attachments: FELIX-3456-1.diff I have a component with two required static service references (A and B). In my scenario A and B are registered nearly simultaneously on different threads and this causes the DependencyManager to ignore the addition of one of these two services (B). This causes the component to remain unsatisfied and never activate, since the service that was ignored is not re-registered at any time and nothing subsequently causes the component to re-activate. This happens as follows: 12:30:59:317 Thread 1 - Registers Service B/257 12:30:59:320 Thread 2 - Registers Service A/258 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, activate component 12:30:59:321 Thread 2 - State transition : Unsatisfied - Activating 12:30:59:321 Thread 2 - Activating component 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored for static reference --- I believe we end up here because Thread 2 has moved the component from Unsatisfied to Activating and the reference is a static reference 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate 12:30:59:321 Thread 2 - State transition : Activating - Unsatisfied Because the addition of Service B has been ignored and serviceB is a required dependency my component then never activates even though my reqiured service is present. There is a comment in DependencyManager#serviceAdded method: // FELIX-1413: if the dependency is static and the component is // satisfied (active) added services are not considered until // the component is reactivated for other reasons. This suggests that the static service should only be ignored if the component is satisfied(active), which would be correct, but in this case the component is only activating (and will fail to activate because one of the two dependencies is not yet satisfied) and there is no check of state at this time. A simple fix would be to check the state of the component as well as if the service is static e.g. replace if ( m_dependencyMetadata.isStatic() ) with if ( m_dependencyMetadata.isStatic() m_componentManager.getState() == AbstractComponentManager.STATE_ACTIVE ) This is an easy fix, but I guess may leave a small window where a static reference could get replaced while a component was still activating if another instance of the same
[jira] [Commented] (FELIX-3456) Component ignores required static service addition when in Activating state
[ https://issues.apache.org/jira/browse/FELIX-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253605#comment-13253605 ] Felix Meschberger commented on FELIX-3456: -- Thanks for reporting. This is in fact an issue. I am not against replacing the size int by an AtomicInteger; in the interest of concurrency stability this might make sense. (though this might prevent SCR from being used in pre-Java 5 setups; we still consider this requirement valid for SCR) But I am not convinced with the state lock. This going to be dangerous for deadlocks because during activate and deactive services may be registered or unregistered, which may cause deadlocks: We currently have one single situation where we synchronize (creation of delayed component service instances) and we realize occasional deadlocks. Thinking the other way around: We have some transient states during which events may happen which may get lost. One such transient state is the activating state. And this is such an event which may get lost. Another event may be a configuration update. I have been contemplating some kind of event queuing and some way of processing such a queue when leaving the transient state. In the concrete example: T1 registers Service A, causes component into the ACTIVATING state T2 registers Service B, enqueues event since component is ACTIVATING T1 terminates ACTIVATING, checks queue and handles event. The queue could be as simple as a list of Runnable on each component manager. Component ignores required static service addition when in Activating state --- Key: FELIX-3456 URL: https://issues.apache.org/jira/browse/FELIX-3456 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Environment: Using org.apache.felix.scr svn rev 1298268 on Mac Reporter: Richard Ellis Priority: Critical Attachments: FELIX-3456-1.diff I have a component with two required static service references (A and B). In my scenario A and B are registered nearly simultaneously on different threads and this causes the DependencyManager to ignore the addition of one of these two services (B). This causes the component to remain unsatisfied and never activate, since the service that was ignored is not re-registered at any time and nothing subsequently causes the component to re-activate. This happens as follows: 12:30:59:317 Thread 1 - Registers Service B/257 12:30:59:320 Thread 2 - Registers Service A/258 12:30:59:320 Thread 2 - Dependency Manager: Adding Service A/258 12:30:59:321 Thread 2 - Dependency Manager: Service serviceA registered, activate component 12:30:59:321 Thread 2 - State transition : Unsatisfied - Activating 12:30:59:321 Thread 2 - Activating component 12:30:59:321 Thread 1 - Dependency Manager: Adding Service B/257 12:30:59:321 Thread 2 - Dependency not satisfied: serviceB 12:30:59:321 Thread 1 - Dependency Manager: Added service serviceB is ignored for static reference --- I believe we end up here because Thread 2 has moved the component from Unsatisfied to Activating and the reference is a static reference 12:30:59:321 Thread 2 - Not all dependencies satisified, cannot activate 12:30:59:321 Thread 2 - State transition : Activating - Unsatisfied Because the addition of Service B has been ignored and serviceB is a required dependency my component then never activates even though my reqiured service is present. There is a comment in DependencyManager#serviceAdded method: // FELIX-1413: if the dependency is static and the component is // satisfied (active) added services are not considered until // the component is reactivated for other reasons. This suggests that the static service should only be ignored if the component is satisfied(active), which would be correct, but in this case the component is only activating (and will fail to activate because one of the two dependencies is not yet satisfied) and there is no check of state at this time. A simple fix would be to check the state of the component as well as if the service is static e.g. replace if ( m_dependencyMetadata.isStatic() ) with if ( m_dependencyMetadata.isStatic() m_componentManager.getState() == AbstractComponentManager.STATE_ACTIVE ) This is an easy fix, but I guess may leave a small window where a static reference could get replaced while a component was still activating if another instance of the same service was registered on a different thread. There are other fixes that could be done by synchronizing more around service additions. Is anyone willing to make this fix or does anyone have any thoughts about this issue? Thanks -- This message is automatically
[jira] [Commented] (FELIX-3406) Localization in Web Console doesn't work anymore
[ https://issues.apache.org/jira/browse/FELIX-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247203#comment-13247203 ] Felix Meschberger commented on FELIX-3406: -- Looks like the files are translated (in target/classes/...) but are packed in the final JAR file untranslated ... So the webconsole reads the original UTF-8 encoded files as if it would be ISO-8859-1 and thus, of course, cannot render properly. Localization in Web Console doesn't work anymore Key: FELIX-3406 URL: https://issues.apache.org/jira/browse/FELIX-3406 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.4.0 Reporter: Valentin Valchev Assignee: Felix Meschberger Priority: Critical Fix For: webconsole-3.4.0 Seems that native2ascii task doesn't work anymore and this is with the latest SVN snapshot. (I'm using Apache Maven 3.0.3 to build) So, when UTF-8 characters are rendered on screen they appear like random characters. This makes the web console totally unusable in Bulgarian and Russian languages. -- 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-2163) The view for a single bundle uses the same multi-column view than for the bundles list, which is inapropriate
[ https://issues.apache.org/jira/browse/FELIX-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247231#comment-13247231 ] Felix Meschberger commented on FELIX-2163: -- Popup would definitely be an option. Nevertheless we still would want to support something like http://localhost/system/console/bundles/10.json to just return the JSON formatted info for Bundle 10. The view for a single bundle uses the same multi-column view than for the bundles list, which is inapropriate - Key: FELIX-2163 URL: https://issues.apache.org/jira/browse/FELIX-2163 Project: Felix Issue Type: Improvement Components: Web Console Reporter: Guillaume Nodet There's no real point in presenting the data in a multicolumn view, where you have only one line with one huge cell and several cells which are mostly redundant. I think we should have a slightly different view for viewing a single bundle. -- 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-3442) native2ascii doesn't work for DS plugin
[ https://issues.apache.org/jira/browse/FELIX-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247240#comment-13247240 ] Felix Meschberger commented on FELIX-3442: -- Same problem as with FELIX-3406: The bundle plugin includes the unprocessed resources. To have the processed resources, they must be explicitly included. native2ascii doesn't work for DS plugin --- Key: FELIX-3442 URL: https://issues.apache.org/jira/browse/FELIX-3442 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-ds-plugin-1.0.0 Reporter: Valentin Valchev Assignee: Felix Meschberger Fix For: webconsole-ds-plugin-1.0.0 -- 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-3442) native2ascii doesn't work for DS plugin
[ https://issues.apache.org/jira/browse/FELIX-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13247243#comment-13247243 ] Felix Meschberger commented on FELIX-3442: -- Explicit inclusion of the processed language files with the Include-Resources directive in Rev. 1309872 (and tested). Sorry Valentin, did realize only after the fact, that you already fixed this by adding another maven resource element. IMHO this is a problem of the bundle plugin which should be solved by configuration of the bundle plugin. native2ascii doesn't work for DS plugin --- Key: FELIX-3442 URL: https://issues.apache.org/jira/browse/FELIX-3442 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-ds-plugin-1.0.0 Reporter: Valentin Valchev Assignee: Felix Meschberger Fix For: webconsole-ds-plugin-1.0.0 -- 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-3410) ImmediateComponentManager should use any non-ignored configuration to try to activate a component.
[ https://issues.apache.org/jira/browse/FELIX-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13242215#comment-13242215 ] Felix Meschberger commented on FELIX-3410: -- Oh, quite right. I missed that detail. Thanks for providing the patch. ImmediateComponentManager should use any non-ignored configuration to try to activate a component. -- Key: FELIX-3410 URL: https://issues.apache.org/jira/browse/FELIX-3410 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.2 Reporter: David Jencks Attachments: FELIX-3410.diff ImmediateComponentManager.reconfigure only tries to activate an unsatisfied component if the configuration is require. However, if configuration is optional (i.e. not ignored) it could still change target properties and make the component satisfied so it can be activated. -- 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-3406) Localization in Web Console doesn't work anymore
[ https://issues.apache.org/jira/browse/FELIX-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240440#comment-13240440 ] Felix Meschberger commented on FELIX-3406: -- This could be related to my movement of the files. Has there been something failing due to that ? Or is there some UTF-8 setting missing ? Localization in Web Console doesn't work anymore Key: FELIX-3406 URL: https://issues.apache.org/jira/browse/FELIX-3406 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.2.0 Reporter: Valentin Valchev Assignee: Felix Meschberger Priority: Critical Fix For: webconsole-3.2.2 Seems that native2ascii task doesn't work anymore and this is with the latest SVN snapshot. (I'm using Apache Maven 3.0.3 to build) So, when UTF-8 characters are rendered on screen they appear like random characters. This makes the web console totally unusable in Bulgarian and Russian languages. -- 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-3268) Cannot build webconsole and webconsole-plugins with JDK 7
[ https://issues.apache.org/jira/browse/FELIX-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238511#comment-13238511 ] Felix Meschberger commented on FELIX-3268: -- Moved the resources to src/main/resources in Rev. 1305413 and updated the event plugin to use 1.0-beta-1 of the native2ascii plugin in Rev. 1305415 Cannot build webconsole and webconsole-plugins with JDK 7 - Key: FELIX-3268 URL: https://issues.apache.org/jira/browse/FELIX-3268 Project: Felix Issue Type: Bug Components: Web Console Environment: Debian unstable x86_64, JDK 7 from http://jdk7.java.net/download.html, Maven 3.0.3 Reporter: Lionel Debroux Assignee: Felix Meschberger Labels: patch Fix For: webconsole-upnp-plugin-1.0.2, webconsole-shell-plugin-1.0.0, webconsole-obr-plugin-1.0.0, webconsole-ds-plugin-1.0.0, webconsole-deployment-admin-plugin-1.0.0, webconsole-3.2.0, webconsole-event-plugin-1.0.4 A search in JIRA returned no match for native2ascii and no relevant match for native, so I'm creating an issue. When trying to build Felix SVN HEAD with JDK 7, the build process stops when it fails to invoke native2ascii in webconsole. It seems that there was a change between JDK 6 and JDK 7, and the 1.0-alpha-1 version of org.codehaus.mojo:native2ascii-maven-plugin in multiple POMs cannot handle it. However, version 1.0-beta-1 (I obtained that version number by removing the version parameter entirely) can cope with JDK 7. The patch below fixes the build problem in webconsole webconsole-plugins: diff --git a/webconsole-plugins/deppack/pom.xml b/webconsole-plugins/deppack/pom.xml index 0c764e6..e576a57 100644 --- a/webconsole-plugins/deppack/pom.xml +++ b/webconsole-plugins/deppack/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/ds/pom.xml b/webconsole-plugins/ds/pom.xml index 40a3224..338f306 100644 --- a/webconsole-plugins/ds/pom.xml +++ b/webconsole-plugins/ds/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId -version1.0-alpha-1/version +version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/event/pom.xml b/webconsole-plugins/event/pom.xml index b257032..2375eab 100644 --- a/webconsole-plugins/event/pom.xml +++ b/webconsole-plugins/event/pom.xml @@ -48,7 +48,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId -version1.0-alpha-1/version +version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/obr/pom.xml b/webconsole-plugins/obr/pom.xml index c4a88f2..3854ca3 100644 --- a/webconsole-plugins/obr/pom.xml +++ b/webconsole-plugins/obr/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/shell/pom.xml b/webconsole-plugins/shell/pom.xml index 661d3cd..7f1b428 100644 --- a/webconsole-plugins/shell/pom.xml +++ b/webconsole-plugins/shell/pom.xml @@ -40,7 +40,7 @@ plugin groupIdorg.codehaus.mojo/groupId artifactIdnative2ascii-maven-plugin/artifactId - version1.0-alpha-1/version + version1.0-beta-1/version executions execution goals diff --git a/webconsole-plugins/upnp/pom.xml b/webconsole-plugins/upnp/pom.xml index 413da08..bb091a4 100644 --- a/webconsole-plugins/upnp/pom.xml +++ b/webconsole-plugins/upnp/pom.xml @@ -48,7
[jira] [Commented] (FELIX-3316) Log plugin should provide more detailed exception column
[ https://issues.apache.org/jira/browse/FELIX-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238746#comment-13238746 ] Felix Meschberger commented on FELIX-3316: -- Added german translations in Rev. 1305523 In addition I removed the bottom status line (we only have the status line at the top) and made sure the select lists are nicely styled. Log plugin should provide more detailed exception column Key: FELIX-3316 URL: https://issues.apache.org/jira/browse/FELIX-3316 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Valentin Valchev Assignee: Felix Meschberger Fix For: webconsole-3.2.0 Now in the Log plugin we have an Exception column, that shows only a brief message description. We should add an option, to enable full stack-trace display. This could be particularly useful for debugging. -- 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-3399) Configuration Printers which do not implement the ConfigurationPrinter interface cannot be defined in inner classes
[ https://issues.apache.org/jira/browse/FELIX-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238753#comment-13238753 ] Felix Meschberger commented on FELIX-3399: -- Can you provide a sample exhibiting this issue ? Thanks. Configuration Printers which do not implement the ConfigurationPrinter interface cannot be defined in inner classes --- Key: FELIX-3399 URL: https://issues.apache.org/jira/browse/FELIX-3399 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Justin Edelson FELIX-2649 added support for Configuration Printers which do not explicitly implement the ConfigurationPrinter interface. However, I've discovered that if the Configuration Printer service is defined as an inner class, this does not work. The printer is displayed in the Configuration Status plugin with the correct title, but the content is not rendered (and the printConfiguration method is never invoked). No error message is logged. -- 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-3377) Allow a component to update its own service properties
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227350#comment-13227350 ] Felix Meschberger commented on FELIX-3377: -- ExtComponentContext.setServiceProperties and the return Dictionary value from activate and update replace the service registration properties rather than update the values calculated by some other method. Yes calling ExtComponentContext.setServiceProperties from within an activate or modify method would have the same effect as returning the service properties from the method Yes. If both are done -- calling setServiceProperties and return Dictionary, the latter would overwrite/replace the former. In order to avoid arguments over whether config admin or the component sets the service properties, the update method would recalculate the service properties when config admin changes them and reset what it wants either through a return value or calling ExtComponentContext.setServiceProperties. IMHO configuration admin properties are primarily to configure the component and are also (kind of secondarily) used to set the service properties. Both make sense, of course. But if we think a component should be able to set its own service properties, it should probably be able to do so completely but without disturbing its own configuration. Thus: #1 Component propertiesa are default configuration for the component #2 Config Admin enhances, extends, overwrites default configuration for the component #3 By default this set of properties is used as service properties (except private properties starting with .) #4 The component may overwrite the properties from #3 by returning a Dictionary from activate or modified or by calling setServiceProperties In practice, I would assume a component to take the properties received from the DS runtime (either ComponentContext.getProperties or the Map passed to the activate or modified method) modify it and use the result to call setProperties or return from activate. I might be conceivable, though to be slightly strange in the API: (1) activate and modified may return MapString, Object for the service properties. This would be inline with the DS 1.1 option to get the configuration passed as a Map into the methods (2) setServiceProperties would take a DictionaryString, Object for the service properties. This would be inline with the original ComponentContext.getProperties method. WDYT ? Allow a component to update its own service properties -- Key: FELIX-3377 URL: https://issues.apache.org/jira/browse/FELIX-3377 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Attachments: FELIX-3377-2.diff, FELIX-3377.diff If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements). Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired. According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy. IIUC this idea does not make sense for component factories. This idea was originally suggested by Erin Schnabel in OSGI bug 2250. -- 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-3377) Allow a component to update its own service properties
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226146#comment-13226146 ] Felix Meschberger commented on FELIX-3377: -- Thinking about it, I would like to refine your original proposal as follows: (1) New ExtCompontentContext.setServiceProperties(Dictionary) This replaces the set of properties derived from the component properties, configuration admin properties, and from the ComponentFactory.newInstance call and is only used to set the component's service registration property (2) Allow the activate and modify methods to return Dictionary If a Dictionary is returned, the respective properties are used for subsequent service registration (Dictionary returned from activate for an immediate component) or to update the service registration (Dictionary returned from modify or from activate for a delayed or service factory component). The first method is inline with DS 1.0 tradition, where the ComponentContext provides access to framework related functionality (BundleContext etc.) The second method is inline with the DS 1.1 tradition to require as minimal OSGi API involvement as possible. Any private properties (starting with a .) are filtered out of the Dictionary in both cases before using the properties for service registration. The ExtComponent method thus only influences the service registration but not an configuration supplied to the activate or modified method. Also updated OSGi Bug 2250 with this proposal. Allow a component to update its own service properties -- Key: FELIX-3377 URL: https://issues.apache.org/jira/browse/FELIX-3377 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Attachments: FELIX-3377-2.diff, FELIX-3377.diff If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements). Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired. According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy. IIUC this idea does not make sense for component factories. This idea was originally suggested by Erin Schnabel in OSGI bug 2250. -- 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-2292) Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331)
[ https://issues.apache.org/jira/browse/FELIX-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225284#comment-13225284 ] Felix Meschberger commented on FELIX-2292: -- Yes, but lack of time, you know ;-) You might give it a try.. Uprage to jetty 7.0 (org.eclipse.jetty 7.0.2v20100331) -- Key: FELIX-2292 URL: https://issues.apache.org/jira/browse/FELIX-2292 Project: Felix Issue Type: Improvement Components: HTTP Service Reporter: Jonathan Bardin Fix For: http-2.2.2 Attachments: jetty7.patch, jetty7GoodFormat.patch Hi, This is a small improvement of the Http Service in order to use jetty 7.0.2 (org.eclipse.jetty 7.0.2v20100331). The patch is following. Regards, Jonathan -- 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-3377) Allow a component to update its own service properties
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224627#comment-13224627 ] Felix Meschberger commented on FELIX-3377: -- This makes sense to me. Some remarks: (1) I would probably name the new package o.a.f.scr.component and export it with a mandatory attribute (as we do with other provisional API we export) (2) I would rather call the MutablePropertiesComponentContext interface ExtComponentContext (3) The JavaDoc for the updateProperties method should clearly indicate (as you propose) that the properties from the component descriptor are to be amended and/or updated and that these properties are still subject to being overwritten by configuration from Configuration Admin. This would imply that existing properties from the component descriptors cannot be removed, right ? Have you already submitted an OSGi bug proposing this enhancement in a future spec ? Allow a component to update its own service properties -- Key: FELIX-3377 URL: https://issues.apache.org/jira/browse/FELIX-3377 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Attachments: FELIX-3377.diff If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements). Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired. According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy. IIUC this idea does not make sense for component factories. -- 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-3345) Concurrency problems in SCR
[ https://issues.apache.org/jira/browse/FELIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224978#comment-13224978 ] Felix Meschberger commented on FELIX-3345: -- Thanks for providing the patches. As indicated in [1] I have applied the patches as follows: FELIX-3345-2.diff in Rev. 1298266 FELIX-3345-5.diff in Rev. 1298267 Patch FELIX-3345-6.diff referred to in the message seems to be missing. Doesn't matter, I'd like to apply the comprehensive test patch as of FELIX-3371 anyway. Concurrency problems in SCR --- Key: FELIX-3345 URL: https://issues.apache.org/jira/browse/FELIX-3345 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Assignee: Felix Meschberger Attachments: FELIX-3345-2.diff, FELIX-3345-3.diff, FELIX-3345-4.diff, FELIX-3345-5.diff, FELIX-3345.diff We've been encountering several exceptions thrown intermittently from DS. They generally look like ungetting service on a disposed-of SCR BundleComponentActivator, ComponentManager, or DependencyManager. There may be two threads trying to shut down the same bundles at the same time. I'm not sure how to investigate the root cause or if this kind of behavior is expected. The SCR code generally doesn't look very thread safe. It's easy to fix the specific problems we see by adding more checks to the SCR code so the NPEs are avoided, or attempted use of closed bundle contexts are caught and ignored. I'd be happy to keep looking into this but could use some hints about what should be happening. Unless someone can come up with a better explanation and fix it would be great meanwhile to patch the code to avoid throwing the exceptions. Here are some of the typical stack traces we see: Stack Dump = org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService() at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:287) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.releaseService(ServiceRegistrationImpl.java:562) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.releaseServicesInUse(ServiceRegistry.java:665) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.close(BundleContextImpl.java:91) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:514) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:565) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1161) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:595) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:691) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:598) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle$1.run(InternalSystemBundle.java:261) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.NullPointerException at org.apache.felix.scr.impl.BundleComponentActivator.log(BundleComponentActivator.java:614) at org.apache.felix.scr.impl.BundleComponentActivator.log(BundleComponentActivator.java:589) at org.apache.felix.scr.impl.manager.AbstractComponentManager.log(AbstractComponentManager.java:633) at org.apache.felix.scr.impl.manager.AbstractComponentManager$State.log(AbstractComponentManager.java:1000) at org.apache.felix.scr.impl.manager.AbstractComponentManager$State.ungetService(AbstractComponentManager.java:964) at org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService(DelayedComponentManager.java:114) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$3.run(ServiceUse.java:277) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:275) ... 14 more Stack Dump = org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService() at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:287) at
[jira] [Commented] (FELIX-3371) update scr build to recent pax components
[ https://issues.apache.org/jira/browse/FELIX-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224985#comment-13224985 ] Felix Meschberger commented on FELIX-3371: -- Applied patch FELIX-3371-3.diff in Rev. 1298268 update scr build to recent pax components - Key: FELIX-3371 URL: https://issues.apache.org/jira/browse/FELIX-3371 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Assignee: Felix Meschberger Attachments: FELIX-3371-1.diff, FELIX-3371-2.diff, FELIX-3371-3.diff scr is using some really antique pax components. In order to help people write more integration tests it would be useful to use current versions. -- 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-3345) Concurrency problems in SCR
[ https://issues.apache.org/jira/browse/FELIX-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224986#comment-13224986 ] Felix Meschberger commented on FELIX-3345: -- What about the patches 3 and 4 ? Should these also be applied ? Are there any differences between them ? Concurrency problems in SCR --- Key: FELIX-3345 URL: https://issues.apache.org/jira/browse/FELIX-3345 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Assignee: Felix Meschberger Attachments: FELIX-3345-2.diff, FELIX-3345-3.diff, FELIX-3345-4.diff, FELIX-3345-5.diff, FELIX-3345.diff We've been encountering several exceptions thrown intermittently from DS. They generally look like ungetting service on a disposed-of SCR BundleComponentActivator, ComponentManager, or DependencyManager. There may be two threads trying to shut down the same bundles at the same time. I'm not sure how to investigate the root cause or if this kind of behavior is expected. The SCR code generally doesn't look very thread safe. It's easy to fix the specific problems we see by adding more checks to the SCR code so the NPEs are avoided, or attempted use of closed bundle contexts are caught and ignored. I'd be happy to keep looking into this but could use some hints about what should be happening. Unless someone can come up with a better explanation and fix it would be great meanwhile to patch the code to avoid throwing the exceptions. Here are some of the typical stack traces we see: Stack Dump = org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService() at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:287) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.releaseService(ServiceRegistrationImpl.java:562) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.releaseServicesInUse(ServiceRegistry.java:665) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.close(BundleContextImpl.java:91) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:514) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:565) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1161) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:595) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:257) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:215) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:284) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:691) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:598) at org.eclipse.osgi.framework.internal.core.InternalSystemBundle$1.run(InternalSystemBundle.java:261) at java.lang.Thread.run(Thread.java:680) Caused by: java.lang.NullPointerException at org.apache.felix.scr.impl.BundleComponentActivator.log(BundleComponentActivator.java:614) at org.apache.felix.scr.impl.BundleComponentActivator.log(BundleComponentActivator.java:589) at org.apache.felix.scr.impl.manager.AbstractComponentManager.log(AbstractComponentManager.java:633) at org.apache.felix.scr.impl.manager.AbstractComponentManager$State.log(AbstractComponentManager.java:1000) at org.apache.felix.scr.impl.manager.AbstractComponentManager$State.ungetService(AbstractComponentManager.java:964) at org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService(DelayedComponentManager.java:114) at org.eclipse.osgi.internal.serviceregistry.ServiceUse$3.run(ServiceUse.java:277) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:275) ... 14 more Stack Dump = org.osgi.framework.ServiceException: Exception in org.apache.felix.scr.impl.manager.DelayedComponentManager.ungetService() at org.eclipse.osgi.internal.serviceregistry.ServiceUse.releaseService(ServiceUse.java:287) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.releaseService(ServiceRegistrationImpl.java:562) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:245) at
[jira] [Commented] (FELIX-3377) Allow a component to update its own service properties
[ https://issues.apache.org/jira/browse/FELIX-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225019#comment-13225019 ] Felix Meschberger commented on FELIX-3377: -- Thanks a lot for providing the patch. I have applied it slightly modified in Rev. 1298275: - Added some more JavaDoc to ExtComponentContext - Have ExtComponentContext extend ComponentContext - Internally tread property overwrites like supplied CM configuration This allows for properly transient property modification instead of overwriting the actual descriptor properties which would cause the properties for all instances created from the same descriptor to be subsequently modified. Does this sound correct ? Allow a component to update its own service properties -- Key: FELIX-3377 URL: https://issues.apache.org/jira/browse/FELIX-3377 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Attachments: FELIX-3377-2.diff, FELIX-3377.diff If you just register a service in code, you can give the ServiceRegistration to the service and it can update its service properties to reflect what it can discover about its environment. This proposes that services registered through DS should be able to do this too, by calling an updateProperties(Dictionary) method on the ComponentContext. (Since we'd need a spec update to add the method to ComponentContext, I added a new interface that ComponentContextImpl implements). Right now a service could get Config Admin and modify the properties there, but then (a) the update method is called even though the component itself initiated the changes and (b) the new property values are persisted which is presumably not desired. According to the spec config admin properties override default property values specified in the component xml. I think that in order to reduce confusion, once a property has been set through config admin it should not be possible to update it through this update method. This also makes implementing this idea easy. IIUC this idea does not make sense for component factories. This idea was originally suggested by Erin Schnabel in OSGI bug 2250. -- 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-3368) Class loading fails on shutdown because zip is unreadable
[ https://issues.apache.org/jira/browse/FELIX-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13219895#comment-13219895 ] Felix Meschberger commented on FELIX-3368: -- Couldn't we just throw ClassNotFoundException in this case ? (or maybe I am just off by a bit ;-) ) Class loading fails on shutdown because zip is unreadable - Key: FELIX-3368 URL: https://issues.apache.org/jira/browse/FELIX-3368 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.2.2 Reporter: Dustin Schultz If a particular module executes a shutdown hook which loads a class at runtime, it will fail with NoClassDefFound errors because the classloader will be unable to load the class from the jar. ERROR: JarContent: Unable to read bytes. (java.lang.IllegalStateException: zip file closed) java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:415) at java.util.zip.ZipFile.getEntry(ZipFile.java:160) at org.apache.felix.framework.util.ZipFileX.getEntry(ZipFileX.java:52) at org.apache.felix.framework.cache.JarContent.getEntryAsBytes(JarContent.java:122) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1816) at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727) at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCache.doDispose(IndexedDiskCache.java:920) at -- 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-3361) Bundle#start does not comply with the spec
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215539#comment-13215539 ] Felix Meschberger commented on FELIX-3361: -- If start levels come into play the StartLevel service dictates the actual bundle states. * when the bundle start level is greater than the framework target start level The bundle is not expected to start until the framework start level is increased to at least the bundle's start level. Start levels are increased step-wise. So if a bundle is at 5, the current is 2 and the target is 6, the start level is increased to 3, 4, 5, and 6 and bundles assigned to the respective start levels are actually started. Thus a bundle at level x with the framework start level being y x will at most be in the RESOLVED state. * if the start level thread is already running Right, if the start level is being increased, the bundle is only actually started when passing the bundle's start level. Bundle.start in these situations will only persistently mark the bundle started (for later start level operations to actually start the bundle). Bundle#start does not comply with the spec -- Key: FELIX-3361 URL: https://issues.apache.org/jira/browse/FELIX-3361 Project: Felix Issue Type: Bug Affects Versions: framework-4.0.2 Reporter: Guillaume Nodet The spec says: When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance. However there is a case where this does not happen, which is when the start level thread is already running I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec. -- 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-3361) Bundle#start does not comply with the spec
[ https://issues.apache.org/jira/browse/FELIX-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13215569#comment-13215569 ] Felix Meschberger commented on FELIX-3361: -- See 8.3.5 Starting a Bundle: If a bundle is started by calling the Bundle.startmethod, then the OSGi Framework must mark the bundle as persistently started. The OSGi Framework must not actually start a bundle when the active start level is less than the bundle’s start level. In that case, the state must not change. Also the Bundle.start(int) JavaDoc clarifies this. Bundle#start does not comply with the spec -- Key: FELIX-3361 URL: https://issues.apache.org/jira/browse/FELIX-3361 Project: Felix Issue Type: Bug Affects Versions: framework-4.0.2 Reporter: Guillaume Nodet The spec says: When the start method returns without an exception, the state of the bundle will either be ACTIVE or STARTING, depending on the declared activation policy and whether it was used. If the start method throws an exception, then the bundle will not be in either of these states and the stop method will not be called for this Bundle Activator instance. However there is a case where this does not happen, which is when the start level thread is already running I think the Bundle#start should either activate the bundle or wait for the bundle to be activated before returning in order to comply with the spec. -- 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-3360) Bundle location is statically set for dynamically bound bundles
[ https://issues.apache.org/jira/browse/FELIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212730#comment-13212730 ] Felix Meschberger commented on FELIX-3360: -- Sorry, I have to decline this request because it would violate the spec. The spec states that a configuration retrieved with the single argument getConfiguration(String pid) method must be statically bound to the calling bundle. So everything works correctly. In fact your use case of uninstalling and re-installing a bundle to update it is not sensitive: You should really update the existing bundle. Not only will you keep the configuration properly bound but also will you not loose any potential bundle-private data (accessed through BundleContext.getDataFile(String)). With Configuration Admin spec 1.4 new definitions of the bundle location exist and the Apache Felix SCR bundle (I assume you refer to that when you talk of the getConfiguration(String pid) method) will be updated to actually use an explicit bundle location of ?* when accessing configuration to prevent this kind of binding of unbound configuration. Bundle location is statically set for dynamically bound bundles --- Key: FELIX-3360 URL: https://issues.apache.org/jira/browse/FELIX-3360 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.2.8 Reporter: Julian Sedding Attachments: FELIX-3360.patch The method ConfigurationAdminImpl#getConfiguration(pid) dynamically sets the configuration's bundle location if it is null. However, it uses ConfigurationImpl#setStaticBundleLocation(location) in order to do so. This should be changed to set the dynamic location. Attached is a proposed patch. The issue I observed, that lead me to this bug, was as follows: 1. Installed a number of factory configurations and the bundle (version 1.0.0, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.0.jar) providing the service implementation (using SCR) via Sling's OSGi Installer 2. Uninstalled the bundle. 3. Installed the bundle (version 1.0.2, bundle location: jcrinstall:/apps/sample/install/bundle-1.0.2.jar) After this, the factory configurations were not bound to the bundle any longer, because they were still bound to the no longer existing bundle location jcrinstall:/apps/sample/install/bundle-1.0.0.jar. This basically leaves stale configurations and a badly configured system. While Sling's OSGi Installer handles updates without changing the bundle location normally, the above scenario differs in that instead of an update, there is an uninstall + re-install happening. The Configuration Admin Service Specification 1.3 clearly states (in 104.4.1 Location Binding): When this dynamically bound bundle is subsequently uninstalled, the Configuration object's bundle location must be set to null again so it can be bound again later. Note: in the patch I also changed the return type of ConfigurationImpl#tryBindLocation() from boolean to void. Before, it always returned true, so the return value is meaningless. I almost ended up using it in an if statement because of the return type, which made me believe that it returns true if the bundle location is set and false otherwise. -- 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-2625) Provide a plugin for the Gogo Shell
[ https://issues.apache.org/jira/browse/FELIX-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13196873#comment-13196873 ] Felix Meschberger commented on FELIX-2625: -- Committed a first shot a Felix provided Web Console plugin in Rev. 1238456/1238457. This is basically the Karaf WebConsole plugin mentioned by Guillaume above with some dependencies from Karaf Shell inlined and stripped down. Particularly the blueprint stuff and Felix Gogo internals are removed. Provide a plugin for the Gogo Shell --- Key: FELIX-2625 URL: https://issues.apache.org/jira/browse/FELIX-2625 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Felix Meschberger Assignee: Felix Meschberger The Gogo Shell has replaced the simple Felix Shell as the command line tool for OSGi Management. We should provide support for this shell from within the Web Console, too. -- 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-3334) PreferencesManager can throw NPE after being stopped.
[ https://issues.apache.org/jira/browse/FELIX-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197641#comment-13197641 ] Felix Meschberger commented on FELIX-3334: -- A bundle being stopped is automatically unregistered as a bundle listener but only after having called the stop method of the BundleActivator. Looking at the code, chances are minimal (if there is a concurrency between event handling and handling stop), but this would not be 100% solved by the patch (because an event might still be coming in. A better fix would be to check for the null-situation in the event handler when accessing the store. Did you actually encounter an NPE ? PreferencesManager can throw NPE after being stopped. - Key: FELIX-3334 URL: https://issues.apache.org/jira/browse/FELIX-3334 Project: Felix Issue Type: Bug Components: Preferences Service Affects Versions: prefs-1.0.4 Reporter: J.W. Janssen Labels: patch Attachments: quickfix.patch PreferencesManager#bundleChanged tries to intercept bundles that are uninstalled. However, if the PreferencesManager itself is stopped, it does not unregister itself as bundle listener, causing possible NPEs when other bundles depending on the preferences service are stopped later on, for example during a shutdown. I've got a patch available, will attach it to this issue to be applied. -- 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-3325) Finding activate/deactivate/modified methods has numerous problems
[ https://issues.apache.org/jira/browse/FELIX-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195747#comment-13195747 ] Felix Meschberger commented on FELIX-3325: -- Thanks for providing the patch. ReferenceMetadata.validate right, not a big deal in reality, but good for code completeness. BaseMethod.getMethod Wow, yeah, the expected exception is eaten. ActivateMethod.doFindMethod right. going to apply this patch. Finding activate/deactivate/modified methods has numerous problems -- Key: FELIX-3325 URL: https://issues.apache.org/jira/browse/FELIX-3325 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: David Jencks Attachments: FELIX-3325.diff I've identified at least 3 problems in the code finding appropriate activate/deactivate/modified methods on DS components. 1. BaseMethod.getMethod wraps SuitableMethodNotAccessibleException exceptions in InvocationTargetExceptions, which prevents callers from detecting the SuitableMethodNotAccessibleException and responding appropriately. 2. ActivateMethod.doFindMethod: if it gets to looking for an empty method, it will return null if there isn't one, even if there was a previous SuitableMethodNotAccessible detected. It should only return a non-null method. 3. ActivateMethod.getSingleParameterMethod will throw a SuitableMethodNotAccessibleException even if it finds an accessible suitable method after the non-accessible one. In addition, ReferenceMetadata.validate does not make the object read-only by setting m_validate. -- 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-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193705#comment-13193705 ] Felix Meschberger commented on FELIX-3317: -- Committed a first fix in Rev. 1236123 This implements the second option by checking the consistency before assigning the service registration field: If the state is (still) the same after registering the service and the service registration field is still null (concurrent execution might have already set the field) the field is set. Otherwise a WARN message is logged with the log service and the service is unregistered again. Concurrency issue during Component Service registration --- Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- 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-3317) Concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193752#comment-13193752 ] Felix Meschberger commented on FELIX-3317: -- Improved state check in Rev. 1236132: a delayed or service factory component may be really activated during service registration and thus may change the state from Registered to Active. This is perfectly valid and thus must not cause the service registration to be thrown away. Also improved logging of the Service Reference to get some usefull information out of it. Concurrency issue during Component Service registration --- Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- 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-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193849#comment-13193849 ] Felix Meschberger commented on FELIX-3318: -- I think this is a bug in the PackageAdminImpl.getBundleType method: This calls adapt to get the BundleRevision of the bundle which returns null for uninstalled bundles (probably correctly). Yet this result is not checked in the getBundleType method and thus the NPE. NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Web Console Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If
[jira] [Commented] (FELIX-3318) NPE in WebConsole when trying to uninstall a bundle
[ https://issues.apache.org/jira/browse/FELIX-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193853#comment-13193853 ] Felix Meschberger commented on FELIX-3318: -- Hmm, since the PackageAdminImpl.getBundleType method actually wants to have the BundleRevisionImpl class, it should probably ask for it. This should never return null, probably. NPE in WebConsole when trying to uninstall a bundle --- Key: FELIX-3318 URL: https://issues.apache.org/jira/browse/FELIX-3318 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.0.2 Reporter: Alex Parvulescu Priority: Minor Attachments: FELIX-3318.patch Tested against 3.18 and a trunk build (3.1.9.SNAPSHOT) as well. Both fail in the same way (stacktrace comes from trunk): AJAX Error The request failed: HTTP ERROR 500 Problem accessing /system/console/bundles/20. Reason: INTERNAL_SERVER_ERROR Caused by: java.lang.NullPointerException at org.apache.felix.framework.PackageAdminImpl.getBundleType(PackageAdminImpl.java:112) at org.apache.felix.webconsole.internal.core.BundlesServlet.isFragmentBundle(BundlesServlet.java:715) at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:358) at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:473) at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:418) at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79) at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42) at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49) at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33) at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39) at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) I'm testing against a barebone felix install: g! lb START LEVEL 1 ID|State |Level|Name 0|Active |0|System Bundle (4.0.1) 1|Active |1|Apache Felix Bundle Repository (1.6.6) 2|Active |1|Apache Felix Gogo Command (0.12.0) 3|Active |1|Apache Felix Gogo Runtime (0.10.0) 4|Active |1|Apache Felix Gogo Shell (0.10.0) 5|Active |1|Apache Felix Log Service (1.0.1) 6|Active |1|Apache Felix Http Bundle (2.2.0) 7|Active |1|Apache Felix Http Jetty (2.2.0) 8|Active |1|Apache Felix Configuration Admin Service (1.2.8) 9|Active |1|Apache Felix Metatype Service (1.0.4) 15|Active |1|Apache Commons IO Bundle (1.4.0) 16|Active |1|Apache Commons FileUpload Bundle (1.2.1) 17|Active |1|Apache Geronimo Bundles: json-20090211 (20090211.0.0.1) 23|Active |1|Apache Felix Web Management Console (3.1.9.SNAPSHOT) I can install any bundle and then delete it and consistently see this error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact
[jira] [Commented] (FELIX-3311) Cookie handling seems not to work anymore
[ https://issues.apache.org/jira/browse/FELIX-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193022#comment-13193022 ] Felix Meschberger commented on FELIX-3311: -- I recently (FELIX-3290) changed the cookie handling to create consistent cookie names and also to make the cookies more long-lived. Maybe this change didn't really work properly (it seems to have worked in my setup...) Cookie handling seems not to work anymore - Key: FELIX-3311 URL: https://issues.apache.org/jira/browse/FELIX-3311 Project: Felix Issue Type: Bug Components: Web Console Reporter: Carsten Ziegeler Fix For: webconsole-3.2.0 Sorting the bundle list, switching to another tab and going back shows the bundle list in the original sort order but not in the one previously picked As this information is in a cookie I assume that cookie handling does now work differently -- 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-3317) Potential concurrency issue during Component Service registration
[ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193043#comment-13193043 ] Felix Meschberger commented on FELIX-3317: -- There are multiple approaches to this problem: (1) Try to delay the destruction of the component due to the configuration update if an incomplete satisified state is recognized (2) Check state consistency after registering the service with the framework: If the state after registration is still the same as before and the service registration field has not been set (by another thread for example), the field is set. Otherwise the field is left untouched and the service is unregistered again (the backing object is most probably destroyed anyway). The first solution must make sure to not create unsolvable deadlocks by for example employing a timout in the delay instead of just waiting. Also an indication of what incomplete means and is would be required. The second solution really is a workaround since an invalid (or partially invalid) service object is being distributed causing all sorts of log messages (and may be trouble). Potential concurrency issue during Component Service registration - Key: FELIX-3317 URL: https://issues.apache.org/jira/browse/FELIX-3317 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.6.2 In our Sling-based application we saw the following behavior: The Sling ResourceResolverFactory is a component being activated. Yet every now and then a field of that component seems to become null which is not expected for an activated ResourceResolverFactory component and thus causes a NullPointerException. Upon inspection I saw, that for the same Declarative Services component two Services have been registered where only one was actually expected. Turns out that consumers of the ResoureResovlerFactory where all bound to the same service. The component on the other hand has been cycled due to a configuration update. So one service is backed by a deactivated component (whose field has been reset to null already) and the other service is live. The problem is that the service backed by the deactivated method has not been unregistered and thus all consumers are hooked up to the deactivated instance causing all sorts of problems ... This is what most probably happens in the AbstractComponentManager: * T1 Unsatisfied.activate has set the state to Active already before calling registerService * T1 registerService is called but the service registration field field is not assigned yet during registerService ServiceListeners are called * T2 A Configuration update comes in and Satisfied(Active).deactivate is called * T2 calls unregisterComponentService; does nothing because the service registration field is not assigned * T2 destroys component * T1 assigns field from service registration As a result the deactivated object's service registration may be unregistered later when the component is cycled again and the second service registration will only be unregistered when the providing bundle is restarted. -- 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-3283) Use generics in the Web Console
[ https://issues.apache.org/jira/browse/FELIX-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181370#comment-13181370 ] Felix Meschberger commented on FELIX-3283: -- Basically reverted the commit 1215540 in Rev. 1228221. But left the animal sniffer plugin config Use generics in the Web Console --- Key: FELIX-3283 URL: https://issues.apache.org/jira/browse/FELIX-3283 Project: Felix Issue Type: Task Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.2.0 Now that the web console has source level Java 5 (but still generates Java 1.4 class files) we may make use of generics and enhanced for loops to clean up the 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-3288) NPE when component exposed as a service with servicefactory = true
[ https://issues.apache.org/jira/browse/FELIX-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173532#comment-13173532 ] Felix Meschberger commented on FELIX-3288: -- You might want to update the SCR bundle to the latest release (1.6.0 at this time). This contains lots of fixes since the virtually age-old 1.0.2 release. NPE when component exposed as a service with servicefactory = true -- Key: FELIX-3288 URL: https://issues.apache.org/jira/browse/FELIX-3288 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.0.2 Reporter: Jarek Gawor I have a component that is exposed as a service and is also configured with servicefactory = true. I see the following NPE when shutting the framework: java.lang.NullPointerException at org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:252) at org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:135) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1075) at org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:357) at org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:196) at org.apache.felix.scr.impl.config.ConfiguredComponentHolder.disposeComponents(ConfiguredComponentHolder.java:299) at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:319) at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:340) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:207) Since the component is configured with servicefactory = true, ServiceFactoryComponentManager is used to manage the object. ServiceFactoryComponentManager overrides the createComponent() method from ImmediateComponentManager. ServiceFactoryComponentManager also intended (I think) to override the corresponding deleteComponent() method from ImmediateComponentManager. However, the signature of the deleteComponent() in ImmediateComponentManager has changed a bit so the override doesn't work anymore. So that's what I think is causing the problem in this case. -- 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-2709) Allow webconsole context root be obtained from framework properties
[ https://issues.apache.org/jira/browse/FELIX-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13172117#comment-13172117 ] Felix Meschberger commented on FELIX-2709: -- Adding in Rev. 1220660: - felix.webconsole.loglevel -- AbstractWebConsolePlugin log level - felix.webconsole.locale -- default locale overwriting Accept-Language header Allow webconsole context root be obtained from framework properties --- Key: FELIX-2709 URL: https://issues.apache.org/jira/browse/FELIX-2709 Project: Felix Issue Type: New Feature Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Thomas Diesler Assignee: Felix Meschberger Fix For: webconsole-3.2.0 -- 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-2708) Webconsole causes NPE in Bundle.getResource(String)
[ https://issues.apache.org/jira/browse/FELIX-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171874#comment-13171874 ] Felix Meschberger commented on FELIX-2708: -- The URL is not valid any longer (maybe some repo restructuring). The point is a potential NPE in the LicenseServlet.sendResource method: if pathInfo.innerJar is null but there is no pathInfo.licenseFile resource in the bundle, the method still tries to get the bundle resource from pathInfo.innerJar, which is null and thus causes the NPE. Webconsole causes NPE in Bundle.getResource(String) --- Key: FELIX-2708 URL: https://issues.apache.org/jira/browse/FELIX-2708 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Thomas Diesler Assignee: Felix Meschberger Fix For: webconsole-3.2.0 -- 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-3022) Add Uptime indication to Status page
[ https://issues.apache.org/jira/browse/FELIX-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171628#comment-13171628 ] Felix Meschberger commented on FELIX-3022: -- Both, start time and up time are calculated based on the start of the web console - which might be different from the system. Right. I don't have another time source ;-) Yet, it is better than nothing Add Uptime indication to Status page Key: FELIX-3022 URL: https://issues.apache.org/jira/browse/FELIX-3022 Project: Felix Issue Type: Improvement Components: Web Console Affects Versions: webconsole-3.1.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: webconsole-3.2.0 Besides the last startup time and indication of the actual up time is easy to calculate and might be interesting to see. -- 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-3278) Empty array is not persisted correctly
[ https://issues.apache.org/jira/browse/FELIX-3278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170833#comment-13170833 ] Felix Meschberger commented on FELIX-3278: -- This looks like a duplicate to your own report FELIX-3046 which has been fixed in trunk. Empty array is not persisted correctly -- Key: FELIX-3278 URL: https://issues.apache.org/jira/browse/FELIX-3278 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.2.8 Reporter: Martin Zdila Priority: Critical Empty array is not persisted correctly. It is stored as someProperty= At runtime it is then null. If the configuration is updated to empty array again, it is OK just until the framework (or config admin) is restarted. -- 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-3269) maven SCR plugin @Property is not properly parsed.
[ https://issues.apache.org/jira/browse/FELIX-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169144#comment-13169144 ] Felix Meschberger commented on FELIX-3269: -- Thanks for your report. I would assume that this issue should be solving itself with FELIX-3247. maven SCR plugin @Property is not properly parsed. -- Key: FELIX-3269 URL: https://issues.apache.org/jira/browse/FELIX-3269 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.4 Environment: Ubuntu linux 11.10, amd64, Java 1.6 - seems to be a parser issue. Reporter: Francisco Olarte When parsing the following property annotations: - // @Property(value = 127.0.0.1 // , label = Server host // , description = IP address of host to connect to. // ) final static String HOST = host; // @Property(intValue = 5000 // , label = Yate server port // , description = Port number to connect to, =0 to disable this server. // ) final static String PORT = port; // @Property(value = // , label = Server name // , description = Name for this server. // ) final static String NAME = name; // @Property(value = ALL // , label = Server purpose // , description = What this served is going to be used for, used to filter them. // ) - The metatype.xml is incorrectly generated ( extra chars from the source picked up into attribut name of AD element for port: - OCD id=com.peoplecall.yate.server name=Configuracion de socket description=Conexiones a los servidores de yate. AD id=host type=String default=127.0.0.1 name=Server host description=IP address of host to connect to./ AD id=port type=Integer default=5000 name=/#10; quot;Yate server port description=Port number to connect to, lt;=0 to disable this server./ AD id=name type=String default= name=Server name description=Name for this server./ AD id=purpose type=String default=ALL name=Server purpose description=What this served is going to be used for, used to filter them./ /OCD Notice it only happens in the non-string property, even if I use the same comment pattern as the others. I think this is related to a previously reported ( by me ) bug: https://issues.apache.org/jira/browse/FELIX-3234 and due to the SCR plugin reparsing the source code ( I suppose there is a reason for not going to the .class file to pick up annotations ). -- 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-3258) Separate parent POM from reactor
[ https://issues.apache.org/jira/browse/FELIX-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162823#comment-13162823 ] Felix Meschberger commented on FELIX-3258: -- Created new parent POM in Rev. 1210468 Separate parent POM from reactor Key: FELIX-3258 URL: https://issues.apache.org/jira/browse/FELIX-3258 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-parent-3 The (full) HTTP Service parent POM is currently the same as the reactor pom to build all parts of the service. To support creating independent releases of the parts of the implementation, we should also separate the parent POM from the reactor. -- 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-3084) Submission of source code for review of software grant for lightweight HTTP service implementation.
[ https://issues.apache.org/jira/browse/FELIX-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162835#comment-13162835 ] Felix Meschberger commented on FELIX-3084: -- Can this be closed now that we have a first release upcoming ? Submission of source code for review of software grant for lightweight HTTP service implementation. --- Key: FELIX-3084 URL: https://issues.apache.org/jira/browse/FELIX-3084 Project: Felix Issue Type: Task Components: HTTP Service Reporter: Ken Gilmer Labels: software Attachments: GRANT.pdf, org.apache.felix.http.lightweight-src.tar.gz This issue is created as part of the process outlined in the Contributing Source Code Felix page as suggested by Richard Hall in issue FELIX-538[1]. The source code attached[6] to this issue is an implementation of the OSGi HTTP Service specification version 1.2. The code is based on Richard's original server which is also referenced in FELIX-538, and the remaining code was developed by me, with the exception of a few classes which were adapted from existing Felix sources[2]. Design constraints for this project were backwards compatibility, simplicity, and size. The code base consists of 23 Java files in 3 packages. The source is divided into osgi, server, and servlet packages according to the primary purpose of the class, and interfaces are utilized to keep the three domains fairly isolated[3]. The minimal compiled jar which does not include the servlet API or OSGi API currently is 41Kb, and the dependency-free jar with all necessary APIs is 125Kb. An Ant script is provided that will build the jars and a CI server is also available for binary builds[4] and javadocs[5]. In terms of features the server doesn't offer: -HTTPS -Authentication -Cookie support -Session support In addition several aspects of the Servlet implementation have not been tested including: -Multipart POST -DELETE -PUT -Non-default character encodings And as of the submission several Servlet API methods are unimplemented in (all unimplemented methods throw org.apache.felix.http.lightweight.servlet.UnimplementedAPIException): -HttpServletRequest(Impl) -HttpServletResponse(Impl) However the core functionality has been implemented and tested and the Felix Web Admin application can be hosted with this HTTP Service implementation. I plan in continuing to use the service in personal and professional projects and would be happy to continue to add unimplemented features and maintain the code base as a Felix committer. Thanks! Ken Gilmer 1: https://issues.apache.org/jira/browse/FELIX-538 2: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/DefaultContextImpl.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/Logger.java 3: /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationHandler.java, /plain-http-service/src/main/java/org/apache/felix/http/lightweight/osgi/ServiceRegistrationResolver.java 4: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/ 5: https://leafcutter.ci.cloudbees.com/job/lightweight%20http%20service/javadoc/ 6: MD5SUM 47580996a8c364890518222494d4d26b org.apache.felix.http.lightweight-src.tar.gz -- 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-2882) It's dangerous to use service instances as keys in a Map (in the http whiteboard bundle).
[ https://issues.apache.org/jira/browse/FELIX-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162837#comment-13162837 ] Felix Meschberger commented on FELIX-2882: -- To implement FELIX-3226 I have changed this to use the ServiceReference as the key It's dangerous to use service instances as keys in a Map (in the http whiteboard bundle). - Key: FELIX-2882 URL: https://issues.apache.org/jira/browse/FELIX-2882 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Marcel Offermans Assignee: Felix Meschberger Priority: Minor Fix For: http-whiteboard-2.3.0 In ExtenderManagerImpl.addMapping() the key that is used to store a tuple in a Map is actually the service instance that you get from the ServiceTracker. This is dangerous because you have absolutely no idea if that instance correctly implements equals() and hashCode(). It's usually better to use the ServiceReference as the key (which is guaranteed to correctly implement those methods). It's probably only a minor issue in practice, but still one you can look for a long time if it does bite you. -- 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-3226) Whiteboard servlet service registered with default HttpContext if registered before HttpContext service
[ https://issues.apache.org/jira/browse/FELIX-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163003#comment-13163003 ] Felix Meschberger commented on FELIX-3226: -- Add test dependency to commons-collections in Rev. 1210601 Whiteboard servlet service registered with default HttpContext if registered before HttpContext service --- Key: FELIX-3226 URL: https://issues.apache.org/jira/browse/FELIX-3226 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-whiteboard-2.3.0 If a Servlet service for whiteboard registration with the HttpService is registered before the HttpContext service referred to, the servlet is registered with a default context. This may cause problems in the service and prevent correct operation. Rather the servlet registration should be delayed until the HttpContext arrives. Likewise, once the HttpContext is unregistered, the servlet must be unregistered from the HttpService, too. -- 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-2871) Transistive Dependencies
[ https://issues.apache.org/jira/browse/FELIX-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163004#comment-13163004 ] Felix Meschberger commented on FELIX-2871: -- Cleanup transitive dependencies of the whiteboard module in Rev. 1210601 - Limit embeddings, import the HTTP extension API - All dependencies are provided Transistive Dependencies Key: FELIX-2871 URL: https://issues.apache.org/jira/browse/FELIX-2871 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.2.0 Environment: Win XP Reporter: Andrew Holland Priority: Minor Fix For: http-2.2.2, http-whiteboard-2.3.0 i use both felix org.apache.felix.http.jetty org.apache.felix.http.whiteboard bundles with my project, it seems that both these bundles export the same packages. is it possible that transitive dependencies could be excluded from the built bundles and Import-Package should be used to find required packages. (the base and api bundles) As it stands org.apache.felix.http.jetty includes the following embedded dependencies javax.servlet org.apache.felix.http.api org.apache.felix.http.base org.mortbay org.osgi.service.http org.apache.felix.http.whiteboard bundles includes org.apache.felix.http.api org.apache.felix.http.base is it not possible to just use Import-Package and not use the embedded dependencies -- 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-3237) Provide Web Console plugin for the Http Whiteboard support
[ https://issues.apache.org/jira/browse/FELIX-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13153239#comment-13153239 ] Felix Meschberger commented on FELIX-3237: -- Implemented a Web Console Plugin in Rev. 1203903 Provide Web Console plugin for the Http Whiteboard support -- Key: FELIX-3237 URL: https://issues.apache.org/jira/browse/FELIX-3237 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger Assignee: Felix Meschberger To check whether Whiteboard Filter, Servlet, and HttpContext service registration properly works a Web Console plugin should be added to the Http Service Whiteboard support bundle. In addition a ConfigurationPrinter is to be added to get a simple information dump. -- 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-3227) ManagedService.update must be called with null if configuration exists but is not visilbe
[ https://issues.apache.org/jira/browse/FELIX-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13151155#comment-13151155 ] Felix Meschberger commented on FELIX-3227: -- Adapted integration test case to MS.update being called with null for invisible configuration (used to not be called at all previously) ManagedService.update must be called with null if configuration exists but is not visilbe - Key: FELIX-3227 URL: https://issues.apache.org/jira/browse/FELIX-3227 Project: Felix Issue Type: Bug Components: Configuration Admin, Specification compliance Affects Versions: configadmin-1.2.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: configadmin-1.4.0 R 4.3 Configuration Admin Specification (v1.4) prescribes in Section 104.5.3, that ManagedService.update must be called with null if configuration exists but is not visible to the ManagedService. Currently this call with null is only done according to the R 4.2 (v 1.3) specification if configuration does not exist. -- 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-3230) ConfiguartionAdapter.setBundleLocation checks configuration permission incorrectly
[ https://issues.apache.org/jira/browse/FELIX-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13151156#comment-13151156 ] Felix Meschberger commented on FELIX-3230: -- Fixed the check in Rev. 1202654 ConfiguartionAdapter.setBundleLocation checks configuration permission incorrectly -- Key: FELIX-3230 URL: https://issues.apache.org/jira/browse/FELIX-3230 Project: Felix Issue Type: Bug Components: Configuration Admin, Specification compliance Affects Versions: configadmin-1.2.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: configadmin-1.4.0 The ConfigurationAdapter.setBundleLocation checks the configuration does not check for CP(*,CONFIGURE) if the configurations current location is null. This must be fixed. -- 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-1963) Add possibility to share ServletContext between bundles
[ https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13150292#comment-13150292 ] Felix Meschberger commented on FELIX-1963: -- I think for HttpContext equality the Object identity is good enough (and probably even correct). Add possibility to share ServletContext between bundles --- Key: FELIX-1963 URL: https://issues.apache.org/jira/browse/FELIX-1963 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Sten Roger Sandvik Assignee: Sten Roger Sandvik Check out the possibility to share ServletContext between bundles. If ServletContextManager is global instead of local to each bundle then it chould be done. If you want to share ServletContext each HttpContext must implement equals method that ensures equality. -- 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-3198) Support generic configuration properties
[ https://issues.apache.org/jira/browse/FELIX-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13143892#comment-13143892 ] Felix Meschberger commented on FELIX-3198: -- In what respect standard or non-standard ? The OSGi Configuration Admin just provides a Dictionary of properties and the administrator/tool preparing the configuration can put in there what they like. As such this is IMHO along the lines of spec. Now, what is special here, of course, is that not all properties actually supported by the service are declared in the metatype descriptor. This of course prevents these properties from directly and easily be edited in a metatype based configuration GUI, such as the web console. Unless the tool allows for raw configuration property editing. While this might be bending the concepts a bit, I don't think it really violates any spec. As for the servlet context path: The path configured here is the path to which the servlet cookie is bound. By default this is the servlet context path but it can be narrowed down. This, of course, is a Jetty feature which technically probably violates the Servlet API spec. Same as the cookie name and request parameter name configurations, where spec reads rather strict: The names have to be JSESSIONID for the cookie and jsessionid for the request parameter. The session does not talk about the session cookie's domain directly, though. And we had customers actually asking for the session cookie's domain to be something different than the default. As a consequence: -- I think it is ok to support configuration parameters not exposed through Metatype -- In retrospect (and there is still time to fix this), I am not sure whether it is good to expose the session cookie name, parameter name and cooke path properties -- I think having the cookie domain and lifetime configurable is ok, though. WDYT ? Support generic configuration properties Key: FELIX-3198 URL: https://issues.apache.org/jira/browse/FELIX-3198 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.2 Currently the Jetty configuration only allows for a hard-coded limited sets of properties provided in either the Configuration Admin configuration or as framework properties. Adding support for generic properties allows administrators to configure the Servlet Container more specifically. Examples of such properties would be Jetty specific session configuration. -- 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-2687) Make HTTP session timeout configurable
[ https://issues.apache.org/jira/browse/FELIX-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142954#comment-13142954 ] Felix Meschberger commented on FELIX-2687: -- We have to make sure to not mix issues here: One is the HTTP(s) connection timeout of the original request. The other is the session timeout, which is an equally important issues. This shall be handled in FELIX-3199 Make HTTP session timeout configurable -- Key: FELIX-2687 URL: https://issues.apache.org/jira/browse/FELIX-2687 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.0.4 Environment: apache-karaf-2.1.0 on openjdk-6b18/Linux Reporter: Wolfgang Glas Assignee: Felix Meschberger Attachments: configurable-http-timeout.patch Hi all, ThX very much for the really smooth http service packaging ;-) According to the docs and to my code review there is no possibility to configure the HTTP session timeout in felix' HTTP service bundle. It would be very much appreciated, if such a possiblity might be introduced in a future version of HTTP service. TIA and best regards, Wolfgang Glas -- 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-2803) Separate project versions from each other
[ https://issues.apache.org/jira/browse/FELIX-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142957#comment-13142957 ] Felix Meschberger commented on FELIX-2803: -- Detached the Jetty sub project in Rev. 1196993 to only depend on released dependencies (parent, API, and base) for now. Separate project versions from each other - Key: FELIX-2803 URL: https://issues.apache.org/jira/browse/FELIX-2803 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Felix Meschberger Fix For: http-2.2.2 Currently the versions of the Http Service bundles are linked to each other by way of inheriting the project version number from the parent project. This results in the implied requirement to always relase all bundles in one go. IMHO this is not very ideal because there are some bundles, which will have more releases (for example http.base) and some bundles which will have close to no releases (e.g. http.api). -- 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-3176) Implement Configuration Admin 1.4 changes
[ https://issues.apache.org/jira/browse/FELIX-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13136810#comment-13136810 ] Felix Meschberger commented on FELIX-3176: -- In Rev. 1189621 added some DEBUG log statements and the implicit permission for bundles to get, manage, and receive their own configuration (where config location and bundle location are the same) or un-owned configuration (where bundle location is null). Implement Configuration Admin 1.4 changes - Key: FELIX-3176 URL: https://issues.apache.org/jira/browse/FELIX-3176 Project: Felix Issue Type: Task Components: Configuration Admin Affects Versions: configadmin-1.2.8 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: configadmin-1.4.0 As part of the Residential Specification 4.3 the Configuration Admin Service will be updated to Version 1.4 with the following changes (from the spec): • Allow multiple bundles to register with the same PID to access to the same configuration, see Location Binding. • Extended Configuration Permission with a location name so that it can be used to prevent access to Configurations marked with a certain location, enabling regions, see Regions. Our implementation should be adapted to continue to serve as the RI -- 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-2096) Check MetaTypeProvider.getObjectClassDefinition(String, String) specification compliance
[ https://issues.apache.org/jira/browse/FELIX-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133399#comment-13133399 ] Felix Meschberger commented on FELIX-2096: -- As of Rev. 1187706 the getObjectClassDefinition throws an IllegalArgumentException if either id is empty or null or no localized ObjectClassDefinition for the ID can be found. Null is never returned. Check MetaTypeProvider.getObjectClassDefinition(String, String) specification compliance Key: FELIX-2096 URL: https://issues.apache.org/jira/browse/FELIX-2096 Project: Felix Issue Type: Task Components: Metatype Service, Specification compliance Affects Versions: metatype-1.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger I have been running the Apache Felix Metatype Service implementation through the OSGi CT and found an issue with the MetaTypeProvider.getObjectClassDefinition(String id, String locale) method as used in the testMetaTypeProvider test. The method is defined in Section 105.13.4.2 in the R4.2 Compendium specification to: * either return an ObjectClassDefinition for the requested id and locale * or throw an IllegalArgumentException if either id or the locale is invalid THe CT test calls the getObjectClassDefinition three times: (1) getObjectClassDefinition(, du); Expects null, but the id here is definitely invalid (empty string) and not defined, thus an exception might be more appropriate Our implementation returns null (which is presumably wrong) but passes the test (2) getObjectClassDefinition(com.acme.23456789, abc); Expects an exception due to the locale abc not provided as a file Our implementation returns null because the id com.acme.23456789 is not declared Here an exception is probably really expected because the id is not declared. It may be expected due to the missing locale. (3) getObjectClassDefinition(com.acme.foo, du) This test should pass as expected A question regarding invalidity is in place: * What does invalid mean for the id ? Empty string ? Undefined/Undeclared ObjectClassDefinition ? * What does invalid mean for the locale ? This is tricky, since locales form an implicit inheritance hierarchy and even though translations for an exact locale may not be provided, such translations may be provided by the parent. And the default definitions should probably be the root of this tree. E.g. given the locale is de_CH and translations exist for de, it is IMHO expected to get a translation for de instead of de_CH. NB: Returning null as our implementation does is probably definitely wrong according to the spec, since null is not defined to be a valid result. -- 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-2880) The Webconsole does not handle VectorPrimitiveWrapper
[ https://issues.apache.org/jira/browse/FELIX-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133403#comment-13133403 ] Felix Meschberger commented on FELIX-2880: -- Still strange, I cannot reproduce this issue. I have added your sample AD to an existing metatype.xml and get the editor incl. the +/- as expected. I am using Web Console 3.1.6. The Webconsole does not handle VectorPrimitiveWrapper --- Key: FELIX-2880 URL: https://issues.apache.org/jira/browse/FELIX-2880 Project: Felix Issue Type: Bug Components: Web Console Reporter: Peter Kriens An AD like: AD name='Ints' id='ints' cardinality='-2147483648' required='true' type='Integer'/ Should be edited as a list and returned as a VectorInteger. However, this shows as a single integer in the webconsole, not a list editor. I guess it gets confused with primiitves? -- 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-3182) Update to use parent POM 2.1
[ https://issues.apache.org/jira/browse/FELIX-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13133441#comment-13133441 ] Felix Meschberger commented on FELIX-3182: -- Nothing to worry about. This setup is quite custom in Java-based project. As long as the required files exist in the final build - source and binary. If you build with the apache-release profile,which is the case for a release build, the source distro is created with the correct files. Update to use parent POM 2.1 Key: FELIX-3182 URL: https://issues.apache.org/jira/browse/FELIX-3182 Project: Felix Issue Type: Task Components: Metatype Service Affects Versions: metatype-1.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: metatype-1.0.6 Make use of the 2.1 parent POM to leverage new plugins and remote resources for the legal files -- 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-3045) new webconsole plugin - dependency finder
[ https://issues.apache.org/jira/browse/FELIX-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13132940#comment-13132940 ] Felix Meschberger commented on FELIX-3045: -- Sorry for the delay ... lost track of it. new webconsole plugin - dependency finder - Key: FELIX-3045 URL: https://issues.apache.org/jira/browse/FELIX-3045 Project: Felix Issue Type: New Feature Components: Web Console Reporter: Justin Edelson Assignee: Felix Meschberger Attachments: FELIX-3045-real.patch I recently put together a small web console plugin which allows a user to enter a list of package or class names and get back the list of bundles which export those packages (deduping the list first) as well as a dependency block to insert into a Maven pom. -- 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-3177) Remove temporary inclusion of OSGi classes
[ https://issues.apache.org/jira/browse/FELIX-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131563#comment-13131563 ] Felix Meschberger commented on FELIX-3177: -- Added first shot of the implementation in Rev. 1186765: - CM_LOCATION_CHANGED event - reassign config on location changes - support for new configuration Regions - Factory (internal mechanism) are not location bound any more - Each factory configuration instance is individually bound - adapt integration tests - temporarily include ConfigurationEvent and ConfigurationPermission classes from the OSGi repo for two new constants - export cm package at version 1.4 (and reimport [1.4,1.5)) The inclusion of two OSGi Alliance classes will be reverted by FELIX-3177. Remove temporary inclusion of OSGi classes -- Key: FELIX-3177 URL: https://issues.apache.org/jira/browse/FELIX-3177 Project: Felix Issue Type: Task Components: Configuration Admin Affects Versions: configadmin-1.4.0 Reporter: Felix Meschberger Once the OSGi Alliance releases an official build of the Configuration Admin 1.4 API classes to the central maven repository, the temporary inclusion of the ConfigurationEvent and ConfigurationPermission classes should be reverted. Also the export and import versions of the Configuration Admin package should be deduced from the official library (again). -- 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-3176) Implement Configuration Admin 1.4 changes
[ https://issues.apache.org/jira/browse/FELIX-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131618#comment-13131618 ] Felix Meschberger commented on FELIX-3176: -- Added first shot of the implementation in Rev. 1186765: - CM_LOCATION_CHANGED event - reassign config on location changes - support for new configuration Regions - Factory (internal mechanism) are not location bound any more - Each factory configuration instance is individually bound - adapt integration tests - temporarily include ConfigurationEvent and ConfigurationPermission classes from the OSGi repo for two new constants - export cm package at version 1.4 (and reimport [1.4,1.5)) The inclusion of two OSGi Alliance classes will be reverted by FELIX-3177. Implement Configuration Admin 1.4 changes - Key: FELIX-3176 URL: https://issues.apache.org/jira/browse/FELIX-3176 Project: Felix Issue Type: New Feature Components: Configuration Admin Affects Versions: configadmin-1.2.10 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: configadmin-1.4.0 As part of the Residential Specification 4.3 the Configuration Admin Service will be updated to Version 1.4 with the following changes (from the spec): • Allow multiple bundles to register with the same PID to access to the same configuration, see Location Binding. • Extended Configuration Permission with a location name so that it can be used to prevent access to Configurations marked with a certain location, enabling regions, see Regions. Our implementation should be adapted to continue to serve as the RI -- 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-3176) Implement Configuration Admin 1.4 changes
[ https://issues.apache.org/jira/browse/FELIX-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13131634#comment-13131634 ] Felix Meschberger commented on FELIX-3176: -- Added a few tests for expected ConfigurationEvents in Rev. 1186810 Implement Configuration Admin 1.4 changes - Key: FELIX-3176 URL: https://issues.apache.org/jira/browse/FELIX-3176 Project: Felix Issue Type: New Feature Components: Configuration Admin Affects Versions: configadmin-1.2.10 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: configadmin-1.4.0 As part of the Residential Specification 4.3 the Configuration Admin Service will be updated to Version 1.4 with the following changes (from the spec): • Allow multiple bundles to register with the same PID to access to the same configuration, see Location Binding. • Extended Configuration Permission with a location name so that it can be used to prevent access to Configurations marked with a certain location, enabling regions, see Regions. Our implementation should be adapted to continue to serve as the RI -- 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-3126) SCR activates a service component while the containing bundle is stopping.
[ https://issues.apache.org/jira/browse/FELIX-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125247#comment-13125247 ] Felix Meschberger commented on FELIX-3126: -- Committed a fix in Rev. 1181999 which prevents the component from being enabled or activated while the bundle is being stopped. Can you please check, whether this helps you use case ? Thanks. SCR activates a service component while the containing bundle is stopping. -- Key: FELIX-3126 URL: https://issues.apache.org/jira/browse/FELIX-3126 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Environment: FELIX-3.2.2, SCR-1.6.0 Reporter: Soren Petersen Assignee: Felix Meschberger Fix For: scr-1.6.2 I've got the following setup: Bundle 1: Implements a pattern similar to the extender pattern. A bundle tracker monitors bundles containing a certain configuration entry. Each time a bundle with the coniguration entry enters or leaves the ACTIVE state, a service of the interface com.example.bundle1.Bundle1Service is unregistered and a new service with the same interface is re-registered. Bundle 2: Has an immediate service component with the following configuration: component name=Bundle2Component immediate=true xmlns=http://www.osgi.org/xmlns/scr/v1.1.0; implementation class=com.example.bundle2.TestComponent / service provide interface=java.lang.Object / /service reference name=bundle1service interface=com.example.bundle1.Bundle1Service cardinality=1..1 policy=static bind=setBundle1Service / /component Situation: Both bundles have been started. The service component from bundle 2 is active and the reference is bound to the current Bundle1Service exported from bundle 1. Now, when i stop bundle 2 the following occur: 1. The state of bundle 2 is changed to STOPPING 2. The state change is discovered by the service tracker in bundle 1 which causes it to unregister the Bundle1Service and then register a a new Bundle1Service. 3. The SCR discovers that the bundle1service reference of the component has become unsatisfied and deactivates the component. 4. The SCR discovers that the bundle1service reference of the component has become satisfied (with a new service) and activates the component. 5. The SCR tries to export the newly activated component as a service, but fails since the bundle is stopping. The problem seems to be that SCR has not discovered that the bundle is STOPPING and disabled the component. A simple fix might be to check whether to disable the component based on bundle status before activating a new instance of the component. -- 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-2992) scr 1.6.1-SNAPSHOT: impossible to build due to obsolete dependencies
[ https://issues.apache.org/jira/browse/FELIX-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13125273#comment-13125273 ] Felix Meschberger commented on FELIX-2992: -- The project is setup to get the 0.6.0 versions from the OPS4J repository and thus may build. I tried to upgrade to the latest 2.2.0 release but I was not satisfied with the result: * Some functionality is destructively changed like missing support for in-container @Before and @After as well as no support for providing the BundleContext to the @Before method any more * In 0.6.0 the test code bundle exports its classes such that I could set up TinyBundles making use of those classes; this is not the case any longer requiring more complex setup for this sharing (I need TinyBundles to be able to properly test the processing of the descriptors in various custom built bundles) All in all, I aborted trying to migrate for now. If someone comes up with a patch for this migration, I would be happy to apply it, though. scr 1.6.1-SNAPSHOT: impossible to build due to obsolete dependencies Key: FELIX-2992 URL: https://issues.apache.org/jira/browse/FELIX-2992 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Andrei Pozolotin scr: impossible to build due to obsolete dependencies errors: [INFO] [INFO] Building Apache Felix Declarative Services 1.6.1-SNAPSHOT [INFO] [WARNING] The POM for org.ops4j.pax.exam:pax-exam:jar:0.6.0 is missing, no dependency information available [WARNING] The POM for org.ops4j.pax.exam:pax-exam-junit:jar:0.6.0 is missing, no dependency information available [WARNING] The POM for org.ops4j.pax.exam:pax-exam-container-default:jar:0.6.0 is missing, no dependency information available [WARNING] The POM for biz.aQute:bndlib:jar:0.0.313 is missing, no dependency information available [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.875s [INFO] Finished at: Fri Jun 10 13:04:54 CDT 2011 [INFO] Final Memory: 3M/61M indeed: current maven central does not contain these artifacts: http://search.maven.org/#search|ga|1|bndlib http://search.maven.org/#search|ga|1|pax%20exam -- 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-3087) Given invalid value, but the property isn't invalid.
[ https://issues.apache.org/jira/browse/FELIX-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123689#comment-13123689 ] Felix Meschberger commented on FELIX-3087: -- In Rev. 1180605: * Fix wrong Character/Char type conversion * add unit tests * refactor value conversion to do it during validation, which allows to fail value conversion on a component-level instead of a descriptor file level Given invalid value, but the property isn't invalid. Key: FELIX-3087 URL: https://issues.apache.org/jira/browse/FELIX-3087 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.6.0 Reporter: Yasuhiro Kawame Assignee: Felix Meschberger Given the following XML, the value of the property will be invalid. But this property is a valid property, with a value of char 'a'. ?xml version=1.0 encoding=UTF-8? scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0; implementation class=DummyClass / property name=test.property.Character type=Character value=ab / /scr:component -- 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-3039) SCR cleans up delayed service components too aggressively
[ https://issues.apache.org/jira/browse/FELIX-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123732#comment-13123732 ] Felix Meschberger commented on FELIX-3039: -- Actually the specification states that delayed components have to be deactivated and destroyed if not used any longer: If the service registered by a component configuration becomes unused because there are no more bundles using it, then SCR should deactivate that component configuration. This allows SCR implementations to eagerly reclaim activated component configurations. (112.5.4, Delayed Components) While should of course is not a requirement, I understand it as a strong recommendation. On the other hand, since this still allows the implementation to keep the components alive, it might make sense to keep them alive. Will consider an option ds.dontDisposeInstances as follows: * default: false -- to implement the spec recommendation * base (static) configuration by framework property (BundleContext.getProperty) * dynamic configuration through Configuration Admin (if available) 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 Priority: Minor 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] [Commented] (FELIX-2895) Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13123740#comment-13123740 ] Felix Meschberger commented on FELIX-2895: -- Thinking about it I come to the conclusion, that using getResource is really wrong. So I think we should go the full length and completely remove the use of getResource Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name -- Key: FELIX-2895 URL: https://issues.apache.org/jira/browse/FELIX-2895 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Reporter: Justin Edelson Attachments: FELIX-2895-fmeschbe.patch, FELIX-2895.patch, FELIX-2895_take2.patch The current version of SCR will use the API method getResource() to get the service component descriptor if the Service-Component header does not contain a wildcard. This precludes the discovery of DS components in attached fragment bundles. From the DS spec: Section 112.4: Component descriptions are defined in XML documents contained in a bundle and any attached fragments. Section 112.4.1: The last component of each path in the Service-Component header may use wildcards so that Bundle.findEntries can be used to locate the XML document within the bundle and its fragments A Service-Component manifest header specified in a fragment is ignored by SCR. However, XML documents referenced by a bundle's Service-Component Note the use of the word may in the first sentence. It does not say that findEntries() should/must *only* be used if there's a wildcard. As such, I believe this is within the spec, albeit not backwards compatible which is why I'm proposing to use a framework property. -- 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
