[jira] [Commented] (FELIX-58) Extend HTTP Service to support deploying WARs
[ https://issues.apache.org/jira/browse/FELIX-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898900#comment-13898900 ] Achim Nierbeck commented on FELIX-58: - Just for the record, in case one stumbles over this Jira entry and is looking for a solution. Pax Web does provide this feature. > Extend HTTP Service to support deploying WARs > - > > Key: FELIX-58 > URL: https://issues.apache.org/jira/browse/FELIX-58 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Reporter: Richard S. Hall >Assignee: Marcel Offermans >Priority: Minor > > Since our HTTP Service uses Jetty underneath, it would be interesting to > extend it to support deploying WARs in bundles. Marcel Offermans has done > some work in this area, so I am assigning this issue to him. :-) I am not > sure if this issue can be done independently of a move to Jetty 5/6 (see > FELIX-55) or if it should be coordinated or merged somehow. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (FELIX-58) Extend HTTP Service to support deploying WARs
[ https://issues.apache.org/jira/browse/FELIX-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.W. Janssen closed FELIX-58. - Resolution: Won't Fix After 8 years nobody has taken a stab at this, so I guess it won't be fixed any time soon. If somebody really wants this functionality, they should reopen this issue and provide a patch. Closing this one... > Extend HTTP Service to support deploying WARs > - > > Key: FELIX-58 > URL: https://issues.apache.org/jira/browse/FELIX-58 > Project: Felix > Issue Type: New Feature > Components: HTTP Service >Reporter: Richard S. Hall >Assignee: Marcel Offermans >Priority: Minor > > Since our HTTP Service uses Jetty underneath, it would be interesting to > extend it to support deploying WARs in bundles. Marcel Offermans has done > some work in this area, so I am assigning this issue to him. :-) I am not > sure if this issue can be done independently of a move to Jetty 5/6 (see > FELIX-55) or if it should be coordinated or merged somehow. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (FELIX-4419) Open access to InstanceDeclaration and TypeDeclaration
I would be in favor on an immutable object. Maybe a builder cloning the configuration of an existing declaration. On 11 févr. 2014, at 19:04, Guillaume Sauthier (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/FELIX-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898083#comment-13898083 > ] > > Guillaume Sauthier commented on FELIX-4419: > --- > > I'm wondering if the created InstanceDeclaration should be modifiable after > creation ? > Like renaming, changing properties, ... > > > >> Open access to InstanceDeclaration and TypeDeclaration >> -- >> >>Key: FELIX-4419 >>URL: https://issues.apache.org/jira/browse/FELIX-4419 >>Project: Felix >> Issue Type: Bug >> Components: iPOJO >> Affects Versions: ipojo-runtime-1.11.0 >> Reporter: Clement Escoffier >> Assignee: Clement Escoffier >>Fix For: ipojo-runtime-1.12.0 >> >> > > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160)
Re: [VOTE] Release of Jaas Support Bundle 0.0.2
+1, Regards, Clement On 11 févr. 2014, at 11:36, Chetan Mehrotra wrote: > I would like to call a vote on the initial release of the Apache Felix > JAAS Support Bundle. For details on how to use it refer to > http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1006/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1006 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > Initial Release 0.0.2 > - > > ** Task >* [FELIX-3935] - Add testcases for validating the JAAS Feature > implementation >* [FELIX-3980] - Add documentation related to usage of Felix JAAS Bundle >* [FELIX-3981] - Create a sample project for demonstrating Felix > JAAS main features >* [FELIX-3989] - Add support for determining code coverage with > integration testcases >* [FELIX-4318] - prepare for initial release of JAAS Bundle > > ** Bug >* [FELIX-3985] - ConfigSpiOsgi should be registered by default >* [FELIX-3998] - Updating JAAS config leads to registration of > duplicate LoginModules >* [FELIX-4387] - JAAS config fields are initialized too late in > the ConfigSpiOsgi constructor >* [FELIX-4390] - Login modules registered via LMF not updated if > LMF service config changes > > ** Improvement >* [FELIX-3983] - Use inlined Sling commons PropertiesUtil for > reading config values >* [FELIX-3984] - Use default application/realm name of 'other' if > none specified >* [FELIX-4389] - Configuration ranking for LMF services should > also use "jaas.ranking" property >* [FELIX-4414] - Empty string value in jaas.realm should also > trigger default > > ** New Feature >* [FELIX-3705] - Bundle to simplify JAAS usage in OSGi > > Release notes also available at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12323385 > > Chetan Mehrotra
Re: [VOTE] Release of Jaas Support Bundle 0.0.2
On Tue, Feb 11, 2014 at 2:36 AM, Chetan Mehrotra wrote: > I would like to call a vote on the initial release of the Apache Felix > JAAS Support Bundle. For details on how to use it refer to > http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1006/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1006 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) Here's my non binding vote: +1 Approve the release regards, toby
[jira] [Commented] (FELIX-4419) Open access to InstanceDeclaration and TypeDeclaration
[ https://issues.apache.org/jira/browse/FELIX-4419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898083#comment-13898083 ] Guillaume Sauthier commented on FELIX-4419: --- I'm wondering if the created InstanceDeclaration should be modifiable after creation ? Like renaming, changing properties, ... > Open access to InstanceDeclaration and TypeDeclaration > -- > > Key: FELIX-4419 > URL: https://issues.apache.org/jira/browse/FELIX-4419 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.11.0 >Reporter: Clement Escoffier >Assignee: Clement Escoffier > Fix For: ipojo-runtime-1.12.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: [VOTE] Release of Jaas Support Bundle 0.0.2
+1 Regards Felix Am 11.02.2014 um 11:36 schrieb Chetan Mehrotra : > I would like to call a vote on the initial release of the Apache Felix > JAAS Support Bundle. For details on how to use it refer to > http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1006/ > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1006 /tmp/felix-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > Initial Release 0.0.2 > - > > ** Task >* [FELIX-3935] - Add testcases for validating the JAAS Feature > implementation >* [FELIX-3980] - Add documentation related to usage of Felix JAAS Bundle >* [FELIX-3981] - Create a sample project for demonstrating Felix > JAAS main features >* [FELIX-3989] - Add support for determining code coverage with > integration testcases >* [FELIX-4318] - prepare for initial release of JAAS Bundle > > ** Bug >* [FELIX-3985] - ConfigSpiOsgi should be registered by default >* [FELIX-3998] - Updating JAAS config leads to registration of > duplicate LoginModules >* [FELIX-4387] - JAAS config fields are initialized too late in > the ConfigSpiOsgi constructor >* [FELIX-4390] - Login modules registered via LMF not updated if > LMF service config changes > > ** Improvement >* [FELIX-3983] - Use inlined Sling commons PropertiesUtil for > reading config values >* [FELIX-3984] - Use default application/realm name of 'other' if > none specified >* [FELIX-4389] - Configuration ranking for LMF services should > also use "jaas.ranking" property >* [FELIX-4414] - Empty string value in jaas.realm should also > trigger default > > ** New Feature >* [FELIX-3705] - Bundle to simplify JAAS usage in OSGi > > Release notes also available at > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12323385 > > Chetan Mehrotra
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897830#comment-13897830
]
Felix Meschberger commented on FELIX-4424:
--
[~jajans] Thanks alot. This is just a quick shot approach which I did not
actually thoroughly test, though :-)
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897833#comment-13897833
]
J.W. Janssen commented on FELIX-4424:
-
No problem, I'll ponder about the solution a little as well ;)
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Work started] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4424 started by J.W. Janssen.
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897821#comment-13897821
]
J.W. Janssen commented on FELIX-4424:
-
I'm already busy in this area, so I'll be happy to apply the proposed patch...
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (FELIX-4424) ClassLoader leak in Http Service ServletContextManager
[
https://issues.apache.org/jira/browse/FELIX-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.W. Janssen reassigned FELIX-4424:
---
Assignee: J.W. Janssen
> ClassLoader leak in Http Service ServletContextManager
> --
>
> Key: FELIX-4424
> URL: https://issues.apache.org/jira/browse/FELIX-4424
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Reporter: Chetan Mehrotra
>Assignee: J.W. Janssen
>
> While analyzing heap dump for classloader leaks using script [1] following
> possible leak was reported
> {noformat}
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
>Following are few of the live paths found
>Live path
> com.day.crx.packmgr.impl.AuthHttpContext@0x124214d18
> java.util.HashMap$Entry@0x12429db50
> [Ljava.util.HashMap$Entry;@0x1238f47b0
> java.util.HashMap@0x1238f4780
>
> org.apache.felix.http.base.internal.context.ServletContextManager@0x1238f4760
> [*]
>
> org.apache.felix.http.base.internal.service.HttpServiceImpl@0x1238f45c0 [*]
>
> org.apache.felix.framework.ServiceRegistry$UsageCount@0x1238f45a8
>
> [Lorg.apache.felix.framework.ServiceRegistry$UsageCount;@0x129efb430
> java.util.HashMap$Entry@0x1235ee950
> [Ljava.util.HashMap$Entry;@0x1249e2b78
> java.util.HashMap@0x123484668
> org.apache.felix.framework.ServiceRegistry@0x12339c108
> org.apache.felix.framework.ServiceRegistrationImpl@0x126a7a3c8
> java.util.concurrent.atomic.AtomicReference@0x126a7a3b8
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x126a79ab8 [*]
> java.util.HashMap$Entry@0x126a9c3f0
> java.util.HashMap$Entry@0x1286ce7a0
> [Ljava.util.HashMap$Entry;@0x124884030
> java.util.HashMap@0x1238f1ce0
> org.apache.felix.scr.impl.ComponentRegistry@0x1236757f0 [*]
> org.apache.felix.scr.impl.BundleComponentActivator@0x127152bd0
> [*]
>
> org.apache.felix.scr.impl.config.ImmediateComponentHolder@0x127153a08 [*]
>
> org.apache.felix.scr.impl.manager.DelayedComponentManager@0x127154398 [*]
> org.apache.felix.scr.impl.manager.DependencyManager@0x127154720
> [*]
> {noformat}
> In our case the AuthHttpContext was being registered via the Whiteboard
> pattern. The dump shows that ServletContextManager [2] uses the HttpContext
> as key for the map however it is never removed. If our bundle would had used
> HttpService directly then internal map would have been GC upon bundle
> deactivation.
> In Felix HttpService is registered as a ServiceFactory however as all
> interactions with HttpService is done via Whiteboard bundle the HttpService
> is bound to Whiteboard bundle. So such HttpContext might remain for the
> lifetime of whiteboard bundle and hence cause classloader leak.
> [1] https://gist.github.com/chetanmeh/8860776
> [2]
> https://github.com/apache/felix/blob/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/context/ServletContextManager.java
> PS: The lines marked with [*] are objects which are from valid bundle and are
> maintaining hard reference to the objects from classloader which should have
> been GC
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[VOTE] Release of Jaas Support Bundle 0.0.2
I would like to call a vote on the initial release of the Apache Felix JAAS Support Bundle. For details on how to use it refer to http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1006/ You can use this UNIX script to download the release and verify the signatures: http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh Usage: sh check_staged_release.sh 1006 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) Initial Release 0.0.2 - ** Task * [FELIX-3935] - Add testcases for validating the JAAS Feature implementation * [FELIX-3980] - Add documentation related to usage of Felix JAAS Bundle * [FELIX-3981] - Create a sample project for demonstrating Felix JAAS main features * [FELIX-3989] - Add support for determining code coverage with integration testcases * [FELIX-4318] - prepare for initial release of JAAS Bundle ** Bug * [FELIX-3985] - ConfigSpiOsgi should be registered by default * [FELIX-3998] - Updating JAAS config leads to registration of duplicate LoginModules * [FELIX-4387] - JAAS config fields are initialized too late in the ConfigSpiOsgi constructor * [FELIX-4390] - Login modules registered via LMF not updated if LMF service config changes ** Improvement * [FELIX-3983] - Use inlined Sling commons PropertiesUtil for reading config values * [FELIX-3984] - Use default application/realm name of 'other' if none specified * [FELIX-4389] - Configuration ranking for LMF services should also use "jaas.ranking" property * [FELIX-4414] - Empty string value in jaas.realm should also trigger default ** New Feature * [FELIX-3705] - Bundle to simplify JAAS usage in OSGi Release notes also available at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12323385 Chetan Mehrotra
[jira] [Updated] (FELIX-3981) Create a sample project for demonstrating Felix JAAS main features
[ https://issues.apache.org/jira/browse/FELIX-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3981: --- Fix Version/s: (was: jaas-0.0.2) jaas-1.0.0 > Create a sample project for demonstrating Felix JAAS main features > -- > > Key: FELIX-3981 > URL: https://issues.apache.org/jira/browse/FELIX-3981 > Project: Felix > Issue Type: Task > Components: JAAS >Affects Versions: jaas-0.0.2 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-1.0.0 > > > In addition to the documentation around JAAS support (FELIX-3980) it would be > helpful if sample projects can be provided which quickly demonstrate JAAS > usage. The sample code can live under [1] > As of now one can get some details from wiki [2] and testcases [3] > [1] http://svn.apache.org/repos/asf/felix/trunk/examples > [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi > [3] > http://svn.apache.org/repos/asf/felix/trunk/jaas/src/test/java/org/apache/felix/jaas/integration -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-4318) prepare for initial release of JAAS Bundle
[ https://issues.apache.org/jira/browse/FELIX-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved FELIX-4318. Resolution: Fixed All relevant work done > prepare for initial release of JAAS Bundle > -- > > Key: FELIX-4318 > URL: https://issues.apache.org/jira/browse/FELIX-4318 > Project: Felix > Issue Type: Task > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-0.0.2 > > > The JAAS bundle needs to be released. To do that some task needs to be > completed > * Add changelog.txt > * Add ProviderType, ConsumerType annotations to the packages exported > Any other required change -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (FELIX-3981) Create a sample project for demonstrating Felix JAAS main features
[ https://issues.apache.org/jira/browse/FELIX-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897687#comment-13897687 ] Chetan Mehrotra commented on FELIX-3981: The examples have been ported to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/ Need to work on a readme to use these examples > Create a sample project for demonstrating Felix JAAS main features > -- > > Key: FELIX-3981 > URL: https://issues.apache.org/jira/browse/FELIX-3981 > Project: Felix > Issue Type: Task > Components: JAAS >Affects Versions: jaas-0.0.2 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-0.0.2 > > > In addition to the documentation around JAAS support (FELIX-3980) it would be > helpful if sample projects can be provided which quickly demonstrate JAAS > usage. The sample code can live under [1] > As of now one can get some details from wiki [2] and testcases [3] > [1] http://svn.apache.org/repos/asf/felix/trunk/examples > [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi > [3] > http://svn.apache.org/repos/asf/felix/trunk/jaas/src/test/java/org/apache/felix/jaas/integration -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-3980) Add documentation related to usage of Felix JAAS Bundle
[ https://issues.apache.org/jira/browse/FELIX-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved FELIX-3980. Resolution: Fixed Relevant documentation is added to http://felix.apache.org/documentation/subprojects/apache-felix-jaas.html > Add documentation related to usage of Felix JAAS Bundle > --- > > Key: FELIX-3980 > URL: https://issues.apache.org/jira/browse/FELIX-3980 > Project: Felix > Issue Type: Task > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-0.0.2 > > > The documentation of the Felix JAAS Module currently is present at [1]. This > needs to be moved to Apache Felix website > [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (FELIX-3935) Add testcases for validating the JAAS Feature implementation
[ https://issues.apache.org/jira/browse/FELIX-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved FELIX-3935. Resolution: Fixed Initial planned testcase have been made. More would be added by specific issues > Add testcases for validating the JAAS Feature implementation > > > Key: FELIX-3935 > URL: https://issues.apache.org/jira/browse/FELIX-3935 > Project: Felix > Issue Type: Task > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-0.0.2 > > Original Estimate: 120h > Remaining Estimate: 120h > > Need to add testcases to validate various scenarios supported by JAAS support > in OSGi env -- This message was sent by Atlassian JIRA (v6.1.5#6160)
