[jira] Created: (FELIX-2830) Tablesorter loses it's styling if placed in JQuery TAB component
Tablesorter loses it's styling if placed in JQuery TAB component Key: FELIX-2830 URL: https://issues.apache.org/jira/browse/FELIX-2830 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor If a sorted table is placed in a tab, then when you click on the table headings to sort the column, the styling is gone and the down/up arrow, showing the sort order is hidden. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2830) Tablesorter loses it's styling if placed in JQuery TAB component
[ https://issues.apache.org/jira/browse/FELIX-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-2830: Attachment: screen002.png the attached image illustrates the problem Tablesorter loses it's styling if placed in JQuery TAB component Key: FELIX-2830 URL: https://issues.apache.org/jira/browse/FELIX-2830 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor Attachments: screen002.png Original Estimate: 1h Remaining Estimate: 1h If a sorted table is placed in a tab, then when you click on the table headings to sort the column, the styling is gone and the down/up arrow, showing the sort order is hidden. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work logged: (FELIX-2830) Tablesorter loses it's styling if placed in JQuery TAB component
[
https://issues.apache.org/jira/browse/FELIX-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel\#worklog-{worklog.getId()}
]
Valentin Valchev logged work on FELIX-2830:
---
Author: Valentin Valchev
Created on: 08/Feb/11 9:06 AM
Start Date: 08/Feb/11 9:06 AM
Worklog Time Spent: 1h
Issue Time Tracking
---
Worklog Id: (was: 11255)
Time Spent: 1h
Remaining Estimate: 0h (was: 1h)
Tablesorter loses it's styling if placed in JQuery TAB component
Key: FELIX-2830
URL: https://issues.apache.org/jira/browse/FELIX-2830
Project: Felix
Issue Type: Bug
Components: Web Console
Affects Versions: webconsole-3.1.6
Reporter: Valentin Valchev
Assignee: Valentin Valchev
Priority: Minor
Fix For: webconsole-3.1.8
Attachments: screen002.png
Original Estimate: 1h
Time Spent: 1h
Remaining Estimate: 0h
If a sorted table is placed in a tab, then when you click on the table
headings to sort the column, the styling is gone and the down/up arrow,
showing the sort order is hidden.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-2830) Tablesorter loses it's styling if placed in JQuery TAB component
[ https://issues.apache.org/jira/browse/FELIX-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-2830. - Resolution: Fixed Fix Version/s: webconsole-3.1.8 Fixed in rev.1068296 Tablesorter loses it's styling if placed in JQuery TAB component Key: FELIX-2830 URL: https://issues.apache.org/jira/browse/FELIX-2830 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor Fix For: webconsole-3.1.8 Attachments: screen002.png Original Estimate: 1h Remaining Estimate: 1h If a sorted table is placed in a tab, then when you click on the table headings to sort the column, the styling is gone and the down/up arrow, showing the sort order is hidden. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-2830) Tablesorter loses it's styling if placed in JQuery TAB component
[ https://issues.apache.org/jira/browse/FELIX-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-2830: Fix Version/s: (was: webconsole-3.1.8) webconsole-3.1.10 Tablesorter loses it's styling if placed in JQuery TAB component Key: FELIX-2830 URL: https://issues.apache.org/jira/browse/FELIX-2830 Project: Felix Issue Type: Bug Components: Web Console Affects Versions: webconsole-3.1.6 Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Minor Fix For: webconsole-3.1.10 Attachments: screen002.png Original Estimate: 1h Time Spent: 1h Remaining Estimate: 0h If a sorted table is placed in a tab, then when you click on the table headings to sort the column, the styling is gone and the down/up arrow, showing the sort order is hidden. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services
[
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991858#comment-12991858
]
Timothy Ward commented on FELIX-2546:
-
Hi Guillaume,
Obviously I'd like this fixed, but I'm happy for it to go into a 1.7 release
rather than a 1.6.5 release of bundlerepository. There are a few other problems
I'm looking at providing fixes for, and I'm happy to work by locally patching
my bundles in the short term.
Tim
Only one service is provisioned even when specifying for mulitple services
--
Key: FELIX-2546
URL: https://issues.apache.org/jira/browse/FELIX-2546
Project: Felix
Issue Type: Bug
Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
Environment: n/a
Reporter: Emily Jiang
Attachments: Felix OBR isMultiple support - timothyjward.txt
Felix OBR is unable to return multiple services when specifying 'multiple'
attribute with the value of 'true'. The test scenario is detailed below.
I am trying to get all bundles registering the service of
com.sample.HelloWorld and install them into the osgi framework . In my test
environment, there are two bundles with different symbolic name offering the
same service, com.sample.HelloWorld. However, only one bundle was pulled into
runtime. The snippet of my repository is shown below.
require extend=false
filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
multiple=true name=service optional=falseRequires service with
attributes {service=service, objectClass=com.sample.HelloWorld}/require
Regards
Emily
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2394) Servlets that are automatically unregistered should not be destroyed
[ https://issues.apache.org/jira/browse/FELIX-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2394. Close issues after release Servlets that are automatically unregistered should not be destroyed Key: FELIX-2394 URL: https://issues.apache.org/jira/browse/FELIX-2394 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Alan Cabrera Assignee: Felix Meschberger Fix For: http-2.2.0 Servlets that are automatically unregistered, when their registering bundles are uninstalled, should not be destroyed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2769) Provide Metatype Descriptor for Jetty Configuration properties
[ https://issues.apache.org/jira/browse/FELIX-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2769. Close issues after release Provide Metatype Descriptor for Jetty Configuration properties -- Key: FELIX-2769 URL: https://issues.apache.org/jira/browse/FELIX-2769 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.0 To support configuration of the Jetty embedded servlet container e.g. with the Web Console, a metatype descirptor would be useful describing the properties, their types and default values. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2801) Http exports should not use the bundle version
[
https://issues.apache.org/jira/browse/FELIX-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-2801.
Close issues after release
Http exports should not use the bundle version
--
Key: FELIX-2801
URL: https://issues.apache.org/jira/browse/FELIX-2801
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
Fix For: http-2.2.0
The http.api bundle exports the API as version ${pom.version}, thus the
version of the exported package follows the bundle version, which is
completely wrong. Rather the package should be exported with its own version
-- starting with 2.0.4 for backwards compatibility with the 2.0.4 release of
the API bundle.
Same for the exportet http roxy package.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-1962) Add support for (select) Servlet API listeners
[ https://issues.apache.org/jira/browse/FELIX-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1962. Close issues after release Add support for (select) Servlet API listeners -- Key: FELIX-1962 URL: https://issues.apache.org/jira/browse/FELIX-1962 Project: Felix Issue Type: New Feature Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.0 Attachments: FELIX-1962-2.patch, FELIX-1962.patch The new Http Service implementation currently does not support any Servlet API listeners at all. Support for some listeners can easily be implemented in a transparent way: ServletContextAttributeListener, ServletRequestListener, ServletRequestAttributeListener. The HttpSession listeners can probably not easily be implemented in such a transparent way. The ServletContextListener is probably not worth it supporting. Most (if not all) use cases for ServletContextListeners in traditional web applications can be solved in better ways in an OSGi framework. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-1999) The classes in the http.base bundle do not properly handle ServletRequest.getPathInfo() == null
[ https://issues.apache.org/jira/browse/FELIX-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1999. Close issues after release The classes in the http.base bundle do not properly handle ServletRequest.getPathInfo() == null --- Key: FELIX-1999 URL: https://issues.apache.org/jira/browse/FELIX-1999 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.0 ServletRequest.getPathInfo() is allowed to return null (if there is no additional path information). For example, IBM WebSphere returns null if the client accesses the Servlet context without a trailing slash (Jetty in this case redirects to the context path with a trailing slash and thus this case does not happen). To prevent NullPointerExceptions from happening the FilterHandler.match and ServletHandler.match methods must guard against the uri parameter being null -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2768) HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
[
https://issues.apache.org/jira/browse/FELIX-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-2768.
Close issues after release
HttpContext.handleSecurity returns SC_FORBIDDEN unless response is comitted
---
Key: FELIX-2768
URL: https://issues.apache.org/jira/browse/FELIX-2768
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.0.4
Reporter: Derek Baum
Assignee: Felix Meschberger
Fix For: http-2.2.0
The JavaDoc for HttpContext.handleSecurity states:
* If the request requires authentication and the Authorization header
in
* the request is missing or not acceptable, then this method should
set the
* WWW-Authenticate header in the response object, set the status in the
* response object to Unauthorized(401) and return codefalse/code
So the following implementation of handleSecurity() should cause an
UNAUTHORIZED response:
response.setHeader(WWW-Authenticate, BASIC realm=\Secure
Moixa Energy Gateway\);
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
return false;
This worked OK in org.apache.felix.http.jetty-1.0.1, but fails in
org.apache.felix.http.jetty-2.0.4, by always returning SC_FORBIDDEN.
Examining the implementation:
org/apache/felix/http/base/internal/handler/ServletHandler.java:
if (!getContext().handleSecurity(req, res)) {
if (!res.isCommitted()) {
res.sendError(HttpServletResponse.SC_FORBIDDEN);
}
}
which means that SC_FORBIDDEN is always returned, unless the response is
committed.
In order to commit the response, response.flushBuffer() must be called in the
handleSecurity() implementation after setting the response code to
unauthorized. Howver, the JavaDoc for HttpContext does not indicate that it
is necessary to commit the response.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2788) ServletContextImpl does not propagate context attribute changes to parent context
[ https://issues.apache.org/jira/browse/FELIX-2788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2788. Close issues after release ServletContextImpl does not propagate context attribute changes to parent context - Key: FELIX-2788 URL: https://issues.apache.org/jira/browse/FELIX-2788 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Tobias Bocanegra Assignee: Felix Meschberger Fix For: http-2.2.0 org.apache.felix.http.base.internal.context.ServletContextImpl does not propagate context attribute changes to parent context. this is a problem for example when a session event is triggered. then the evt.getSession().getServletContext() is the one of the servlet container and not the felix one, thus the context attributes added prior to the servlet context are not visible. so either wrap the httpsession in the events with a java proxy for a complete isolation, or delegate all attribute modifications to the parent context. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-1978) Make ConfigAdmin packages optional
[ https://issues.apache.org/jira/browse/FELIX-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1978. Close issues after release Make ConfigAdmin packages optional -- Key: FELIX-1978 URL: https://issues.apache.org/jira/browse/FELIX-1978 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.0.2, http-2.0.4 Reporter: Sten Roger Sandvik Assignee: Felix Meschberger Fix For: http-2.2.0 Attachments: FELIX-1978.patch ConfigAdmin packages is now required in org.apache.felix.http.jetty. To make this optional we need to change JettyService to be able to detect if ManagedService classes is present. Log message if available/not-available. Also the ConfigAdmin packages should have optional flag set under Import-Package statement. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2605) FilterHandler should pre-compile regular expression
[ https://issues.apache.org/jira/browse/FELIX-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2605. Close issues after release FilterHandler should pre-compile regular expression --- Key: FELIX-2605 URL: https://issues.apache.org/jira/browse/FELIX-2605 Project: Felix Issue Type: Improvement Components: HTTP Service Affects Versions: http-2.0.4 Reporter: David Hay Assignee: Carsten Ziegeler Fix For: http-2.2.0 Attachments: FilterHandler.java-regexp.patch The implementation of FilterHandler has a potential performance problem. Each time the handle method is called, it goes through a matching process that includes the following code: return uri.matches(this.pattern) The problem is that this compiles the regular expression every time this method is called, a potentially expensive operation. The pattern should be compiled using Pattern.compile and then re-used for each call to matches as follows: return this.regex.matcher(uri).matches(); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2387) registerServlet() throws NPE
[ https://issues.apache.org/jira/browse/FELIX-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2387. Close issues after release registerServlet() throws NPE Key: FELIX-2387 URL: https://issues.apache.org/jira/browse/FELIX-2387 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Alan Cabrera Assignee: Carsten Ziegeler Fix For: http-2.2.0 registerServlet() throws NPE when passed a null for servlet. It should throw an IllegalArgumentException. java.lang.NullPointerException at org.apache.felix.http.base.internal.handler.ServletHandler.init(ServletHandler.java:55) at org.apache.felix.http.base.internal.handler.HandlerRegistry.addServlet(HandlerRegistry.java:65) at org.apache.felix.http.base.internal.service.HttpServiceImpl.registerServlet(HttpServiceImpl.java:97) at org.papoose.tck.http.BaseHttpServiceImplTest.testRegisterNullServlet(BaseHttpServiceImplTest.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:143) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:105) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:637) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-1979) ServletHandlerRequest.getPathInfo() returns undecoded string
[ https://issues.apache.org/jira/browse/FELIX-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-1979. Close issues after release ServletHandlerRequest.getPathInfo() returns undecoded string Key: FELIX-1979 URL: https://issues.apache.org/jira/browse/FELIX-1979 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.0 Attachments: FELIX-1979-2.patch, FELIX-1979.patch The Servlet API specifies the HttpServletRequest.getPathInfo() to return a decoded path string. The current implementation just cuts off the servlet context and servlet alias from the request URL (retrieved from HttpServletRequest.getRequestURI()), which is not decoded. Therefore the resulting path info is also not decoded and needs decoding. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2000) Pathinfo for servlets/filters with relative path not correctly determined
[ https://issues.apache.org/jira/browse/FELIX-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2000. Close issues after release Pathinfo for servlets/filters with relative path not correctly determined -- Key: FELIX-2000 URL: https://issues.apache.org/jira/browse/FELIX-2000 Project: Felix Issue Type: Bug Components: HTTP Service Environment: Apache Tomcat 5.5; Apache Felix 2.0.4. Reporter: J.W. Janssen Assignee: Felix Meschberger Fix For: http-2.2.0 We're currently running an Felix HTTP-filter inside a Tomcat WAR. This WAR has the HTTP Proxy from Felix registered on a relative path (for example '/osgi'). When trying to use the Felix webconsole, one would suspect to have to use an URI like '/osgi/system/console'. However, this is not working. After some debugging, I came to the conclusion that the problem is caused by the implementation of ServletHandlerRequest#calculatePathInfo() (in the http-base bundle). This method does not take the relative paths of a servlet/filter into account to determine the path-info. Instead, it assumes the servlet/filter has no relative path at all. Due to this, the webconsole retrieves an incorrect URL and refuses to display as the webconsole uses the path-info for determining which page (bundles, configuration, ...) it has to display. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2806) Fix NOTICE files to comply with ASF standards
[ https://issues.apache.org/jira/browse/FELIX-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2806. Close issues after release Fix NOTICE files to comply with ASF standards - Key: FELIX-2806 URL: https://issues.apache.org/jira/browse/FELIX-2806 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: http-2.2.0 The NOTICE files of the Http Service implementation are still formatted according to the old invalid policy. These files must be adapted to the ASF rules and DEPENDENCIES files be added to capture to the old contents of the NOTICE files. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2398) Config property to disable NIO use in http.bundle doesn't work
[ https://issues.apache.org/jira/browse/FELIX-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed FELIX-2398. Close issues after release Config property to disable NIO use in http.bundle doesn't work -- Key: FELIX-2398 URL: https://issues.apache.org/jira/browse/FELIX-2398 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.0.4 Environment: All Reporter: Bruce Jackson Assignee: Felix Meschberger Fix For: http-2.2.0 In Felix-870 (https://issues.apache.org/jira/browse/FELIX-870) a property was added to disable the use of NIO by the jetty embedded http server. This config property no longer works. From Rob Walker: Just grepping the source code, and I think this property was in the original felix/http.jetty bundle but may not have made it across to the new felix/http bundle. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-2691) Apache Felix HTTP service HttpServiceImpl.isNameValid does not match OSGi R4.2 spec?
[
https://issues.apache.org/jira/browse/FELIX-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-2691.
Close issues after release
Apache Felix HTTP service HttpServiceImpl.isNameValid does not match OSGi
R4.2 spec?
Key: FELIX-2691
URL: https://issues.apache.org/jira/browse/FELIX-2691
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.0.4
Environment: Not relevant
Reporter: Misha Koshelev
Assignee: Felix Meschberger
Fix For: http-2.2.0
Attachments:
FELIX-2691-HttpServiceImpl-isNameValid-comply-OSGI-R42.patch
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Filing bug per:
http://www.mail-archive.com/dev@felix.apache.org/msg19853.html
The R4.2 enterprise spec from
http://www.osgi.org/Download/File?url=/download/r4v42/r4.enterprise.pdf
on page 48 clearly states:
The name parameter must also not end with slash ('/') with the
exception that a name of the form / is used to denote the root of
the bundle.
The relevant code, in trunk, is, from
http://svn.apache.org/repos/asf/felix/trunk/http/base/src/main/java/org/apache/felix/http/base/internal/service/HttpServiceImpl.java
public void registerResources(String alias, String name, HttpContext context)
throws NamespaceException
{
if (!isNameValid(name)) {
throw new IllegalArgumentException( Malformed resource
name [ + name + ]);
}
...
and
private boolean isNameValid(String name)
{
if (name == null) {
return false;
}
if (name.endsWith( / )) {
return false;
}
return true;
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FELIX-2831) Bundle-RequiredExecutionEnvironment will not match for obr
Bundle-RequiredExecutionEnvironment will not match for obr -- Key: FELIX-2831 URL: https://issues.apache.org/jira/browse/FELIX-2831 Project: Felix Issue Type: Bug Components: Bundle Repository (OBR) Environment: Java SE 1.6 Reporter: Don Corley The obr will not deploy a resource with the correct execution environment. If my manifest has the entry: Bundle-RequiredExecutionEnvironment: J2SE-1.5, JavaSE-1.6 and I try to deploy, I get this error: deploy joda-time Unsatisfied requirement(s): --- (|(ee=J2SE-1.5)(ee=JavaSE-1.6)) Joda-Time If I change the mainfest to JavaSE-1.6* it works fine.. but then the framework doesn't see it. I searched through your source code, but I can't find the place where you get the ee. Obviously, you are getting the full version, such as JavaSE-1.6.2 and you are not removing the .2, to match the expected values in http://www.osgi.org/Specifications/Reference#ees Thanks for looking at this. Don -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Re-trying releases
New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle. Kind regards, Peter Kriens On 4 feb 2011, at 09:39, Carsten Ziegeler wrote: Guillaume Nodet wrote On Fri, Feb 4, 2011 at 02:52, Richard S. Hall he...@ungoverned.org wrote: If enough people respond maybe we can reach some sort of consensus...or else we could call a vote on it. Can other felix members speak here ? I guess we don't find consensus by just discussing :) Some of us prefer it this way, others the other way. I prefer increasing the version number for each retry, it requires no additional work (except changing the version in jira) and makes it easier to track if people are using failed releases. Sure, comparing the hash of the binary artifact would solve this as well, but just looking at the version number is soo easy :) If - as a project - we agree to use the same version number for retries I'm ok with as well. But I agree we should do this consistently and just write it down somewhere. So let's call a vote and the majority wins :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Re-trying releases
On 2/8/11 12:29, Peter Kriens wrote: New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle. I think everyone agrees that a new version number should always be used for every release. The issue here is about a release that was never released because it was canceled for some reason during the voting period. - richard Kind regards, Peter Kriens On 4 feb 2011, at 09:39, Carsten Ziegeler wrote: Guillaume Nodet wrote On Fri, Feb 4, 2011 at 02:52, Richard S. Hallhe...@ungoverned.org wrote: If enough people respond maybe we can reach some sort of consensus...or else we could call a vote on it. Can other felix members speak here ? I guess we don't find consensus by just discussing :) Some of us prefer it this way, others the other way. I prefer increasing the version number for each retry, it requires no additional work (except changing the version in jira) and makes it easier to track if people are using failed releases. Sure, comparing the hash of the binary artifact would solve this as well, but just looking at the version number is soo easy :) If - as a project - we agree to use the same version number for retries I'm ok with as well. But I agree we should do this consistently and just write it down somewhere. So let's call a vote and the majority wins :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [DISCUSS] Re-trying releases
On 2/8/11 13:04, Richard S. Hall wrote: On 2/8/11 12:29, Peter Kriens wrote: New version number for any reason makes a lot of sense. A bsn + version must be as unique as a SHA-1 hashcode of the bundle. I think everyone agrees that a new version number should always be used for every release. The issue here is about a release that was never released because it was canceled for some reason during the voting period. After re-reading your message, I read reason as release... However, the tricky part is as I described...at Apache there is no release without a proper vote, so the question is, do we need the version number to reflect these failed attempts? Give the ongoing vote on this, it doesn't look like we have any clear consensus. As a result, I'm happy to let the person doing the release decide... - richard - richard Kind regards, Peter Kriens On 4 feb 2011, at 09:39, Carsten Ziegeler wrote: Guillaume Nodet wrote On Fri, Feb 4, 2011 at 02:52, Richard S. Hallhe...@ungoverned.org wrote: If enough people respond maybe we can reach some sort of consensus...or else we could call a vote on it. Can other felix members speak here ? I guess we don't find consensus by just discussing :) Some of us prefer it this way, others the other way. I prefer increasing the version number for each retry, it requires no additional work (except changing the version in jira) and makes it easier to track if people are using failed releases. Sure, comparing the hash of the binary artifact would solve this as well, but just looking at the version number is soo easy :) If - as a project - we agree to use the same version number for retries I'm ok with as well. But I agree we should do this consistently and just write it down somewhere. So let's call a vote and the majority wins :) Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (FELIX-2832) [Framework] It should not be possible to open an URLConnection to / for a bundle URL
[Framework] It should not be possible to open an URLConnection to / for a bundle URL -- Key: FELIX-2832 URL: https://issues.apache.org/jira/browse/FELIX-2832 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.0.8 Reporter: Richard S. Hall Assignee: Richard S. Hall Priority: Minor Fix For: framework-3.2.0 The call Bundle.getResource(/) returns a valid URL, but the only purpose of this URL is to be used as context for building URLs to other entries in the bundle. The / URL doesn't actually exist, so any attempt to open it should fail. Unfortunately, this isn't always the case. For a little background, bundle resource URLs can have multiple roots for each entry on the bundle class path, so just construction a bundle resource URL from another one may not give you what you want since it may not be using the correct index into the bundle class path (since bundle resource URLs are opaque, the user can't be expected to understand this). So, we try to be nice in the URLHandlersBundleURLConnection constructor and detect this case and automatically fix the class path index. When this nice hack is combined with someone opening the / resource URL, we can run into an issue. Since / never exists, the nice hack in URLHandlersBundleURLConnection kicks in and searches for it in other bundle class path entries. If one of these bundle class path entries is an embedded directory, then the / effectively gets converted to the embedded directory entry, since ContentDirectoryContent prepends the embedded directory when searching. Since the embedded directory does exist, it then becomes possible to create an input stream to it, which to the user will appear as if is created an input stream to /. This is not correct for a variety of reasons. To avoid this, we should modify the URLHandlersBundleURLConnection constructor to explicitly check for the / URL and always throw an exception in this case immediately, to ensure that no one can ever open a connection to it. This also avoids the possibility that we will try find it another way with our nice hack. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
