[jira] [Assigned] (FELIX-3511) Apache Felix EventAdmin 1.3.0 -> Without oswego stuff
[ https://issues.apache.org/jira/browse/FELIX-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-3511: --- Assignee: Carsten Ziegeler > Apache Felix EventAdmin 1.3.0 -> Without oswego stuff > - > > Key: FELIX-3511 > URL: https://issues.apache.org/jira/browse/FELIX-3511 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin-1.3.0 >Reporter: Matthias Donat >Assignee: Carsten Ziegeler >Priority: Minor > Labels: java, license, patch > Fix For: eventadmin-1.3.4 > > > The Event Admin bundle uses content from Oswego > (EDU.oswego.cs.dl.util.concurrent) that is functional also available in the > standard java library (java.util.concurrent). > I have made a version without the Oswego stuff based on the actual trunk (rev > 1324766) using java.util.concurrent. > Perhaps it would be nice to use it in future 'official' versions ? > It would also eliminate the need to put the extra-license from Oswego > discussed > earlier (http://osdir.com/ml/dev-felix-apache/2010-02/msg00401.html) > Contact me if you're interested, > M.Donat -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-3511) Apache Felix EventAdmin 1.3.0 -> Without oswego stuff
[ https://issues.apache.org/jira/browse/FELIX-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-3511: Fix Version/s: eventadmin-1.3.4 > Apache Felix EventAdmin 1.3.0 -> Without oswego stuff > - > > Key: FELIX-3511 > URL: https://issues.apache.org/jira/browse/FELIX-3511 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin-1.3.0 >Reporter: Matthias Donat >Priority: Minor > Labels: java, license, patch > Fix For: eventadmin-1.3.4 > > > The Event Admin bundle uses content from Oswego > (EDU.oswego.cs.dl.util.concurrent) that is functional also available in the > standard java library (java.util.concurrent). > I have made a version without the Oswego stuff based on the actual trunk (rev > 1324766) using java.util.concurrent. > Perhaps it would be nice to use it in future 'official' versions ? > It would also eliminate the need to put the extra-license from Oswego > discussed > earlier (http://osdir.com/ml/dev-felix-apache/2010-02/msg00401.html) > Contact me if you're interested, > M.Donat -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-3511) Use java.concurrent from Java 6
[ https://issues.apache.org/jira/browse/FELIX-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-3511: Summary: Use java.concurrent from Java 6 (was: Apache Felix EventAdmin 1.3.0 -> Without oswego stuff) > Use java.concurrent from Java 6 > --- > > Key: FELIX-3511 > URL: https://issues.apache.org/jira/browse/FELIX-3511 > Project: Felix > Issue Type: Improvement > Components: Event Admin >Affects Versions: eventadmin-1.3.0 >Reporter: Matthias Donat >Assignee: Carsten Ziegeler >Priority: Minor > Labels: java, license, patch > Fix For: eventadmin-1.3.4 > > > The Event Admin bundle uses content from Oswego > (EDU.oswego.cs.dl.util.concurrent) that is functional also available in the > standard java library (java.util.concurrent). > I have made a version without the Oswego stuff based on the actual trunk (rev > 1324766) using java.util.concurrent. > Perhaps it would be nice to use it in future 'official' versions ? > It would also eliminate the need to put the extra-license from Oswego > discussed > earlier (http://osdir.com/ml/dev-felix-apache/2010-02/msg00401.html) > Contact me if you're interested, > M.Donat -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
[
https://issues.apache.org/jira/browse/FELIX-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-4523:
-
Assignee: Karl Pauls
> Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
> --
>
> Key: FELIX-4523
> URL: https://issues.apache.org/jira/browse/FELIX-4523
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.2.1
> Environment: linux, junittests
>Reporter: Benjamin Rogge
>Assignee: Karl Pauls
>
> From time to time we are experiencing a deadlock in the URLHandlers Class in
> Apache Felix. We are using Felix as an embedded OSGi Container and
> instantiate the Felix Framework via ServiceLoader and Framework Factory
> ourselves. The situation is as follows: When Felix.stop and Felix.init are
> called by different threads, eventually
> URLHandlers.unregisterFrameworkListsForContextSearch and
> URLHandlers.registerFrameworkInstance are called by the threads. There are
> two locks: m_frameworks and the Class Object of URL (URL.class).
> registerFrameworkInstance tries to aquire m_frameworks first and via the
> constructor of URLHanders URL.class after that.
> unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
> m_frameworks after that. This is a classic deadlock situation. The situation
> arises in unittests where we frequently start and stop the felix framework.
> Stacktracke log:
> {code}
> Found one Java-level deadlock:
> =
> "FelixShutdown":
> waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
> java.util.ArrayList),
> which is held by "main"
> "main":
> waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
> java.lang.Class),
> which is held by "FelixShutdown"
> Java stack information for the threads listed above:
> ===
> "FelixShutdown":
> at
> org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
> - waiting to lock <0x0007ff33e7f0> (a java.util.ArrayList)
> - locked <0x0007ff33e840> (a java.util.HashMap)
> - locked <0x000783b06b18> (a java.lang.Class for java.net.URL)
> 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:606)
> at
> org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
> at
> org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
> at
> org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
> at
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
> at
> org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
> at
> org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
> at org.apache.felix.framework.Felix$2.run(Felix.java:959)
> at java.lang.Thread.run(Thread.java:724)
> "main":
> at org.apache.felix.framework.URLHandlers.(URLHandlers.java:150)
> - waiting to lock <0x000783b06b18> (a java.lang.Class for
> java.net.URL)
> at
> org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
> - locked <0x0007ff33e7f0> (a java.util.ArrayList)
> at
> org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at
> org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
> at org.apache.felix.framework.Felix.init(Felix.java:783)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4523) Deadlock in URLHandlers when Felix.init and Felix.stop are called concurrently
Benjamin Rogge created FELIX-4523:
-
Summary: Deadlock in URLHandlers when Felix.init and Felix.stop
are called concurrently
Key: FELIX-4523
URL: https://issues.apache.org/jira/browse/FELIX-4523
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.2.1
Environment: linux, junittests
Reporter: Benjamin Rogge
>From time to time we are experiencing a deadlock in the URLHandlers Class in
>Apache Felix. We are using Felix as an embedded OSGi Container and instantiate
>the Felix Framework via ServiceLoader and Framework Factory ourselves. The
>situation is as follows: When Felix.stop and Felix.init are called by
>different threads, eventually
>URLHandlers.unregisterFrameworkListsForContextSearch and
>URLHandlers.registerFrameworkInstance are called by the threads. There are two
>locks: m_frameworks and the Class Object of URL (URL.class).
>registerFrameworkInstance tries to aquire m_frameworks first and via the
>constructor of URLHanders URL.class after that.
>unregisterFrameworkListsForContextSearch tries to aquire URL.class first and
>m_frameworks after that. This is a classic deadlock situation. The situation
>arises in unittests where we frequently start and stop the felix framework.
Stacktracke log:
{code}
Found one Java-level deadlock:
=
"FelixShutdown":
waiting to lock monitor 0x00ff7710 (object 0x0007ff33e7f0, a
java.util.ArrayList),
which is held by "main"
"main":
waiting to lock monitor 0x022c4a08 (object 0x000783b06b18, a
java.lang.Class),
which is held by "FelixShutdown"
Java stack information for the threads listed above:
===
"FelixShutdown":
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkListsForContextSearch(URLHandlers.java:315)
- waiting to lock <0x0007ff33e7f0> (a java.util.ArrayList)
- locked <0x0007ff33e840> (a java.util.HashMap)
- locked <0x000783b06b18> (a java.lang.Class for java.net.URL)
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:606)
at
org.apache.felix.framework.util.SecureAction.invoke(SecureAction.java:840)
at
org.apache.felix.framework.URLHandlers.unregisterFrameworkInstance(URLHandlers.java:635)
at
org.apache.felix.framework.URLHandlersActivator.stop(URLHandlersActivator.java:76)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at
org.apache.felix.framework.Felix$SystemBundleActivator.stop(Felix.java:4715)
at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:667)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2530)
at org.apache.felix.framework.Felix$2.run(Felix.java:959)
at java.lang.Thread.run(Thread.java:724)
"main":
at org.apache.felix.framework.URLHandlers.(URLHandlers.java:150)
- waiting to lock <0x000783b06b18> (a java.lang.Class for
java.net.URL)
at
org.apache.felix.framework.URLHandlers.registerFrameworkInstance(URLHandlers.java:600)
- locked <0x0007ff33e7f0> (a java.util.ArrayList)
at
org.apache.felix.framework.URLHandlersActivator.start(URLHandlersActivator.java:71)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at
org.apache.felix.framework.Felix$SystemBundleActivator.start(Felix.java:4634)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645)
at org.apache.felix.framework.Felix.init(Felix.java:783)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-3239) PackageAdmin#getExportedPackages does not work on packages exported by attached fragments
[ https://issues.apache.org/jira/browse/FELIX-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14008780#comment-14008780 ] Bertrand Delacretaz commented on FELIX-3239: Thanks David, your test does match my scenario. And it is *a bit* simpler than mine ;-) > PackageAdmin#getExportedPackages does not work on packages exported by > attached fragments > - > > Key: FELIX-3239 > URL: https://issues.apache.org/jira/browse/FELIX-3239 > Project: Felix > Issue Type: Bug >Affects Versions: framework-4.0.1 >Reporter: Guillaume Nodet >Assignee: David Bosschaert > Fix For: framework-4.6.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4420) [HTTP SSLFilter] Implement sendRedirect
[ https://issues.apache.org/jira/browse/FELIX-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen resolved FELIX-4420. - Resolution: Fixed Applied proposed patch (incl. review comments) in rev #1597554. > [HTTP SSLFilter] Implement sendRedirect > --- > > Key: FELIX-4420 > URL: https://issues.apache.org/jira/browse/FELIX-4420 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Affects Versions: http-2.2.1, http-2.2.2 >Reporter: Felix Meschberger >Assignee: J.W. Janssen > Fix For: http-2.3.0, http-sslfilter-1.0.0 > > Attachments: FELIX-4420.patch > > > The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the > actual protocol used by the client side browser by inspecting a request > header and exposing the proper scheme through its ServletRequest.getScheme() > implementation if the actual server is operated behind an SSL terminating > proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to > server over plain HTTP) > The HttpServletRequest.sendRedirect() method is declared to set the Location > header to the absolute redirect URL which includes the scheme. In an SSL > terminating proxy situation, the servlet container does not know about this > fact and hence uses the actual server scheme (HTTP) for the redirect instead > of the scheme used by client. > To fix this situation the SSL filter response should implement the > HttpServletResponse.sendRedirect() method to use use the client side scheme > as extracted from the request instead of the actual server request. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4522) PojoSRBundleContext should read org.osgi.framework.storage property from Bundle config
[
https://issues.apache.org/jira/browse/FELIX-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated FELIX-4522:
---
Attachment: FELIX-4522.patch
> PojoSRBundleContext should read org.osgi.framework.storage property from
> Bundle config
> --
>
> Key: FELIX-4522
> URL: https://issues.apache.org/jira/browse/FELIX-4522
> Project: Felix
> Issue Type: Improvement
> Components: Connect
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: connect-0.1.0
>
> Attachments: FELIX-4522.patch
>
>
> {{PojoSRBundleContext}} currently read the value of
> {{org.osgi.framework.storage}} from system property. It would better (from
> isolation perspective) to read the value from the config map which is passed
> initially to {{PojoServiceRegistryFactory}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (FELIX-4522) PojoSRBundleContext should read org.osgi.framework.storage property from Bundle config
Chetan Mehrotra created FELIX-4522:
--
Summary: PojoSRBundleContext should read
org.osgi.framework.storage property from Bundle config
Key: FELIX-4522
URL: https://issues.apache.org/jira/browse/FELIX-4522
Project: Felix
Issue Type: Improvement
Components: Connect
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
Fix For: connect-0.1.0
{{PojoSRBundleContext}} currently read the value of
{{org.osgi.framework.storage}} from system property. It would better (from
isolation perspective) to read the value from the config map which is passed
initially to {{PojoServiceRegistryFactory}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
