[
https://issues.apache.org/jira/browse/FELIX-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818140#comment-13818140
]
Wolfgang Glas commented on FELIX-4282:
--------------------------------------
Hello J.W. Nansen,
What you are describing is the correct behaviour of our login service, thanks
for trying to reproduce out problem ;-)
In our setup, the example fails at the very first HTTP request with
jetty-7.6.12.v20130726 and succeeds with jetty-7.6.13.v20130916
We are BTW currently using a patched version felix.http.jetty, which is
created by upgrading the jetty dependency to jetty-7.6.13.v20130916:
http://maven.clazzes.org/org/apache/felix/org.apache.felix.http.jetty/2.2.1-clazzes1/org.apache.felix.http.jetty-2.2.1-clazzes1.jar
Honestly, I have no clue why our example fails in our installation - which is
quite similar to yours - and why you are succeeding :-/
The conclusion is, that felix.http with jetty-7.6.13.v20130916 under the hood
seems to be more robust to subtle differences in the OSGi environment and we
have two options:
a) release felix.http-2.2.2 with jetty-7.6.13.v20130916
b) find a strategy to find out even more about the issue.
Best regards,
Wolfgang
> HTTP Bundle 2.2.1 has and incorrect embedded Jetty instance
> -----------------------------------------------------------
>
> Key: FELIX-4282
> URL: https://issues.apache.org/jira/browse/FELIX-4282
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
> Reporter: Bruce Jackson
>
> I've recently downloaded the latest version of the http bundle 2.2.1 which
> contains the update to Jetty 7. This seems to have a problem, perhaps
> because the Jetty version is a snapshot.
> java.lang.NoSuchMethodError:
> org.eclipse.jetty.util.QuotedStringTokenizer.unquoteOnly(Ljava/lang/String;
> )Ljava/lang/String;
> at
> org.eclipse.jetty.server.CookieCutter.parseFields(CookieCutter.java:284)
> at
> org.eclipse.jetty.server.CookieCutter.getCookies(CookieCutter.java:64)
> at org.eclipse.jetty.server.Request.getCookies(Request.java:499)
> at
> org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(Ses
> sionHandler.java:260)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java
> :155)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java
> :978)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:13
> 5)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHan
> dlerCollection.java:255)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:
> 116)
> at org.eclipse.jetty.server.Server.handle(Server.java:369)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC
> onnection.java:486)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp
> Connection.java:933)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComple
> te(AbstractHttpConnection.java:995)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.jav
> a:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint
> .java:606)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.
> java:46)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java
> :603)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:
> 538)
> at java.lang.Thread.run(Thread.java:724)
> If I build the bundle manually with the 7.4.16 Jetty-all, I don't see this
> problem.
> I'm using the released HTTP Bundle from the felix download site. If I
> manually remove the classes from the exploded jar and replace them with
> the contents of the latest release Jetty all build (which is
> jetty-all-server-7.6.13.v20130916) then I no longer see this problem.
> I suspect that the reason that we see this is that we are using Jetty 7
> continuations (looking at the stack trace, this seems to be an async
> operation) and so if you're not using them, you may never have encountered
> this problem.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
