[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: --- Component/s: JAAS > 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-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > > 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 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-3982) Allow usage of LoginModule present outside of OSGi space
[ https://issues.apache.org/jira/browse/FELIX-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3982: --- Component/s: JAAS > Allow usage of LoginModule present outside of OSGi space > > > Key: FELIX-3982 > URL: https://issues.apache.org/jira/browse/FELIX-3982 > Project: Felix > Issue Type: Improvement > Components: JAAS >Affects Versions: jaas-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > The Sun JDK ships many LoginModule [1] out of the box. It should be possible > to use them within the OSGi > [1] http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/index.html -- 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-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 updated FELIX-3980: --- Component/s: JAAS > 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 >Affects Versions: jaas-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > > 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 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-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 updated FELIX-3935: --- Component/s: JAAS > 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 >Affects Versions: jaas-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Original Estimate: 120h > Remaining Estimate: 120h > > Need to add testcases to validate various scenarios supported by JAAS support > in OSGi env -- 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] [Created] (FELIX-3984) Use default application/realm name of 'other' if none specified
Chetan Mehrotra created FELIX-3984: -- Summary: Use default application/realm name of 'other' if none specified Key: FELIX-3984 URL: https://issues.apache.org/jira/browse/FELIX-3984 Project: Felix Issue Type: Improvement Components: JAAS Affects Versions: jaas-1.0.0 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Any LoginModule registered via config or factory SHOULD provide a realm/application name. However if none is specified then the realm name should be assumed to be 'other'. Following should be supported 1. In case no realm name specified via 'jaas.realmName' the value should be set to 'other' 2. This default value can be changed by Admin via Configuration Spi settings and set it to any other value The significance of using 'other' here is that LoginContext would first check config entry for provided applicationName. If none is found then it looks for config entry for an app name 'other'. So for default setup LoginModules which does not have any appname specified would be considered as part of 'other'. if the admin changes that then no such default logic would be used -- 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] [Resolved] (FELIX-3984) Use default application/realm name of 'other' if none specified
[ https://issues.apache.org/jira/browse/FELIX-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved FELIX-3984. Resolution: Fixed Added support with rev 1459204 along with testcase. Unless overridden by settings of ConfigurationSpi the LoginModule would be bound to application name 'other' if no explicit value is defined > Use default application/realm name of 'other' if none specified > --- > > Key: FELIX-3984 > URL: https://issues.apache.org/jira/browse/FELIX-3984 > Project: Felix > Issue Type: Improvement > Components: JAAS >Affects Versions: jaas-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > Any LoginModule registered via config or factory SHOULD provide a > realm/application name. However if none is specified then the realm name > should be assumed to be 'other'. > Following should be supported > 1. In case no realm name specified via 'jaas.realmName' the value should be > set to 'other' > 2. This default value can be changed by Admin via Configuration Spi settings > and set it to any other value > The significance of using 'other' here is that LoginContext would first check > config entry for provided applicationName. If none is found then it looks for > config entry for an app name 'other'. So for default setup LoginModules which > does not have any appname specified would be considered as part of 'other'. > if the admin changes that then no such default logic would be used -- 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] [Created] (FELIX-3985) ConfigSpiOsgi should be registered by default
Chetan Mehrotra created FELIX-3985: -- Summary: ConfigSpiOsgi should be registered by default Key: FELIX-3985 URL: https://issues.apache.org/jira/browse/FELIX-3985 Project: Felix Issue Type: Bug Components: JAAS Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor ConfigSpiOsgi does not registers the Configuration unless a configuration is explicitly provided for it. Instead it should register by default with a default config. If config is updated it should update itself -- 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] [Resolved] (FELIX-3985) ConfigSpiOsgi should be registered by default
[ https://issues.apache.org/jira/browse/FELIX-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved FELIX-3985. Resolution: Fixed Fixed with rev 1459226 Now the spi registers upon activation and assumes some default config. That config can be overriden via BundleContext properties. > ConfigSpiOsgi should be registered by default > -- > > Key: FELIX-3985 > URL: https://issues.apache.org/jira/browse/FELIX-3985 > Project: Felix > Issue Type: Bug > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > ConfigSpiOsgi does not registers the Configuration unless a configuration is > explicitly provided for it. Instead it should register by default with a > default config. If config is updated it should update itself -- 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-3983) Use inlined Sling commons PropertiesUtil for reading config values
[ https://issues.apache.org/jira/browse/FELIX-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3983: --- Component/s: JAAS > Use inlined Sling commons PropertiesUtil for reading config values > -- > > Key: FELIX-3983 > URL: https://issues.apache.org/jira/browse/FELIX-3983 > Project: Felix > Issue Type: Improvement > Components: JAAS >Affects Versions: jaas-1.0.0 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > Currently the config processing logic uses copied code from Sling Commons > OSGi PropertiesUtils. Instead of that it should inline that class to avoid > copying and also avoid any dependency -- 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-3983) Use inlined Sling commons PropertiesUtil for reading config values
[ https://issues.apache.org/jira/browse/FELIX-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3983: --- Affects Version/s: (was: jaas-0.0.2) > Use inlined Sling commons PropertiesUtil for reading config values > -- > > Key: FELIX-3983 > URL: https://issues.apache.org/jira/browse/FELIX-3983 > Project: Felix > Issue Type: Improvement > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > Currently the config processing logic uses copied code from Sling Commons > OSGi PropertiesUtils. Instead of that it should inline that class to avoid > copying and also avoid any dependency -- 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-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 updated FELIX-3935: --- Affects Version/s: (was: jaas-0.0.2) > 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 > Original Estimate: 120h > Remaining Estimate: 120h > > Need to add testcases to validate various scenarios supported by JAAS support > in OSGi env -- 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-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 updated FELIX-3980: --- Affects Version/s: (was: jaas-0.0.2) > 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 > > 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 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-3985) ConfigSpiOsgi should be registered by default
[ https://issues.apache.org/jira/browse/FELIX-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3985: --- Fix Version/s: jaas-0.0.2 > ConfigSpiOsgi should be registered by default > -- > > Key: FELIX-3985 > URL: https://issues.apache.org/jira/browse/FELIX-3985 > Project: Felix > Issue Type: Bug > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: jaas-0.0.2 > > > ConfigSpiOsgi does not registers the Configuration unless a configuration is > explicitly provided for it. Instead it should register by default with a > default config. If config is updated it should update itself -- 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-3983) Use inlined Sling commons PropertiesUtil for reading config values
[ https://issues.apache.org/jira/browse/FELIX-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3983: --- Fix Version/s: jaas-0.0.2 > Use inlined Sling commons PropertiesUtil for reading config values > -- > > Key: FELIX-3983 > URL: https://issues.apache.org/jira/browse/FELIX-3983 > Project: Felix > Issue Type: Improvement > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: jaas-0.0.2 > > > Currently the config processing logic uses copied code from Sling Commons > OSGi PropertiesUtils. Instead of that it should inline that class to avoid > copying and also avoid any dependency -- 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-3982) Allow usage of LoginModule present outside of OSGi space
[ https://issues.apache.org/jira/browse/FELIX-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated FELIX-3982: --- Affects Version/s: (was: jaas-0.0.2) > Allow usage of LoginModule present outside of OSGi space > > > Key: FELIX-3982 > URL: https://issues.apache.org/jira/browse/FELIX-3982 > Project: Felix > Issue Type: Improvement > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > > The Sun JDK ships many LoginModule [1] out of the box. It should be possible > to use them within the OSGi > [1] http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/index.html -- 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] [Created] (FELIX-3986) ThreadDumper comparators are not correctly implemented
Valentin Valchev created FELIX-3986: --- Summary: ThreadDumper comparators are not correctly implemented Key: FELIX-3986 URL: https://issues.apache.org/jira/browse/FELIX-3986 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-4.0.0 Reporter: Valentin Valchev Assignee: Valentin Valchev Fix For: webconsole-4.0.2 The ThreadComparator and ThreadGroupComparator do not handle correctly null values. In embedded java SE 7 it might cause the following exception: java.lang.IllegalArgumentException: Comparison method violates its general contract! at java.util.TimSort.mergeHi(TimSort.java:868) at java.util.TimSort.mergeAt(TimSort.java:485) at java.util.TimSort.mergeCollapse(TimSort.java:408) at java.util.TimSort.sort(TimSort.java:214) at java.util.TimSort.sort(TimSort.java:173) at java.util.Arrays.sort(Arrays.java:659) at org.apache.felix.webconsole.internal.misc.ThreadDumper.printThreadGroup(ThreadDumper.java:161) -- 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] [Resolved] (FELIX-3986) ThreadDumper comparators are not correctly implemented
[ https://issues.apache.org/jira/browse/FELIX-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-3986. - Resolution: Fixed fixed in rev.1459347 > ThreadDumper comparators are not correctly implemented > -- > > Key: FELIX-3986 > URL: https://issues.apache.org/jira/browse/FELIX-3986 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.0.0 >Reporter: Valentin Valchev >Assignee: Valentin Valchev > Fix For: webconsole-4.0.2 > > > The ThreadComparator and ThreadGroupComparator do not handle correctly null > values. In embedded java SE 7 it might cause the following exception: > java.lang.IllegalArgumentException: Comparison method violates its general > contract! > at java.util.TimSort.mergeHi(TimSort.java:868) > at java.util.TimSort.mergeAt(TimSort.java:485) > at java.util.TimSort.mergeCollapse(TimSort.java:408) > at java.util.TimSort.sort(TimSort.java:214) > at java.util.TimSort.sort(TimSort.java:173) > at java.util.Arrays.sort(Arrays.java:659) > at > org.apache.felix.webconsole.internal.misc.ThreadDumper.printThreadGroup(ThreadDumper.java:161) -- 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-3987) ResourceServlet sets content-length Header too late
[ https://issues.apache.org/jira/browse/FELIX-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kaspar von Gunten updated FELIX-3987: - Attachment: ResourceServlet.patch Suggested Patch > ResourceServlet sets content-length Header too late > --- > > Key: FELIX-3987 > URL: https://issues.apache.org/jira/browse/FELIX-3987 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.0 >Reporter: Kaspar von Gunten > Attachments: ResourceServlet.patch > > > The ResourceServlet.handle(..) implementation sets content-type and > last-modified headers, then goes on and copies the specified resource's > content onto the response's output stream. When it is done, it sets the > content-length header to the # of written bytes. > This is just wrong, because all headers should be present before content is > written. The implementation gets away with it, because most content probably > fits into the internal buffers and content-length is set before flush/close > is called, but with large content this will cause problems. > Suggestion: determine content-length in handle (analogous to last-modified) > BEFORE calling copy(). I atta -- 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] [Created] (FELIX-3987) ResourceServlet sets content-length Header too late
Kaspar von Gunten created FELIX-3987: Summary: ResourceServlet sets content-length Header too late Key: FELIX-3987 URL: https://issues.apache.org/jira/browse/FELIX-3987 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.0 Reporter: Kaspar von Gunten Attachments: ResourceServlet.patch The ResourceServlet.handle(..) implementation sets content-type and last-modified headers, then goes on and copies the specified resource's content onto the response's output stream. When it is done, it sets the content-length header to the # of written bytes. This is just wrong, because all headers should be present before content is written. The implementation gets away with it, because most content probably fits into the internal buffers and content-length is set before flush/close is called, but with large content this will cause problems. Suggestion: determine content-length in handle (analogous to last-modified) BEFORE calling copy(). I atta -- 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-3987) ResourceServlet sets content-length Header too late
[ https://issues.apache.org/jira/browse/FELIX-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kaspar von Gunten updated FELIX-3987: - Description: The ResourceServlet.handle(..) implementation sets content-type and last-modified headers, then goes on and copies the specified resource's content onto the response's output stream. When it is done, it sets the content-length header to the # of written bytes. This is just wrong, because all headers should be present before content is written. The implementation gets away with it, because most content probably fits into the internal buffers and content-length is set before flush/close is called, but with large content this will cause problems. Suggestion: determine content-length in handle (analogous to last-modified) BEFORE calling copy(). I attached a suggested patch for the v2.2.0 ResourceServlet. was: The ResourceServlet.handle(..) implementation sets content-type and last-modified headers, then goes on and copies the specified resource's content onto the response's output stream. When it is done, it sets the content-length header to the # of written bytes. This is just wrong, because all headers should be present before content is written. The implementation gets away with it, because most content probably fits into the internal buffers and content-length is set before flush/close is called, but with large content this will cause problems. Suggestion: determine content-length in handle (analogous to last-modified) BEFORE calling copy(). I atta > ResourceServlet sets content-length Header too late > --- > > Key: FELIX-3987 > URL: https://issues.apache.org/jira/browse/FELIX-3987 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.0 >Reporter: Kaspar von Gunten > Attachments: ResourceServlet.patch > > > The ResourceServlet.handle(..) implementation sets content-type and > last-modified headers, then goes on and copies the specified resource's > content onto the response's output stream. When it is done, it sets the > content-length header to the # of written bytes. > This is just wrong, because all headers should be present before content is > written. The implementation gets away with it, because most content probably > fits into the internal buffers and content-length is set before flush/close > is called, but with large content this will cause problems. > Suggestion: determine content-length in handle (analogous to last-modified) > BEFORE calling copy(). I attached a suggested patch for the v2.2.0 > ResourceServlet. -- 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-3987) ResourceServlet sets content-length header too late
[ https://issues.apache.org/jira/browse/FELIX-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kaspar von Gunten updated FELIX-3987: - Summary: ResourceServlet sets content-length header too late (was: ResourceServlet sets content-length Header too late) > ResourceServlet sets content-length header too late > --- > > Key: FELIX-3987 > URL: https://issues.apache.org/jira/browse/FELIX-3987 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Affects Versions: http-2.2.0 >Reporter: Kaspar von Gunten > Attachments: ResourceServlet.patch > > > The ResourceServlet.handle(..) implementation sets content-type and > last-modified headers, then goes on and copies the specified resource's > content onto the response's output stream. When it is done, it sets the > content-length header to the # of written bytes. > This is just wrong, because all headers should be present before content is > written. The implementation gets away with it, because most content probably > fits into the internal buffers and content-length is set before flush/close > is called, but with large content this will cause problems. > Suggestion: determine content-length in handle (analogous to last-modified) > BEFORE calling copy(). I attached a suggested patch for the v2.2.0 > ResourceServlet. -- 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
Please review patch for FELIX-3906
Hi, I've uploaded a trivial patch to FELIX-3906 - Configuration of Http Service context path broken after upgrade to Jetty 7 - a month ago. It's a trivial one-liner but since it fixes a regression I think it's important to apply it sooner rather than later. I'd appreciate if someone took the time to look at it. Thanks, Robert
[jira] [Created] (FELIX-3988) FilterHandler does not handle return of context.handleSecurity() correctly
Kaspar von Gunten created FELIX-3988:
Summary: FilterHandler does not handle return of
context.handleSecurity() correctly
Key: FELIX-3988
URL: https://issues.apache.org/jira/browse/FELIX-3988
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.2.0
Reporter: Kaspar von Gunten
This is somewhat similar to FELIX-2768, but not resolved.
The JavaDoc for HttpContext.handleSecurity states:
* When this method returns false, the Http Service will send the response back
to the client, thereby
* completing the request. When this method returns true, the Http Service will
proceed with servicing the
* request.
The current FilterHandler impl is as follows:
if (!getContext().handleSecurity(req, res)) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
} else {
this.filter.doFilter(req, res, chain);
}
1) This does not comply to the above doc, because the context might have set a
status/error code and prepared everything correctly to be returned. Sending an
error will overwrite the prepared headers and status.
2) Some context implementations are a bit eager and already send the response
back before they return "false" from the above method. The current
implementation will then lead to an IllegalStateException, because the response
has already been committed. In order to be more robust, there should be an
if(!response.isCommitted())-block around the handling of the "false" return
value.
I attached a patch for the second aspect of the issue, but couldn't resolve the
first part, because as it is at the moment, there is no way to check if there
is already a status set on the resource. I.e. something like:
if (!res.isCommitted() && !res.isStatusSet()) {
res.sendError(SC_FORBIDDEN);
}
is not possible.
--
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-3988) FilterHandler does not handle return of context.handleSecurity() correctly
[
https://issues.apache.org/jira/browse/FELIX-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kaspar von Gunten updated FELIX-3988:
-
Description:
This is somewhat similar to FELIX-2768, but not resolved.
The JavaDoc for HttpContext.handleSecurity states:
* When this method returns false, the Http Service will send the response back
to the client, thereby
* completing the request. When this method returns true, the Http Service will
proceed with servicing the
* request.
The current FilterHandler impl is as follows:
if (!getContext().handleSecurity(req, res)) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
} else {
this.filter.doFilter(req, res, chain);
}
1) This does not comply to the above doc, because the context might have set a
status/error code and prepared everything correctly to be returned. Sending an
error will overwrite the prepared headers and status.
2) Some context implementations are a bit eager and already send the response
back before they return "false" from the above method. The current
implementation will then lead to an IllegalStateException, because the response
has already been committed. In order to be more robust, there should be a
if(!res.isCommitted())-block around the handling of the "false" return value.
I attached a patch for the second aspect of the issue, but couldn't resolve the
first part, because - as it is at the moment - there seems to be no way to
check if there is already a status set on the resource (no getStatus() or
isStatusSet() method).
Ideally the fix should be something like:
if (!res.isCommitted() && !res.isStatusSet()) {
res.sendError(SC_FORBIDDEN);
}
was:
This is somewhat similar to FELIX-2768, but not resolved.
The JavaDoc for HttpContext.handleSecurity states:
* When this method returns false, the Http Service will send the response back
to the client, thereby
* completing the request. When this method returns true, the Http Service will
proceed with servicing the
* request.
The current FilterHandler impl is as follows:
if (!getContext().handleSecurity(req, res)) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
} else {
this.filter.doFilter(req, res, chain);
}
1) This does not comply to the above doc, because the context might have set a
status/error code and prepared everything correctly to be returned. Sending an
error will overwrite the prepared headers and status.
2) Some context implementations are a bit eager and already send the response
back before they return "false" from the above method. The current
implementation will then lead to an IllegalStateException, because the response
has already been committed. In order to be more robust, there should be an
if(!response.isCommitted())-block around the handling of the "false" return
value.
I attached a patch for the second aspect of the issue, but couldn't resolve the
first part, because as it is at the moment, there is no way to check if there
is already a status set on the resource. I.e. something like:
if (!res.isCommitted() && !res.isStatusSet()) {
res.sendError(SC_FORBIDDEN);
}
is not possible.
> FilterHandler does not handle return of context.handleSecurity() correctly
> --
>
> Key: FELIX-3988
> URL: https://issues.apache.org/jira/browse/FELIX-3988
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Kaspar von Gunten
>
> This is somewhat similar to FELIX-2768, but not resolved.
> The JavaDoc for HttpContext.handleSecurity states:
> * When this method returns false, the Http Service will send the response
> back to the client, thereby
> * completing the request. When this method returns true, the Http Service
> will proceed with servicing the
> * request.
> The current FilterHandler impl is as follows:
> if (!getContext().handleSecurity(req, res)) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> } else {
> this.filter.doFilter(req, res, chain);
> }
> 1) This does not comply to the above doc, because the context might have set
> a status/error code and prepared everything correctly to be returned. Sending
> an error will overwrite the prepared headers and status.
> 2) Some context implementations are a bit eager and already send the response
> back before they return "false" from the above method. The current
> implementation will then lead to an IllegalStateException, because the
> response has already been committed. In order to be more robust, there should
> be a if(!res.isCommitted())-block around the handling of the "false" return
> value.
> I attached a patch for the second aspect of the issue, but couldn't resolve
> the first part, because - as it is at the moment - there seems to be no way
> to check if there is already a
[jira] [Updated] (FELIX-3988) FilterHandler does not handle return of context.handleSecurity() correctly
[
https://issues.apache.org/jira/browse/FELIX-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kaspar von Gunten updated FELIX-3988:
-
Attachment: FilterHandler.patch
Suggested patch to make handling of false return value by
context.handleSecurity() more robust.
This patch is only a partial solution to the issue, see description.
> FilterHandler does not handle return of context.handleSecurity() correctly
> --
>
> Key: FELIX-3988
> URL: https://issues.apache.org/jira/browse/FELIX-3988
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Kaspar von Gunten
> Attachments: FilterHandler.patch
>
>
> This is somewhat similar to FELIX-2768, but not resolved.
> The JavaDoc for HttpContext.handleSecurity states:
> * When this method returns false, the Http Service will send the response
> back to the client, thereby
> * completing the request. When this method returns true, the Http Service
> will proceed with servicing the
> * request.
> The current FilterHandler impl is as follows:
> if (!getContext().handleSecurity(req, res)) {
> res.sendError(HttpServletResponse.SC_FORBIDDEN);
> } else {
> this.filter.doFilter(req, res, chain);
> }
> 1) This does not comply to the above doc, because the context might have set
> a status/error code and prepared everything correctly to be returned. Sending
> an error will overwrite the prepared headers and status.
> 2) Some context implementations are a bit eager and already send the response
> back before they return "false" from the above method. The current
> implementation will then lead to an IllegalStateException, because the
> response has already been committed. In order to be more robust, there should
> be a if(!res.isCommitted())-block around the handling of the "false" return
> value.
> I attached a patch for the second aspect of the issue, but couldn't resolve
> the first part, because - as it is at the moment - there seems to be no way
> to check if there is already a status set on the resource (no getStatus() or
> isStatusSet() method).
> Ideally the fix should be something like:
> if (!res.isCommitted() && !res.isStatusSet()) {
> res.sendError(SC_FORBIDDEN);
> }
--
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-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tuomas Kiviaho updated FELIX-3973:
--
Attachment: (was: FELIX-3973.diff)
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
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] [Commented] (FELIX-3973) Exclusion from {local-packages} doesn't work anymore
[
https://issues.apache.org/jira/browse/FELIX-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609081#comment-13609081
]
Tuomas Kiviaho commented on FELIX-3973:
---
I removed the patch after Peter pointer out that I was doing-it-wrong. Proper
way of doing it would be to use macros but alas they don't seem to be working
with {local-packages}. I noticed also that split packages clause is only
applied to the last of the local package. I'll deliver a new patch soon.
> Exclusion from {local-packages} doesn't work anymore
>
>
> Key: FELIX-3973
> URL: https://issues.apache.org/jira/browse/FELIX-3973
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
> Environment: bnd 2.0.0.x
>Reporter: Tuomas Kiviaho
>
> I've been using Export-Package: !org.apache.jsp.*, {local-packages} to
> exclude jspc compilers output, but with BND 2.0.0 this stopped working
> completely (although until now I was getting a bunch of warnings).
> BND currently gives a second chance to non matching packages. This feature
> will rended !org.apache.jsp.* useless since {local-packages} is expanded to
> clause that contains org.apache.jsp prefixed packages.
> A fix would be to pre-filter the {local-packages} against
> Export/Private-Package clauses
--
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
Determining code coverage with Pax Exam
Hi, This query is not related to Felix but I just wanted to check if any of the projects have used any Code Coverage tool with Pax Exam. I am adding integration test for the JAAS module and was looking for a way to measure code coverage. So any pointers around that would be helpful. Chetan Mehrotra
[jira] [Work started] (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 ] Work on FELIX-3981 started by Chetan Mehrotra. > 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 > > 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 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] [Created] (FELIX-3989) Add support for determining code coverage with integration testcases
Chetan Mehrotra created FELIX-3989: -- Summary: Add support for determining code coverage with integration testcases Key: FELIX-3989 URL: https://issues.apache.org/jira/browse/FELIX-3989 Project: Felix Issue Type: Task Components: JAAS Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor It would be good to have a report generated for determining the code coverage of the integration test run by Pax Exam -- 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
