Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Mon, 11 Nov 2013 12:27:21 +0000 (UTC)
From: "Wolfgang Glas (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12673537.1381565312814.51227.1384172841237@arcas>
In-Reply-To: <JIRA.12673537.1381565312814@arcas>
References: <JIRA.12673537.1381565312814@arcas>
Subject: [jira] [Commented] (FELIX-4282) HTTP Bundle 2.2.1 has and incorrect
 embedded Jetty instance
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818914#comment-13818914 ] 

Wolfgang Glas commented on FELIX-4282:
--------------------------------------

Hello J.W. Hansen,

Thanks for fixing this one ;-)

Can you please provide us with a fix version and  a tentative date, when a fix will appear on the download page?

  TIA, Wolfgnag

> 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
>            Assignee: J.W. Janssen
>
> 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)