[jira] Updated: (FELIX-2049) extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific execution environment file for pax-runner
[
https://issues.apache.org/jira/browse/FELIX-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eoghan Glynn updated FELIX-2049:
Attachment: felix_2249.patch
Turns out the execution environment approach isn't sufficient, as pax-runner
will still override the system packages via a
-Dorg.osgi.framework.system.packages=... VM option.
So the only way round this seems to be to grab control of the VM options
directly, to ensure the correct karaf system property (esp. the
org.osgi.framework.system.packages) are actually set.
Please see attached patch.
(Note I had to exclude a bunch of javax.xml.* packages from the jre-1.6
property setting in assembly/src/main/filtered-resources/etc/config.properties
also).
extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific
execution environment file for pax-runner
---
Key: FELIX-2049
URL: https://issues.apache.org/jira/browse/FELIX-2049
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.4.0
Reporter: Eoghan Glynn
Fix For: karaf-1.4.0
Attachments: felix_2249.patch
I've been looking into rebasing an existing test on the new
org.apache.felix.karaf.testing.Helper class, but I don't think it goes quite
far enough in imposing the karaf runtime environment on pax-runner.
Specifically, just pulling in the config.properties settings related to the
system.packages doesn't stop pax-runner generating a system packages list
with its own notion of what packages are appropriate for the current JRE
version.
So for Java6 we end up with problematic entries like javax.xml.ws*,
javax.activation etc. which cause trouble for any bundles doing
version-constrained imports of these packages (because equinox assigns 0.0
as the version for system packages).
What's needed, I think, is for the Helper to generate a pax-runner execution
environment file, named say
target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile, and containing the
correct set of system packages for karaf (i.e. the
org.osgi.framework.system.packages property read from the config.properties
with the jre-1.{5|6} variable substituted in). The Helper should also set
rawPaxRunnerOption(--ee,
file://./target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile) as one of
the default options.
Feedback welcome if I'm on the wrong track with this. But if there are no
objections, I'll go ahead and code this up then submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2049) extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific execution environment file for pax-runner
[
https://issues.apache.org/jira/browse/FELIX-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eoghan Glynn updated FELIX-2049:
Attachment: felix_2249_2.patch
Just noticed a linger println() in the initial patch, please use this one
instead.
extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific
execution environment file for pax-runner
---
Key: FELIX-2049
URL: https://issues.apache.org/jira/browse/FELIX-2049
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.4.0
Reporter: Eoghan Glynn
Fix For: karaf-1.4.0
Attachments: felix_2249.patch, felix_2249_2.patch
I've been looking into rebasing an existing test on the new
org.apache.felix.karaf.testing.Helper class, but I don't think it goes quite
far enough in imposing the karaf runtime environment on pax-runner.
Specifically, just pulling in the config.properties settings related to the
system.packages doesn't stop pax-runner generating a system packages list
with its own notion of what packages are appropriate for the current JRE
version.
So for Java6 we end up with problematic entries like javax.xml.ws*,
javax.activation etc. which cause trouble for any bundles doing
version-constrained imports of these packages (because equinox assigns 0.0
as the version for system packages).
What's needed, I think, is for the Helper to generate a pax-runner execution
environment file, named say
target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile, and containing the
correct set of system packages for karaf (i.e. the
org.osgi.framework.system.packages property read from the config.properties
with the jre-1.{5|6} variable substituted in). The Helper should also set
rawPaxRunnerOption(--ee,
file://./target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile) as one of
the default options.
Feedback welcome if I'm on the wrong track with this. But if there are no
objections, I'll go ahead and code this up then submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FELIX-2049) extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific execution environment file for pax-runner
[
https://issues.apache.org/jira/browse/FELIX-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831403#action_12831403
]
Eoghan Glynn edited comment on FELIX-2049 at 2/9/10 10:42 AM:
--
Just noticed a lingering println() in the initial patch, please use
felix_2249_2.patch instead.
was (Author: eglynn):
Just noticed a linger println() in the initial patch, please use this one
instead.
extend org.apache.felix.karaf.testing.Helper to emit a karaf-specific
execution environment file for pax-runner
---
Key: FELIX-2049
URL: https://issues.apache.org/jira/browse/FELIX-2049
Project: Felix
Issue Type: Improvement
Components: Karaf
Affects Versions: karaf-1.4.0
Reporter: Eoghan Glynn
Fix For: karaf-1.4.0
Attachments: felix_2249.patch, felix_2249_2.patch
I've been looking into rebasing an existing test on the new
org.apache.felix.karaf.testing.Helper class, but I don't think it goes quite
far enough in imposing the karaf runtime environment on pax-runner.
Specifically, just pulling in the config.properties settings related to the
system.packages doesn't stop pax-runner generating a system packages list
with its own notion of what packages are appropriate for the current JRE
version.
So for Java6 we end up with problematic entries like javax.xml.ws*,
javax.activation etc. which cause trouble for any bundles doing
version-constrained imports of these packages (because equinox assigns 0.0
as the version for system packages).
What's needed, I think, is for the Helper to generate a pax-runner execution
environment file, named say
target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile, and containing the
correct set of system packages for karaf (i.e. the
org.osgi.framework.system.packages property read from the config.properties
with the jre-1.{5|6} variable substituted in). The Helper should also set
rawPaxRunnerOption(--ee,
file://./target/paxrunner/platform/ee/karaf/jre-1.{5|6}.profile) as one of
the default options.
Feedback welcome if I'm on the wrong track with this. But if there are no
objections, I'll go ahead and code this up then submit a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2061) [karaf] use waitForFrameworkStartup pax-exam option in the integration tests
[karaf] use waitForFrameworkStartup pax-exam option in the integration tests Key: FELIX-2061 URL: https://issues.apache.org/jira/browse/FELIX-2061 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Fix For: karaf-1.4.0 I've seen the odd timeout in the Karaf integration tests, and I noticed that waitForFrameworkStartup pax-exam option was not being used. Now I'm not sure whether there's even any relationship there, but it probably wouldn't do any harm to add in this option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2061) [karaf] use waitForFrameworkStartup pax-exam option in the integration tests
[ https://issues.apache.org/jira/browse/FELIX-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-2061: Attachment: felix_2061.patch Patch attached, please review and apply if considered OK. [karaf] use waitForFrameworkStartup pax-exam option in the integration tests Key: FELIX-2061 URL: https://issues.apache.org/jira/browse/FELIX-2061 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Fix For: karaf-1.4.0 Attachments: felix_2061.patch I've seen the odd timeout in the Karaf integration tests, and I noticed that waitForFrameworkStartup pax-exam option was not being used. Now I'm not sure whether there's even any relationship there, but it probably wouldn't do any harm to add in this option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2063) [karaf] hardcoding org.ops4j.pax.exam.rbc.rmi.port property in raw pax runner --vmOptions is problematic when 1099 is not the next free port
[karaf] hardcoding org.ops4j.pax.exam.rbc.rmi.port property in raw pax runner --vmOptions is problematic when 1099 is not the next free port Key: FELIX-2063 URL: https://issues.apache.org/jira/browse/FELIX-2063 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Eoghan Glynn Fix For: karaf-1.4.0 Pax-runner calculates the next free port to use on the client side of the RMI connection, whereas the server side RMI registry takes its port from the org.ops4j.pax.exam.rbc.rmi.port property regardless of whether this is free or not. Therefore the org.ops4j.pax.exam.rbc.rmi.port should not be hard-coded via the rawPaxRunnerOption(--vmOptions, ...) mechanism. Now the whole point of setting the raw --vmOptions was to avoid the karaf-specific system.packages setting being overridden by pax-runner. However a similar effect can be achieved without having to specify a org.ops4j.pax.exam.rbc.rmi.port property if the org.ops4j.pax.exam.container.def.PaxRunnerOptions.vmOption is used instead of the org.ops4j.pax.exam.container.def.PaxRunnerOptions.rawPaxRunnerOption. This approach appears to work even when another process is hogging port 1099. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2063) [karaf] hardcoding org.ops4j.pax.exam.rbc.rmi.port property in raw pax runner --vmOptions is problematic when 1099 is not the next free port
[ https://issues.apache.org/jira/browse/FELIX-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-2063: Attachment: felix_2063.patch Patch attached, please review and commit if OK. [karaf] hardcoding org.ops4j.pax.exam.rbc.rmi.port property in raw pax runner --vmOptions is problematic when 1099 is not the next free port Key: FELIX-2063 URL: https://issues.apache.org/jira/browse/FELIX-2063 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.4.0 Reporter: Eoghan Glynn Fix For: karaf-1.4.0 Attachments: felix_2063.patch Pax-runner calculates the next free port to use on the client side of the RMI connection, whereas the server side RMI registry takes its port from the org.ops4j.pax.exam.rbc.rmi.port property regardless of whether this is free or not. Therefore the org.ops4j.pax.exam.rbc.rmi.port should not be hard-coded via the rawPaxRunnerOption(--vmOptions, ...) mechanism. Now the whole point of setting the raw --vmOptions was to avoid the karaf-specific system.packages setting being overridden by pax-runner. However a similar effect can be achieved without having to specify a org.ops4j.pax.exam.rbc.rmi.port property if the org.ops4j.pax.exam.container.def.PaxRunnerOptions.vmOption is used instead of the org.ops4j.pax.exam.container.def.PaxRunnerOptions.rawPaxRunnerOption. This approach appears to work even when another process is hogging port 1099. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1915) [karaf] allow overridding of etc/system.properties via environment
[karaf] allow overridding of etc/system.properties via environment -- Key: FELIX-1915 URL: https://issues.apache.org/jira/browse/FELIX-1915 Project: Felix Issue Type: Task Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.4.0 The properties specified in etc/system.properties take precedence over those set via -Dname=value in the JAVA_OPTS. It would be more convenient for overriding if the opposite precedence ordering was used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1915) [karaf] allow overridding of etc/system.properties via environment
[ https://issues.apache.org/jira/browse/FELIX-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1915: Attachment: felix_1915.patch Can some committer please review this patch and apply if considered OK? [karaf] allow overridding of etc/system.properties via environment -- Key: FELIX-1915 URL: https://issues.apache.org/jira/browse/FELIX-1915 Project: Felix Issue Type: Task Components: Karaf Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.4.0 Attachments: felix_1915.patch The properties specified in etc/system.properties take precedence over those set via -Dname=value in the JAVA_OPTS. It would be more convenient for overriding if the opposite precedence ordering was used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1902) [karaf] sanitize web demo README of references to FUSE SNAPSHOT version
[karaf] sanitize web demo README of references to FUSE SNAPSHOT version --- Key: FELIX-1902 URL: https://issues.apache.org/jira/browse/FELIX-1902 Project: Felix Issue Type: Task Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.4.0 Just noticed in the 1.2.0 kit that the web demo README refers to the 1.1.0.0-fuse-SNAPSHOT version. This needs to be replaced with a generic version reference thats substituted for the real version during the kit build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1902) [karaf] sanitize web demo README of references to FUSE SNAPSHOT version
[ https://issues.apache.org/jira/browse/FELIX-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1902: Attachment: felix_1902.patch Can some committer please review the attached patch and apply if considered kosher. [karaf] sanitize web demo README of references to FUSE SNAPSHOT version --- Key: FELIX-1902 URL: https://issues.apache.org/jira/browse/FELIX-1902 Project: Felix Issue Type: Task Affects Versions: karaf-1.2.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.4.0 Attachments: felix_1902.patch Just noticed in the 1.2.0 kit that the web demo README refers to the 1.1.0.0-fuse-SNAPSHOT version. This needs to be replaced with a generic version reference thats substituted for the real version during the kit build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1882) [karaf] karaf-client should have the option to retry connection establishment
[ https://issues.apache.org/jira/browse/FELIX-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1882: Component/s: Karaf Fix Version/s: karaf-1.2.0 karaf-1.0.2 Affects Version/s: karaf-1.0.0 [karaf] karaf-client should have the option to retry connection establishment - Key: FELIX-1882 URL: https://issues.apache.org/jira/browse/FELIX-1882 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Fix For: karaf-1.0.2, karaf-1.2.0 When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay down the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1882) [karaf] karaf-client should have the option to retry connection establishment
[ https://issues.apache.org/jira/browse/FELIX-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1882: Attachment: felix_1882.patch Can some committer please review this patch and apply if considered kosher? [karaf] karaf-client should have the option to retry connection establishment - Key: FELIX-1882 URL: https://issues.apache.org/jira/browse/FELIX-1882 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Fix For: karaf-1.0.2, karaf-1.2.0 Attachments: felix_1882.patch When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay down the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1882) [karaf] karaf-client should have the option to retry connection establishment
[ https://issues.apache.org/jira/browse/FELIX-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1882: Description: When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) was: When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay down the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) [karaf] karaf-client should have the option to retry connection establishment - Key: FELIX-1882 URL: https://issues.apache.org/jira/browse/FELIX-1882 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Fix For: karaf-1.0.2, karaf-1.2.0 Attachments: felix_1882.patch When using the karaf-client to run some automated set-up commands on a newly started karaf instances, there's a slight race condition between the ssh server being ready to accept incoming connections and the point at which the karaf-client is run. This is especially apparent if the karaf instance has a long boot features list. To avoid having to artificially delay the client start-up, the karaf-client should accept two new command-line options to enable connection-establishment retry logic: -r [attempts] retry connection establishment (up to attempts times) -d [delay]intra-retry delay (defaults to 2 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1849) Provide Instance details for root instance via AdminServiceMBean.getInstances() attribute
[ https://issues.apache.org/jira/browse/FELIX-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1849: Attachment: felix_1849.patch Can some committer review this patch and apply if considered kosher? BTW the patch also fixes FELIX-1850. Provide Instance details for root instance via AdminServiceMBean.getInstances() attribute - Key: FELIX-1849 URL: https://issues.apache.org/jira/browse/FELIX-1849 Project: Felix Issue Type: Task Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Fix For: karaf-1.2.0 Attachments: felix_1849.patch Currently only child instances are reported via this tabular data, with the result that the ssh port for the root instance is not available via JMX. An additional Instance should be included in this list to represent root. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1850) Expose additional isRoot attribute on AdminServiceMBean
[ https://issues.apache.org/jira/browse/FELIX-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776979#action_12776979 ] Eoghan Glynn commented on FELIX-1850: - Fixed by patch for FELIX-1849 (https://issues.apache.org/jira/secure/attachment/12424718/felix_1849.patch) Expose additional isRoot attribute on AdminServiceMBean --- Key: FELIX-1850 URL: https://issues.apache.org/jira/browse/FELIX-1850 Project: Felix Issue Type: Task Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Fix For: karaf-1.2.0 Currently determining if an instance is the root instance depends on the karaf.name not having been over-ridden from root to some other value. It would be useful to provide this information explicitly via a new isRoot attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1655) Provide an additional argument to the Karaf admin:create command that specifies the featuresBoot
[ https://issues.apache.org/jira/browse/FELIX-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766014#action_12766014 ] Eoghan Glynn commented on FELIX-1655: - What would be useful also would be the ability to add a features URL via a similar argument. Something like: admin:create -furl mvn:org.apache.servicemix.features/apache-servicemix/4.1.0/xml/features -f cxf-jaxrs or some-such. Provide an additional argument to the Karaf admin:create command that specifies the featuresBoot Key: FELIX-1655 URL: https://issues.apache.org/jira/browse/FELIX-1655 Project: Felix Issue Type: Improvement Components: Karaf Reporter: David Bosschaert Fix For: karaf-1.0.2 Currently when you do admin:create from the Karaf shell, it creates a minimal Karaf runtime. This is nice, but it would be even better if you could specify some additional intial features with the create command. Something like: admin:create -f web+jbi This would add web and jbi to the minimum set of features (which is ssh and management I think). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1751) [karaf] admin:start silently fails to launch new instance
[ https://issues.apache.org/jira/browse/FELIX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1751: Description: admin:start foobar fails silently, i.e. no process is launched for foobar instance After running the equivalent command directly, I see a FileNotFound on the framework jar: java.io.FileNotFoundException: ...apache-felix-karaf-.../org/apache/felix/org.apache.felix.framework/2.0.0/org.apache.felix.framework-2.0.0.jar The path above is missing just the system component. This is due to the karaf.default.repository=system property being present in top-level etc/system.properties but missing from instances/foobar/etc/system.properties. was: admin:start foobar fail silently, i.e. no process is launched for foobar instance After running the equivalent command directly I see a FileNotFound on the framework jar: java.io.FileNotFoundException: ...apache-felix-karaf-.../org/apache/felix/org.apache.felix.framework/2.0.0/org.apache.felix.framework-2.0.0.jar The path above is missing just the system component. This is due to the karaf.default.repository=system property being present in top-level etc/system.properties but missing from instances/foobar/etc/system.properties. [karaf] admin:start silently fails to launch new instance - Key: FELIX-1751 URL: https://issues.apache.org/jira/browse/FELIX-1751 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: Eoghan Glynn Fix For: karaf-1.0.2 admin:start foobar fails silently, i.e. no process is launched for foobar instance After running the equivalent command directly, I see a FileNotFound on the framework jar: java.io.FileNotFoundException: ...apache-felix-karaf-.../org/apache/felix/org.apache.felix.framework/2.0.0/org.apache.felix.framework-2.0.0.jar The path above is missing just the system component. This is due to the karaf.default.repository=system property being present in top-level etc/system.properties but missing from instances/foobar/etc/system.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1751) [karaf] admin:start silently fails to launch new instance
[karaf] admin:start silently fails to launch new instance - Key: FELIX-1751 URL: https://issues.apache.org/jira/browse/FELIX-1751 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: Eoghan Glynn Fix For: karaf-1.0.2 admin:start foobar fail silently, i.e. no process is launched for foobar instance After running the equivalent command directly I see a FileNotFound on the framework jar: java.io.FileNotFoundException: ...apache-felix-karaf-.../org/apache/felix/org.apache.felix.framework/2.0.0/org.apache.felix.framework-2.0.0.jar The path above is missing just the system component. This is due to the karaf.default.repository=system property being present in top-level etc/system.properties but missing from instances/foobar/etc/system.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1751) [karaf] admin:start silently fails to launch new instance
[ https://issues.apache.org/jira/browse/FELIX-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1751: Attachment: felix_1751.patch Can some committer review and apply the attached patch. [karaf] admin:start silently fails to launch new instance - Key: FELIX-1751 URL: https://issues.apache.org/jira/browse/FELIX-1751 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf-1.0.2 Reporter: Eoghan Glynn Fix For: karaf-1.0.2 Attachments: felix_1751.patch admin:start foobar fails silently, i.e. no process is launched for foobar instance After running the equivalent command directly, I see a FileNotFound on the framework jar: java.io.FileNotFoundException: ...apache-felix-karaf-.../org/apache/felix/org.apache.felix.framework/2.0.0/org.apache.felix.framework-2.0.0.jar The path above is missing just the system component. This is due to the karaf.default.repository=system property being present in top-level etc/system.properties but missing from instances/foobar/etc/system.properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-1675) karaf web demo README references old servicemix-client.jar
karaf web demo README references old servicemix-client.jar -- Key: FELIX-1675 URL: https://issues.apache.org/jira/browse/FELIX-1675 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.0.2 The karaf web demo README.txt instructions need to be snaitized of ServiceMix Kernel references. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1675) karaf web demo README references old servicemix-client.jar
[ https://issues.apache.org/jira/browse/FELIX-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1675: Description: The karaf web demo README.txt instructions need to be sanitized of ServiceMix Kernel references. (was: The karaf web demo README.txt instructions need to be snaitized of ServiceMix Kernel references.) karaf web demo README references old servicemix-client.jar -- Key: FELIX-1675 URL: https://issues.apache.org/jira/browse/FELIX-1675 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.0.2 The karaf web demo README.txt instructions need to be sanitized of ServiceMix Kernel references. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-1675) karaf web demo README references old servicemix-client.jar
[ https://issues.apache.org/jira/browse/FELIX-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eoghan Glynn updated FELIX-1675: Attachment: felix_1675.patch Can some commiter apply this trivial patch? karaf web demo README references old servicemix-client.jar -- Key: FELIX-1675 URL: https://issues.apache.org/jira/browse/FELIX-1675 Project: Felix Issue Type: Improvement Components: Karaf Affects Versions: karaf-1.0.0 Reporter: Eoghan Glynn Priority: Minor Fix For: karaf-1.0.2 Attachments: felix_1675.patch The karaf web demo README.txt instructions need to be sanitized of ServiceMix Kernel references. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1642) osgi:shutdown just hang when use karaf-client.jar
[ https://issues.apache.org/jira/browse/FELIX-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12759482#action_12759482 ] Eoghan Glynn commented on FELIX-1642: - Could the client hang occur because the shutdown command is actually interpreted as shutdown the remote karaf instance as opposed to shutdown the local client? That's what I'm seeing when I use a karaf-client to interact with a remote karaf instance started standalone, or launched from MOP (though not running in a servlet container as per your use-case). osgi:shutdown just hang when use karaf-client.jar - Key: FELIX-1642 URL: https://issues.apache.org/jira/browse/FELIX-1642 Project: Felix Issue Type: Bug Components: Karaf Reporter: Freeman Fang I tried with karaf/demos/web example, all is fine, I can use java -jar lib/karaf-client.jar to connect the karaf instance deployed in servlet container, osgi:list return is ok, but when I try to use osgi:shutdown to quit the client, the console just hang -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-1642) osgi:shutdown just hang when use karaf-client.jar
[ https://issues.apache.org/jira/browse/FELIX-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12759491#action_12759491 ] Eoghan Glynn commented on FELIX-1642: - Here's a thread dump from a client after running shutdown: ka...@root shutdown ka...@root 2009-09-25 12:12:27 Full thread dump Java HotSpot(TM) Server VM (14.2-b01 mixed mode): ClientInputStreamPump daemon prio=10 tid=0x8fffa800 nid=0x84a runnable [0x8f5fe000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at org.apache.sshd.client.channel.ChannelSession.pumpInputStream(ChannelSession.java:78) at org.apache.sshd.client.channel.ChannelSession$1.run(ChannelSession.java:50) pool-1-thread-1 prio=10 tid=0x091b0800 nid=0x83f waiting on condition [0x8fcad000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0xb1084c68 (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) pool-2-thread-1 prio=10 tid=0x8ff1f400 nid=0x83d waiting on condition [0x8fcfe000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0xb10f3890 (a java.util.concurrent.SynchronousQueue$TransferStack) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424) at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323) at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Low Memory Detector daemon prio=10 tid=0x08c2d800 nid=0x834 runnable [0x] java.lang.Thread.State: RUNNABLE CompilerThread1 daemon prio=10 tid=0x08c2b800 nid=0x833 waiting on condition [0x] java.lang.Thread.State: RUNNABLE CompilerThread0 daemon prio=10 tid=0x08c28c00 nid=0x832 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Signal Dispatcher daemon prio=10 tid=0x08c27400 nid=0x831 waiting on condition [0x] java.lang.Thread.State: RUNNABLE Finalizer daemon prio=10 tid=0x08c16c00 nid=0x830 in Object.wait() [0x90332000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xb16c29c8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked 0xb16c29c8 (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) Reference Handler daemon prio=10 tid=0x08c12000 nid=0x82f in Object.wait() [0x90383000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xb16c29e8 (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked 0xb16c29e8 (a java.lang.ref.Reference$Lock) main prio=10 tid=0x08b6f000 nid=0x829 in Object.wait() [0xb739d000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xb12f34b0 (a java.lang.Object) at java.lang.Object.wait(Object.java:485) at org.apache.sshd.client.channel.AbstractClientChannel.waitFor(AbstractClientChannel.java:155) - locked 0xb12f34b0 (a java.lang.Object) at org.apache.felix.karaf.client.Main.main(Main.java:92) VM Thread prio=10 tid=0x08c0e000 nid=0x82e runnable GC task thread#0 (ParallelGC) prio=10 tid=0x08b75800 nid=0x82a runnable GC task thread#1 (ParallelGC) prio=10 tid=0x08b77000 nid=0x82b runnable GC task thread#2 (ParallelGC) prio=10 tid=0x08b78800 nid=0x82c runnable GC task thread#3 (ParallelGC) prio=10 tid=0x08b79c00 nid=0x82d runnable VM Periodic Task Thread prio=10
