[jira] [Created] (FELIX-3847) java.io.IOException: Resource does not exist: bundle://1.0:1/gosh_profile
TangYong created FELIX-3847: --- Summary: java.io.IOException: Resource does not exist: bundle://1.0:1/gosh_profile Key: FELIX-3847 URL: https://issues.apache.org/jira/browse/FELIX-3847 Project: Felix Issue Type: Bug Components: Gogo Shell Affects Versions: gogo.shell-0.10.0 Environment: 1 felix 4.0.3 2 gogo shell 0.10.0 3 jdk 1.7 4 windows xp 5 glassfish v4 snapshot Reporter: TangYong Priority: Critical [Background] While I embed felix 4.0.3 and gogo shell 0.10.0 and other related bundles into a war, and then deployed the war into glassfish, the issue happened again although FELIX-2446 seemed to have been fixed. The result is that felix gogo shell can not be connected using "telnet localhost ". The stacktrace is as following, [#|2013-01-15T12:16:47.953+0900|SEVERE|glassfish 4.0|javax.enterprise.logging.stderr|_ThreadID=97;_ThreadName=telnetconsole.shell remote=/127.0.0.1:2571;_TimeMillis=1358219807953;_LevelValue=1000;|java.io.IOException: Resource does not exist: bundle://1.0:1/gosh_profile at org.apache.felix.framework.URLHandlersBundleURLConnection.(URLHandlersBundleURLConnection.java:136) at org.apache.felix.framework.URLHandlersBundleStreamHandler.openConnection(URLHandlersBundleStreamHandler.java:64) at java.net.URL.openConnection(URL.java:971) at org.apache.felix.gogo.shell.Shell.readScript(Shell.java:209) at org.apache.felix.gogo.shell.Shell.source(Shell.java:192) at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137) at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82) at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477) at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403) at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183) at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120) at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89) at org.apache.felix.shell.remote.Shell.startGogoShell(Shell.java:108) at org.apache.felix.shell.remote.Shell.run(Shell.java:81) at java.lang.Thread.run(Thread.java:722) |#] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
[
https://issues.apache.org/jira/browse/FELIX-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald Chen updated FELIX-3846:
---
Description:
There is a race condition during the activation of the felix http jetty bundle
when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.Server.doStart(Server.java:224)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37]
I debugged into line Felix.java:3209 and discovered the cause by is thrown by
Felix.java:4875 which is:
throw new IllegalStateException("Unable to acquire bundle lock, thread
interrupted.");
I dug around and discovered the thread which acquired the lock was the one
created on JettyService.java:75
Looking at usages of the thread field, I think I discovered the source of the
interrupt on line JettyService.java:75.
What I think is happening is this:
1. felix container starts jetty bundle
2. jetty activator is run which creates a new jetty service
3. jetty service creates a new thread and initializes jetty
4. jetty attempts to register the http service to the felix container and
obtains the felix bundle lock (Felix.java:4871)
5. at the same time something calls JettyService.update(Dictionary) which
interrupts the thread in attempts to restart the jetty server
6. this causes the felix bundle lock to be interrupted and
IllegalStateException is thrown
At which point the http service is not registered and we sob quietly.
To fix this issue I think the thread jetty service creates should never leave
the jetty space. When it needs to register the http service a new thread
should be created so it doesn't allow the possibility of the jetty service
thread to obtain a lock it shouldn't.
Alternatively in stop using interrupt() to signal change as it is dangerous!
Use a java 5 concurrent lock object.
Repo case:
I can repo this case within my own system by restarting bundle "Apache Felix
Http Jetty (2.2.0)" again and again, but I don't know if there is a smaller
repo case.
was:
There is a race condition during the activation of the felix http jetty bundle
when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.
[jira] [Updated] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
[
https://issues.apache.org/jira/browse/FELIX-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald Chen updated FELIX-3846:
---
Description:
There is a race condition during the activation of the felix http jetty bundle
when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.Server.doStart(Server.java:224)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37]
I debugged into line Felix.java:3209 and discovered the cause by is thrown by
Felix.java:4875 which is:
throw new IllegalStateException("Unable to acquire bundle lock, thread
interrupted.");
I dug around and discovered the thread which acquired the lock was the one
created on JettyService.java:75
Looking at usages of the thread field, I think I discovered the source of the
interrupt on line JettyService.java:75.
What I think is happening is this:
1. felix container starts jetty bundle
2. jetty activator is run which creates a new jetty service
3. jetty service creates a new thread and initializes jetty
4. jetty attempts to register the http service to the felix container and
obtains the felix bundle lock (Felix.java:4871)
5. at the same time something calls JettyService.update(Dictionary) which
interrupts the thread in attempts to restart the jetty server
6. this causes the felix bundle lock to be interrupted and
IllegalStateException is thrown
At which point the http service is not registered and we sob quietly.
To fix this issue I think the thread jetty service creates should never leave
the jetty space. When it needs to register the http service a new thread
should be created so it doesn't allow the possibility of the jetty service
thread to obtain a lock it shouldn't.
Alternatively in stop using interrupt() to signal change as it is dangerous!
Use a java 5 concurrent lock object.
was:
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
[jira] [Updated] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
[
https://issues.apache.org/jira/browse/FELIX-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald Chen updated FELIX-3846:
---
Description:
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.Server.doStart(Server.java:224)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37]
I debugged into line Felix.java:3209 and discovered the cause by is thrown by
Felix.java:4875 which is:
throw new IllegalStateException("Unable to acquire bundle lock, thread
interrupted.");
I dug around and discovered the thread which acquired the lock was the one
created on JettyService.java:75
Looking at usages of the thread field, I think I discovered the source of the
interrupt on line JettyService.java:75.
What I think is happening is this:
1. felix container starts jetty bundle
2. jetty activator is run which creates a new jetty service
3. jetty service creates a new thread and initializes jetty
4. jetty attempts to register the http service to the felix container and
obtains the felix bundle lock (Felix.java:4871)
5. at the same time something calls JettyService.update(Dictionary) which
interrupts the thread in attempts to restart the jetty server
6. this causes the felix bundle lock to be interrupted and
IllegalStateException is thrown
At which point the http service is not registered and we sob quietly.
To fix this issue I think the thread jetty service creates should never leave
the jetty space. When it needs to register the http service a new thread
should be created so it doesn't allow the possibility the jetty service thread
to obtain a lock it shouldn't.
Alternatively in stop using interrupt() to signal change as it is dangerous!
Use a java 5 concurrent lock object.
was:
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
{code}
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:n
[jira] [Updated] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
[
https://issues.apache.org/jira/browse/FELIX-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ronald Chen updated FELIX-3846:
---
Description:
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
{code}
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.Server.doStart(Server.java:224)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37]
{code}
I debugged into line Felix.java:3209 and discovered the cause by is thrown by
Felix.java:4875 which is:
throw new IllegalStateException("Unable to acquire bundle lock, thread
interrupted.");
I dug around and discovered the thread which acquired the lock was the one
created on JettyService.java:75
Looking at usages of the thread field, I think I discovered the source of the
interrupt on line JettyService.java:75.
What I think is happening is this:
1. felix container starts jetty bundle
2. jetty activator is run which creates a new jetty service
3. jetty service creates a new thread and initializes jetty
4. jetty attempts to register the http service to the felix container and
obtains the felix bundle lock (Felix.java:4871)
5. at the same time something calls JettyService.update(Dictionary) which
interrupts the thread in attempts to restart the jetty server
6. this causes the felix bundle lock to be interrupted and
IllegalStateException is thrown
At which point the http service is not registered and we sob quietly.
To fix this issue I think the thread jetty service creates should never leave
the jetty space. When it needs to register the http service a new thread
should be created so it doesn't allow the possibility the jetty service thread
to obtain a lock it shouldn't.
Alternatively in stop using interrupt() to signal change as it is dangerous!
Use a java 5 concurrent lock object.
was:
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.
[jira] [Created] (FELIX-3846) Felix + Felix HTTP Jetty causes IllegalStateException during start up
Ronald Chen created FELIX-3846:
--
Summary: Felix + Felix HTTP Jetty causes IllegalStateException
during start up
Key: FELIX-3846
URL: https://issues.apache.org/jira/browse/FELIX-3846
Project: Felix
Issue Type: Bug
Components: Framework, HTTP Service
Affects Versions: http-2.2.0, framework-4.0.3
Environment: Java version: 1.6.0_37, vendor: Apple Inc.
All operating systems
Reporter: Ronald Chen
There is a race condition during the activation of the of the felix http jetty
bundle when used within a felix container.
During the activation of the felix http jetty bundle you will intermittently
see:
java.lang.IllegalStateException: Can only register services while bundle is
active or activating.
at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
~[na:na]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
~[na:na]
at
org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
~[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at org.mortbay.jetty.Server.doStart(Server.java:224)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at
org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
[org.apache.felix.http.jetty_2.2.0.jar:na]
at java.lang.Thread.run(Thread.java:680) [na:1.6.0_37]
I debugged into line Felix.java:3209 and discovered the cause by is thrown by
Felix.java:4875 which is:
throw new IllegalStateException("Unable to acquire bundle lock, thread
interrupted.");
I dug around and discovered the thread which acquired the lock was the one
created on JettyService.java:75
Looking at usages of the thread field, I think I discovered the source of the
interrupt on line JettyService.java:75.
What I think is happening is this:
1. felix container starts jetty bundle
2. jetty activator is run which creates a new jetty service
3. jetty service creates a new thread and initializes jetty
4. jetty attempts to register the http service to the felix container and
obtains the felix bundle lock (Felix.java:4871)
5. at the same time something calls JettyService.update(Dictionary) which
interrupts the thread in attempts to restart the jetty server
6. this causes the felix bundle lock to be interrupted and
IllegalStateException is thrown
At which point the http service is not registered and we sob quietly.
To fix this issue I think the thread jetty service creates should never leave
the jetty space. When it needs to register the http service a new thread
should be created so it doesn't allow the possibility the jetty service thread
to obtain a lock it shouldn't.
Alternatively in stop using interrupt() to signal change as it is dangerous!
Use a java 5 concurrent lock object.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
AW: Metatype Service - OptionalAttributes - extra XML attributes with namespace support
Bridging the world of namespace-aware XML and not namespace-aware object models
like Java, where an object can only have one field (attribute) with the same
name,
is quite difficult. In other words if we allow for multiple namespaces for XML
attributes (which at the moment is the case according to the spec) then we must
also adopt
that concept of namespaces in the Java object model.
And as a note, (namespace) prefixes by them self are meaningless. They only
convey meaning if they are associated with a namespace.
So we need a solution which is namespace-aware and not limited to, but
compatible to XML. In the light of this I suggest the
following interface, where "namespace" is now a generic concept (abstraction)
and does not necessarily stand for XML-namespaces per se.
public interface ExtraAttributes {
/**
* List the names of extra attributes for a given namespace.
*
* @param namespace the namespace for which to retrieve the names of
available attribute.
*
* @return an {@link Iterator} producing the {@link String}s of the
extra attribute names.
* for the given namespace.
*/
public Iterator getExtraAttributeNames(String namespace);
/**
* Retrieve the value of an extra attribute.
*
* @param namespace the namespace from which to retrieve the attribute
value.
* @param name name of the extra attribute, whose value should be
retrieved.
* @return the value of the extra attribute or null if no
attribute with
* that name exists.
*/
public String getExtraAttributeValue(String namespace, String name);
}
What do you think.
Regards
Alex
--
finnova AG Bankware
Alexander Berger
Software Architect
Merkurstrasse 6
CH-5600 Lenzburg
Tel: +41 (0)62 886 48 07 (direkt)
Tel: +41 (0)62 886 47 47 (zentrale)
Fax: +41 (0)62 886 48 88
mailto:alexander.ber...@finnova.ch
http://www.finnova.ch
-Ursprüngliche Nachricht-
Von: Felix Meschberger [mailto:fmesc...@adobe.com]
Gesendet: Montag, 14. Januar 2013 10:39
An: dev@felix.apache.org
Betreff: Re: Metatype Service - OptionalAttributes - extra XML attributes with
namespace support
Hi
QNAme is an XML-ism and the API is XML-free (as I said, use of XML is just one
way to back the API). So I am extremely reluctant to using QName (regardless of
whether we use javax.xml.QName or define our own QName class). Always consider
the case where an QbjectClassDefinition might be backed by a MetaTypeProvider
service and not XML.
As for the interface (except QName question), I am fine.
However, I could assume we could have the name, if it comes from XML, to be
something like
{url}localname
or
prefix:localname
And, of course, the {url} or prefix: prefix would be omitted for the default
namespace (empty string) or the namespace of the metatype descriptor.
Regards
Felix
Am 14.01.2013 um 07:43 schrieb
:
> O.K. I see.
>
> Then I would suggest to add something like the following interface to
> AttributeDefinition and ObjectClassDefinition:
>
> public interface ExtraAttributes {
>
> /**
>* List the {@link QName}s of extra XML attributes.
>*
>* @return an {@link Iterator} producing the {@link QName}s of the
> extra attributes.
>*/
> public Iterator getExtraAttributeNames();
>
> /**
>* Retrieve the value of an extra XML attribute.
>*
>* @param name {@link QName} of the extra attribute, whose value should
> be retrieved.
>* @return the value of the extra attribute or null if no
> attribute with
>* that name exists.
>*/
> public String getExtraAttributeValue(QName name); }
>
> However, my initial question about QName and XML API support arises
> again as we are using QName here. Note, using just a String as
> argument to getExtraAttributeValue will not work, as several
> attributes with the same name but different Namespaces (prefixes) might exist
> on the same Element.
>
> Regards
> Alex
>
> --
> finnova AG Bankware
> Alexander Berger
> Software Architect
> Merkurstrasse 6
> CH-5600 Lenzburg
> Tel: +41 (0)62 886 48 07 (direkt)
> Tel: +41 (0)62 886 47 47 (zentrale)
> Fax: +41 (0)62 886 48 88
> mailto:alexander.ber...@finnova.ch
> http://www.finnova.ch
>
> -Ursprüngliche Nachricht-
> Von: Felix Meschberger [mailto:fmesc...@adobe.com]
> Gesendet: Samstag, 12. Januar 2013 22:15
> An: dev@felix.apache.org
> Betreff: Re: Metatype Service - OptionalAttributes - extra XML
> attributes with namespace support
>
>
> Am 10.01.2013 um 17:14 schrieb
> :
>
>> That's a good question.
>>
>> I think in terms of an API for accessing extra XML attributes,
>> chances are good that such an API could be standardized (at least
>> technically). But in terms of the specific "extra XML attributes" I
>> see no way to get them standardized. And I guess
Re: Metatype Service - OptionalAttributes - extra XML attributes with namespace support
Hi
QNAme is an XML-ism and the API is XML-free (as I said, use of XML is just one
way to back the API). So I am extremely reluctant to using QName (regardless of
whether we use javax.xml.QName or define our own QName class). Always consider
the case where an QbjectClassDefinition might be backed by a MetaTypeProvider
service and not XML.
As for the interface (except QName question), I am fine.
However, I could assume we could have the name, if it comes from XML, to be
something like
{url}localname
or
prefix:localname
And, of course, the {url} or prefix: prefix would be omitted for the default
namespace (empty string) or the namespace of the metatype descriptor.
Regards
Felix
Am 14.01.2013 um 07:43 schrieb
:
> O.K. I see.
>
> Then I would suggest to add something like the following interface to
> AttributeDefinition and ObjectClassDefinition:
>
> public interface ExtraAttributes {
>
> /**
>* List the {@link QName}s of extra XML attributes.
>*
>* @return an {@link Iterator} producing the {@link QName}s of the
> extra attributes.
>*/
> public Iterator getExtraAttributeNames();
>
> /**
>* Retrieve the value of an extra XML attribute.
>*
>* @param name {@link QName} of the extra attribute, whose value should
> be retrieved.
>* @return the value of the extra attribute or null if no
> attribute with
>* that name exists.
>*/
> public String getExtraAttributeValue(QName name);
> }
>
> However, my initial question about QName and XML API support arises again as
> we are using
> QName here. Note, using just a String as argument to getExtraAttributeValue
> will not work, as several
> attributes with the same name but different Namespaces (prefixes) might exist
> on the same
> Element.
>
> Regards
> Alex
>
> --
> finnova AG Bankware
> Alexander Berger
> Software Architect
> Merkurstrasse 6
> CH-5600 Lenzburg
> Tel: +41 (0)62 886 48 07 (direkt)
> Tel: +41 (0)62 886 47 47 (zentrale)
> Fax: +41 (0)62 886 48 88
> mailto:alexander.ber...@finnova.ch
> http://www.finnova.ch
>
> -Ursprüngliche Nachricht-
> Von: Felix Meschberger [mailto:fmesc...@adobe.com]
> Gesendet: Samstag, 12. Januar 2013 22:15
> An: dev@felix.apache.org
> Betreff: Re: Metatype Service - OptionalAttributes - extra XML attributes
> with namespace support
>
>
> Am 10.01.2013 um 17:14 schrieb
> :
>
>> That's a good question.
>>
>> I think in terms of an API for accessing extra XML attributes, chances
>> are good that such an API could be standardized (at least
>> technically). But in terms of the specific "extra XML attributes" I
>> see no way to get them standardized. And I guess that is the reason
>> why the XSD (XML Schema) for the metatype descriptions allows for extra
>> attributes (which reside in another XML namespace). Maybe someone that has
>> worked on the specification might clarify what the intention about allowing
>> the extra attributes was.
>
> Originally the idea was, that the same XML files would be used for metatype
> descriptors and other applications. Which is why it is lenient to other data.
>
>>
>> Unless I know more about the matter I long for the following:
>>
>> 1. Anybody can enrich the metatype descriptions with his own
>> (specific/individual) metadata.
>> The current specification supports this by allowing extra XML attributes
>> that reside in another namespace (##other).
>>
>> 2. An API to list respectively retrieve those extra attributes. And ideally
>> such an API could become part of the
>> metatype specification (new methods on the already existing interfaces or
>> on new sub-interfaces).
>
> Please also consider that XML files are only one source for metatype
> descriptors. Access is always through API which can also be implemented
> without having XML.
>
> One option I could conceive, though, would be that we extend the
> AttributeDefinition interface with a new method:
>
> String getExtraAttribute(String name);
>
> which returns the named attribute.
>
> WDYT ?
>
> Regards
> Felix
>
>
>>
>> Regards
>> Alex
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Felix Meschberger [mailto:fmesc...@adobe.com]
>> Gesendet: Donnerstag, 10. Januar 2013 15:58
>> An: dev@felix.apache.org
>> Betreff: Re: Metatype Service - OptionalAttributes - extra XML
>> attributes with namespace support
>>
>> Hi Alex,
>>
>> Sorry, I missed your message from last week.
>>
>> Am 10.01.2013 um 13:34 schrieb
>> :
>>
>>> I want to add some extra attributes to the metadata (XML) which will then
>>> be used by a (special) administration console which knows about that extra
>>> attributes. These extra attributes will be used to allow a more concise
>>> representation of Configurations in the Graphical User Interface (GUI). For
>>> example to show a value from a certain configuration property instead of
>>> its PID in the GUI, as PIDs are
