migrated from Bugzilla #414860
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 7.6.12 on platform All
Assigned to: Project Inbox

On 2013-08-12 07:31:43 -0400, Vladimir Tsukur wrote:

Consider the case when client is asking for resource which does not exist. Jetty responds with standard text/html HTTP ERROR 404 page. The problem is that Jetty ignores "Accept" header sent by the client always responding in HTML.

Let's assume HTTP client is sending the request with specific MIME type like application/json. Returning text/html actually breaks the client since it is not what he asked for.

According to the HTTP 1.1 RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html):
If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.

Would it make sense to comply to the rules of content negotiation and return response in compatible content type? Or 4xx/5xx responses should be treated as response which may not confirm to the rules imposed by Accept header?

On 2013-08-12 07:46:03 -0400, Vladimir Tsukur wrote:

Let me elaborate a little bit more on this: returning response in client-compatible MIME type would at least ensure that client may parse the request. Response itself may be HTML if client requests content in /, text/* or text/html and may be empty in all cases (like application/json).

migrated from Bugzilla #407045
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 9.0.2 on platform PC
Assigned to: Jan Bartel

On 2013-05-02 03:22:03 -0400, Oliver Z wrote:

JDBCSessionIdManager.java:1040 and JDBCSessionIdManager:1042

            Statement statement = con.createStatement();
            //take them out of the sessionIds table
            statement.executeUpdate(fillInClause("delete from "+_sessionIdTable+" where id in ", ids, start, end));
            //take them out of the sessions table
            statement.executeUpdate(fillInClause("delete from "+_sessionTable+" where sessionId in ", ids, start, end));
            block++;

This should be a preparet statement.

On 2013-05-02 03:42:38 -0400, Jan Bartel wrote:

Oliver,

I've edited the title of this bug, as it makes it sound as if jetty is using input that comes from a user on a browser to determine which sessions should be deleted, which might mislead some people.

Jan

On 2013-05-02 04:10:58 -0400, Jan Bartel wrote:

Recategorizing as enhancement.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=404068

On 2013-05-02 20:36:55 -0400, Jan Bartel wrote:

Just an observation, but it appears from googling this that it is going to be difficult to find a solution that uses PreparedStatements with an sql IN clause, particularly as the number of args to the IN clause can vary.

eg, see http://www.javaranch.com/journal/200510/Journal200510.jsp#a2

migrated from Bugzilla #409516
status ASSIGNED severity normal in component websocket for 9.3.x
Reported in version 9.0.3 on platform All
Assigned to: Joakim Erdfelt

Original attachment names and IDs:

• 0001-Add-proxy-support-to-websocket-client.patch (ID 233681)

On 2013-05-30 12:21:45 -0400, Joakim Erdfelt wrote:

Need to add support to configure a proxy for WebSocketClient.

On 2013-06-26 09:40:32 -0400, Missing name wrote:

Any plans when it will be implemented?

On 2013-07-22 16:10:29 -0400, Gustavo Giráldez wrote:

Created attachment 233681
Proposed patch for websocket proxy support

Here's a proposed patch to add proxy support to WebSocket client. It'll only work properly with HTTP/1.1 proxy servers and currently supports basic and digest authentication.

The ProxyConnection class is based heavily on UpgradeConnection (et al) and DigestAuthentication was taken and adapted from jetty-client.

From what I've read in Eclipse site pages a patch is the preferred way of sending a contribution but we can make a pull request from https://github.com/manastech/jetty.project/tree/websocket-proxy if that's convenient. Also, we need this functionality and would like for it to be included in a future version of Jetty. Please let me know what changes are required to make this happen. Thanks!

On 2013-07-22 16:20:45 -0400, Jesse McConnell wrote:

First stop is here:

http://www.eclipse.org/jetty/documentation/current/contributing-patches.html#contributing-cla

thanks for the patch!

On 2013-09-23 16:50:18 -0400, Jesse McConnell wrote:

Gustavo, can you complete the CLA paperwork so we can consider your patch?

On 2013-09-24 10:56:01 -0400, Gustavo Giráldez wrote:

I'm confused about what are the next steps. I already signed the CLA. Is there anything else I should do? Thanks!

On 2013-09-24 10:56:44 -0400, Jesse McConnell wrote:

hm...I'll ping wayne about it, there should be a little check mark by your name now :)

On 2013-09-24 11:38:35 -0400, Wayne Beaton wrote:

(In reply to Jesse McConnell from comment # 6)

hm...I'll ping wayne about it, there should be a little check mark by your
name now :)

The CLA system is based on the email address.

The database shows that Gustavo has a CQ, but under a gmail address.

On 2013-09-24 12:11:11 -0400, Gustavo Giráldez wrote:

Hmm, I remember creating my account with my personal email address ([email protected]) but then I changed it to my work email [email protected]. I signed the CLA after this change IIRC. Is there anything I can do?

On 2013-09-25 07:26:45 -0400, Wayne Beaton wrote:

(In reply to Gustavo Giráldez from comment # 8)

Hmm, I remember creating my account with my personal email address
([email protected]) but then I changed it to my work email
[email protected]. I signed the CLA after this change IIRC. Is there
anything I can do?

According to my records, you signed the CLA using your gmail account.

Did you create a second account, or change the email address on the first account?

On 2013-09-25 09:33:51 -0400, Gustavo Giráldez wrote:

No, I only have one account. I just invalidated my CLA and signed a new one. I can now see the tick next to my name, as well as next to Joakim's and Jesse's, which for some reason I didn't get before. So, it looks like it's fixed now :)

On 2013-11-28 10:00:13 -0500, Axel Uhl wrote:

The patch proposed by Gustavo looks good. Now that the IP / CLA issues have been solved, what is keeping the patch from getting merged? Do you already have a target release in mind?

On 2013-11-28 10:04:00 -0500, Joakim Erdfelt wrote:

We'll see about merging this patch back into master (aka Jetty 9.1.0) after the holiday.

On 2014-03-07 07:19:15 -0500, Vlad Lucian Ginju wrote:

Any news on adding the proxy support for websocket client?

On 2014-05-08 23:18:39 -0400, Arthur Naseef wrote:

Any update?

On 2015-02-12 00:36:32 -0500, Thrilochana Rajappa wrote:

Does the latest jetty libraries(9.1.1) support proxy server?

On 2015-02-12 11:56:58 -0500, Joakim Erdfelt wrote:

(In reply to Thrilochana Rajappa from comment # 15)

Does the latest jetty libraries(9.1.1) support proxy server?

Latest Jetty is 9.2.7.v20150116

See: http://download.eclipse.org/jetty/

On 2015-02-13 03:18:02 -0500, Thrilochana Rajappa wrote:

Thanks. Does these libraries(9.2.7) support proxy server?

On 2015-03-04 05:03:52 -0500, Steffen Koehler wrote:

It would be a huge help also in our project to have Jetty websockets with proxy support, 'cause other ways I would have to search for another solution for my proxy problem and mix that then with the Jetty webserver somehow, which will be a pain, I guess..

I would really appreciate to have Gustavos patch (or something simular) been implemented. Unfortunately I'm not enough of an expert to support :-|

Thanks for your great work on Jetty

regards
Steffen

On 2015-04-16 14:30:26 -0400, Adam Foxman wrote:

Hi all,

Seems like this issue has stalled. I'd like to help kick-start it and get the original patch into the mainline distribution.

What is the next step? Is the patch suitable, or does it need work? I'm happy to provide dev support to help this along, if necessary.

On 2015-04-16 16:27:05 -0400, Gustavo Giráldez wrote:

Just a quick comment to let you know that we continued to add some functionality and fixes over the proposed patch. You can find the most current version (what we use in production) at https://github.com/manastech/jetty.project/commits/websocket-proxy. We added NTLM support and authentication over non-persistent connections. There are also a couple of bug fixes.

OTOH, it probably won't merge cleanly with the current version of Jetty and we added jCIFS as an extra dependency for the NTLM support.

On 2015-10-15 18:04:47 -0400, Joakim Erdfelt wrote:

Now that HttpClient has the beginnings of HTTP/1.1 upgrade support, we can start this work for proxy support.

Initial commit to [feature/wsclient-httpclient 3f1d566]

On 2016-01-26 03:26:54 -0500, Amir Karo wrote:

Hi Joakim,
This is good news that you started working on it as we have a lot of customers waiting for it.

Can you estimate when we can have a jetty version with this support?

Thanks!
Amir

migrated from Bugzilla #375278
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 7.6.2 on platform All
Assigned to: Project Inbox

On 2012-03-25 18:06:41 -0400, Greg Wilkins wrote:

The http://wiki.eclipse.org/Pack200 compression is supported since java 1.5 by URLClassLoader.

The webapp configuration processing should be updated to look for *.jar.pack.gz as well as *.jar

migrated from Bugzilla #393363
status ASSIGNED severity major in component server for 7.6.x
Reported in version unspecified on platform All
Assigned to: Greg Wilkins

Original attachment names and IDs:

• 0001-The-use-of-toUpperCase-must-be-Locale-insensitive.-O.patch (ID 223085)

On 2012-11-01 14:58:16 -0400, Mike Christianson wrote:

Created attachment 223085
Locale insensitive patch

The use of toUpperCase() must be Locale insensitive. Otherwise, setTarget() will throw a NoSuchMethodException when the rules of the default Locale produce an unexpected result. For example, if user.language=tr, then the following would produce "setÄ°nitialSize" rather than the expected "setInitialSize":

String target = "initialSize";
String setter = "set"+target.substring(0,1).toUpperCase()+target.substring(1);

This applies to current and past versions of Jetty.

On 2012-11-01 20:56:10 -0400, Greg Wilkins wrote:

This needed a wider solution as we do lots of toUpperCase and toLowerCase calls assuming the default local will work.

I have patched jetty-7 ( 65202e9 ) and these changes will soon be merged to 8 and 9.

I've not yet done a test harness for this.

migrated from Bugzilla #417223
status REOPENED severity normal in component server for 9.0.x
Reported in version 9.1.0 on platform All
Assigned to: Greg Wilkins

On 2013-09-13 16:01:22 -0400, Joakim Erdfelt wrote:

Since most of our code has been switched to use java.util.concurrent.Executor (such as the ServerConnector and whatnot).

Is it time now to eliminate the org.eclipse.jetty.util.thread.ThreadPool interface and class?

On 2013-09-15 20:58:18 -0400, Greg Wilkins wrote:

No.

Executor is the API for a consumer of execution services.

ThreadPool is-a Executor, but with some extra management method on it which are used in features such as resource monitoring.

We should reduce the usage of the ThreadPool API and only use Executor in places that only need to dispatch something to be executed, but at the Server layer at least we need to insist that our Executor impl is-a ThreadPool, so we can access the management methods.

On 2013-09-15 21:00:12 -0400, Joakim Erdfelt wrote:

Fair enough, it only came up as people in the process of migrating were confused that there seemed to be no way to setup or control threadpool in the connectors anymore.

Once we pointed out that the connectors are using executors and that QTP is an executor, it clicked, but it was still confusing in the javadoc and documentation.

On 2013-09-15 21:14:44 -0400, Greg Wilkins wrote:

Reopened to improve the javadoc

migrated from Bugzilla #322534
status REOPENED severity enhancement in component client for 7.1.x
Reported in version unspecified on platform PC
Assigned to: Project Inbox

Original attachment names and IDs:

• mycontribution.zip (ID 176746)

On 2010-08-12 10:07:56 -0400, Shooray wrote:

Build Identifier: 2204

It is truth that jetty-client doesn't support NTLM authentication. There is only one NTLM bug report which is on https://bugs.eclipse.org/bugs/show_bug.cgi?id=289669
So I've to do it myself. However, to my disappointed, jetty-client seems to has no ability to work with NTLM authentication. I've researched for a long time. My conclusion is jetty HttpDestination use different HttpConnection to resend with a pool. So IIS web server doesn't verify the challenge of the type3message which is sent by client.

Here are my source codes:

BasicTest.java
// ========================================================================
// This is the test main program.
// ========================================================================
import org.eclipse.jetty.client.ContentExchange;
import org.eclipse.jetty.client.HttpClient;
import org.eclipse.jetty.client.security.Realm;
import org.eclipse.jetty.client.security.RealmResolver;
import org.eclipse.jetty.client.security.SimpleRealmResolver;

public class BasicTest {

public static void main(String[] args) throws Exception {
HttpClient _client = new HttpClient();
_client.setConnectorType(HttpClient.CONNECTOR_SELECT_CHANNEL);
RealmResolver resolver = new SimpleRealmResolver(new Realm() {
public String getId() {
return "realm";
}

      public String getPrincipal() {
          return "test";
      }

      public String getCredentials() {
          return "password";

      }
  });
  _client.setRealmResolver(resolver);
  _client.start();

  ContentExchange exchange = new ContentExchange();

  // if send type2message directly, it may work fine mostly.
  //exchange.setRequestHeader("Authorization", "NTLM TlRMTVNTUAABAAAAATIAAA0ADQAgAAAADAAMAC0AAABXSU4ySzMtU0VSVkVSSkNJRlMwXzE4XzMx");
  exchange.setURL("http://192.168.10.156/ntlm/index.asp");
  exchange.setMethod("GET");
  exchange.setVersion(11);

  _client.send(exchange);
  exchange.waitForDone();

  System.out.println(exchange.getResponseStatus()); // all be 401
  System.out.println(new String(exchange.getResponseContentBytes()));

}
}

org/eclipse/jetty/client/security/SecurityListener.java
// ========================================================================
// Copyright (c) 2008-2009 Mort Bay Consulting Pty. Ltd.
// ------------------------------------------------------------------------
// All rights reserved. This program and the accompanying materials
// are made available under the terms of the Eclipse Public License v1.0
// and Apache License v2.0 which accompanies this distribution.
// The Eclipse Public License is available at
// http://www.eclipse.org/legal/epl-v10.html
// The Apache License v2.0 is available at
// http://www.opensource.org/licenses/apache2.0.php
// You may elect to redistribute this code under either of these licenses.
// ========================================================================

package org.eclipse.jetty.client.security;

import java.io.IOException;
import java.util.HashMap;
import java.util.Map;
import java.util.StringTokenizer;

import org.eclipse.jetty.client.HttpDestination;
import org.eclipse.jetty.client.HttpEventListenerWrapper;
import org.eclipse.jetty.client.HttpExchange;
import org.eclipse.jetty.http.HttpHeaders;
import org.eclipse.jetty.http.HttpStatus;
import org.eclipse.jetty.io.Buffer;
import org.eclipse.jetty.util.StringUtil;
import org.eclipse.jetty.util.log.Log;

/**

• SecurityListener

• Allow for insertion of security dialog when performing an

• HttpExchange.
  */
  public class SecurityListener extends HttpEventListenerWrapper
  {
  private HttpDestination _destination;
  private HttpExchange _exchange;
  private boolean _requestComplete;
  private boolean _responseComplete;
  private boolean _needIntercept;

  private int _attempts = 0; // TODO remember to settle on winning solution

  public SecurityListener(HttpDestination destination, HttpExchange ex)
  {
  // Start of sending events through to the wrapped listener
  // Next decision point is the onResponseStatus
  super(ex.getEventListener(),true);
  _destination=destination;
  _exchange=ex;
  }

  /**

  • scrapes an authentication type from the authString

  • @param authString

  • @return the authentication type
    */
    protected String scrapeAuthenticationType( String authString )
    {
    String authType;

    if ( authString.indexOf( " " ) == -1 )
    {
    authType = authString.toString().trim();
    }
    else
    {
    String authResponse = authString.toString();
    authType = authResponse.substring( 0, authResponse.indexOf( " " ) ).trim();
    }
    return authType;
    }

  /**

  • scrapes a set of authentication details from the authString

  • @param authString

  • @return the authentication details
    */
    protected Map<String, String> scrapeAuthenticationDetails( String authString )
    {
    Map<String, String> authenticationDetails = new HashMap<String, String>();
    authString = authString.substring( authString.indexOf( " " ) + 1, authString.length() );
    StringTokenizer strtok = new StringTokenizer( authString, ",");

    while ( strtok.hasMoreTokens() )
    {
    String token = strtok.nextToken();
    String[] pair = token.split( "=" );

    // authentication details ought to come in two parts, if not then just skip
    if ( pair.length == 2 )
    {
        String itemName = pair[0].trim();
        String itemValue = pair[1].trim();
    
        itemValue = StringUtil.unquote( itemValue );
    
        authenticationDetails.put( itemName, itemValue );
    }    
    else
    {
        Log.debug("SecurityListener: missed scraping authentication details - " + token );
    }
    

    }
    return authenticationDetails;
    }

  @OverRide
  public void onResponseStatus( Buffer version, int status, Buffer reason )
  throws IOException
  {
  if (Log.isDebugEnabled())
  Log.debug("SecurityListener:Response Status: " + status );

  if ( status == HttpStatus.UNAUTHORIZED_401 && _attempts<_destination.getHttpClient().maxRetries()) 
  {
      // Let's absorb events until we have done some retries
      setDelegatingResponses(false);
      _needIntercept = true;
  }
  else 
  {
      setDelegatingResponses(true);
      setDelegatingRequests(true);
      _needIntercept = false;
  }
  super.onResponseStatus(version,status,reason);
  

  }

  @OverRide
  public void onResponseHeader( Buffer name, Buffer value )
  throws IOException
  {
  if (Log.isDebugEnabled())
  Log.debug( "SecurityListener:Header: " + name.toString() + " / " + value.toString() );

  if (!isDelegatingResponses())
  {
      int header = HttpHeaders.CACHE.getOrdinal(name);
      switch (header)
      {
          case HttpHeaders.WWW_AUTHENTICATE_ORDINAL:
  
              // TODO don't hard code this bit.
              String authString = value.toString();
              String type = scrapeAuthenticationType( authString );
  
              String type2Message = null;
              if("ntlm".equalsIgnoreCase(type)) {
                if ( authString.indexOf( " " ) != -1 ) {
                    // if header is "WWW-Authenticate=NTLM TlRMTVNTUAACAAA......
                    // type2Message is not null
                    type2Message = authString.substring(authString.indexOf( " " ), authString.length()).trim();
                }
              }
  
              // TODO maybe avoid this map creation
              Map<String,String> details = scrapeAuthenticationDetails( authString );
              String pathSpec="/"; // TODO work out the real path spec
              RealmResolver realmResolver = _destination.getHttpClient().getRealmResolver();
  
              if ( realmResolver == null )
              {
                  break;
              }
  
              Realm realm = realmResolver.getRealm( details.get("realm"), _destination, pathSpec ); // TODO work our realm correctly 
  
              if ( realm == null )
              {
                  Log.warn( "Unknown Security Realm: " + details.get("realm") );
              }
              else if ("digest".equalsIgnoreCase(type))
              {
                  _destination.addAuthorization("/",new DigestAuthentication(realm,details));
  
              }
              else if ("basic".equalsIgnoreCase(type))
              {
                  _destination.addAuthorization(pathSpec,new BasicAuthentication(realm));
              }
              else if ("ntlm".equalsIgnoreCase(type))
              {
                _destination.addAuthorization("/",new NTLMAuthentication(realm, type2Message));
              }
  
              break;
      }
  }
  super.onResponseHeader(name,value);
  

  }

  @OverRide
  public void onRequestComplete() throws IOException
  {
  _requestComplete = true;

  if (_needIntercept)
  {
      if (_requestComplete && _responseComplete)
      {
         if (Log.isDebugEnabled())
             Log.debug("onRequestComplete, Both complete: Resending from onResponseComplete "+_exchange); 
          _responseComplete = false;
          _requestComplete = false;
          setDelegatingRequests(true);
          setDelegatingResponses(true);
          _destination.resend(_exchange);  
      } 
      else
      {
          if (Log.isDebugEnabled())
              Log.debug("onRequestComplete, Response not yet complete onRequestComplete, calling super for "+_exchange);
          super.onRequestComplete(); 
      }
  }
  else
  {
      if (Log.isDebugEnabled())
          Log.debug("onRequestComplete, delegating to super with Request complete="+_requestComplete+", response complete="+_responseComplete+" "+_exchange);
      super.onRequestComplete();
  }
  

  }

  @OverRide
  public void onResponseComplete() throws IOException
  {
  _responseComplete = true;
  if (_needIntercept)
  {
  if (_requestComplete && _responseComplete)
  {
  if (Log.isDebugEnabled())
  Log.debug("onResponseComplete, Both complete: Resending from onResponseComplete"+_exchange);
  _responseComplete = false;
  _requestComplete = false;
  setDelegatingResponses(true);
  setDelegatingRequests(true);
  _destination.resend(_exchange);

      }
      else
      {
         if (Log.isDebugEnabled())
             Log.debug("onResponseComplete, Request not yet complete from onResponseComplete,  calling super "+_exchange);
          super.onResponseComplete(); 
      }
  }
  else
  {
      if (Log.isDebugEnabled())
          Log.debug("OnResponseComplete, delegating to super with Request complete="+_requestComplete+", response complete="+_responseComplete+" "+_exchange);
      super.onResponseComplete();  
  }
  

  }

  @OverRide
  public void onRetry()
  {
  _attempts++;
  setDelegatingRequests(true);
  setDelegatingResponses(true);
  _requestComplete=false;
  _responseComplete=false;
  _needIntercept=false;
  super.onRetry();
  }

}

org/eclipse/jetty/client/security/NTLMAuthentication.java
// ========================================================================
// Author: Lion Shooray
// [email protected]
// ========================================================================
package org.eclipse.jetty.client.security;

import java.io.IOException;

import jcifs.ntlmssp.Type1Message;
import jcifs.ntlmssp.Type2Message;
import jcifs.ntlmssp.Type3Message;

import org.eclipse.jetty.client.HttpExchange;
import org.eclipse.jetty.http.HttpHeaders;
import org.eclipse.jetty.http.security.B64Code;
import org.eclipse.jetty.io.Buffer;
import org.eclipse.jetty.io.ByteArrayBuffer;
import org.eclipse.jetty.util.log.Log;

public class NTLMAuthentication implements Authentication {
private Buffer _authorization;

public NTLMAuthentication(Realm realm, String strType2Message) throws IOException
{
  String domain = "WIN2K3-SERVER";
  String authenticationString = null;
  if(strType2Message == null) { //type1
      authenticationString = "NTLM " + new String(B64Code.encode( buildType1Message(Type1Message.getDefaultFlags(),domain, null)));
  } else {//type2 -> type3
      byte[] byte2Msg = B64Code.decode(strType2Message);
      Type2Message type2Message = new Type2Message(byte2Msg);
      byte[] byte3Msg = buildType3Message(type2Message, realm.getCredentials(), domain, realm.getPrincipal(), null, Type3Message.getDefaultFlags());
      authenticationString = "NTLM " + new String(B64Code.encode(byte3Msg));
  }
    if (Log.isDebugEnabled())
        Log.debug("NTLMAuthentication(" + (strType2Message == null?"type1":"type3") + "): " + authenticationString );
    _authorization= new ByteArrayBuffer(authenticationString);
}

public void setCredentials(HttpExchange exchange) throws IOException {
exchange.setRequestHeader( HttpHeaders.AUTHORIZATION_BUFFER, _authorization);
}

protected byte[] buildType1Message(int flag, String domain, String workstation) {
Type1Message type1 = new Type1Message(flag, domain, workstation);
return type1.toByteArray();
}

protected byte[] buildType3Message(Type2Message type2, String password,
String domain, String user, String workstation, int flags) {
Type3Message type3 = new Type3Message(type2, password, domain, user,
workstation, flags);
return type3.toByteArray();
}
}

Reproducible: Always

Steps to Reproduce:

1. replace SecurityListener.java with my edition
   org/eclipse/jetty/client/security/SecurityListener.java
2. add new java file:
   org/eclipse/jetty/client/security/NTLMAuthentication.java
3. add jcifs-1.3.14.jar to classpath, you can get it from
   http://jcifs.samba.org/src/
4. run BaseTest.java to test

On 2010-08-16 07:57:24 -0400, Michael Gorovoy wrote:

Greetings,

NTLM authentication is connection-based, but Jetty HTTP Client is not aware of that, so this is likely the reason you are having problems.

It is possible however to implement NTLM authentication in Jetty HTTP Client by detecting it in a custom listener and delegating the transport to the java.net.UrlConnection that supports NTLM authentication in Java 6. However, you are going to loose Jetty HTTP Client's asynchronous request handling as a result.

Thanks,
Michael

*** This bug has been marked as a duplicate of bug 289669 ***

On 2010-08-16 23:16:06 -0400, Shooray wrote:

Created attachment 176746
This is a suggested implementation with jetty-client NTLM Authentication.

This is a suggested implementation with jetty-client NTLM Authentication.

NTLMAuthenticationTest.java is the test main program with JUnit4.

Steps to Reproduce:

1. prepare a NTLM authentication needed web server, in my case, it is http://192.168.10.156/ntlm/index.asp, you should modify it.
2. replace the org.eclipse.....xxx.java files in jetty-client project
3. add jcifs-1.3.14.jar and JUnit4 jars to classpath, you can get jcifs from
   http://jcifs.samba.org/src/
4. compile and run. it will work properly

I wish jetty become better and better. Thanks for your efforts.

Lion Sooray / [email protected] / 2010-8-17

On 2010-08-16 23:32:07 -0400, Shooray wrote:

Hi Michael:
You said right, I've also found detail about NTLM:
http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication
"3. ......From this point forward, the connection is kept open; closing the connection requires reauthentication of subsequent requests. This implies that the server and client must support persistent connections..."
And it was proved by sniffer tools.

However, it's a pity to hear you don't intend to implement NTLM Authentication in this jetty release. You said "loose Jetty HTTP Client's asynchronous request handling as a

result", I think that is not the truth. I've submited a suggested implementation with jetty-client NTLM Authentication for jetty project. Of cource, I'll use it in a production environment.

By the way, I suggest that you should put Realm(or RealmResolver) into exchange, not in HttpClient. So proxy can handle different request with different Principal/Credentials.

I wish jetty become better and better. Thanks for your efforts.

On 2010-08-16 23:48:04 -0400, Jesse McConnell wrote:

sadly jcifs is lgpl and as such there is no way we could take this patch...even if we were at apache I doubt we could take the patch since LGPL is basically off limits in most scenarios

http://jcifs.samba.org/

pity its not a friendly license, if it had been we would have used it a long time ago

the best bet is still banking on what support the jvm gives which is intermittent and dependent on the jvm and host operating system...we have had jetty client working with ntlm on linux, mac and windos jvm's using the mechanism that michael mentioned

cheers
jesse

On 2010-08-16 23:48:30 -0400, Jesse McConnell wrote:

oh, but I applaud the effort! :)

On 2010-08-17 00:35:17 -0400, Shooray wrote:

Hi jesse:
Thanks for your explanation about license and praise. I'm glad to have ability to contribute my efforts for you.
I don't think jcifs is the problem. Because I only use jcifs to make or parse type1,2,3 message. Moreover, NTLM protocol is open, anybody can implement it. I can rewrite it, or maybe Eclipse Communication Framework Project has finished it.

On 2010-08-23 23:28:29 -0400, Greg Wilkins wrote:

I've reopened this, so the effort does not get wasted.
We can monitor the situation and if a license suitable jcifs replacement becomes available then we can move.

We could also consider doing something in the codehaus release.

On 2010-08-23 23:31:39 -0400, Greg Wilkins wrote:

*** Bug 289669 has been marked as a duplicate of this bug. ***

On 2010-08-24 02:48:09 -0400, Michael Gorovoy wrote:

There are several other NTLM authentication libraries, e.g. Waffle (http://waffle.codeplex.com/), http://www.luigidragone.com/networking/ntlm.html, etc. However all of them are LGPL licensed.

On 2011-09-28 12:56:28 -0400, Jesse McConnell wrote:

nothing has really changed on this, its an enhancement and currently hands are tied regarding this due to IP issues...should that situation change I'll take it and resolve it once and for all

On 2011-10-13 12:46:11 -0400, Shooray wrote:

I used jetty to implement a reverse proxy last year. More bugs had been found and be resolved temporarily by myself, such as url encoding, etc. For work with NTLM, I have to use jetty work in bio not nio. however, in bio, jetty worker thread will auto increment until the thread pool be exhausted. I have to write a shell script to monitor the proxy, if jetty proxy cannot work, restart it automatically. It's a headache.
However, I am not responsible for that product now. If jetty team need my help, I'm still very happy to contribute something.
Good luck jetty!

On 2012-05-04 18:23:20 -0400, Carey Evans wrote:

It looks like Waffle is now using the Eclipse Public License:

https://github.com/dblock/waffle/blob/master/LICENSE

Does this make it useable for client authentication?

On 2012-05-04 21:29:04 -0400, Jesse McConnell wrote:

score! that is good news

first step is to get a CQ opened to use the library and then to get it into orbit

I'll try and get that process started next week

nice catch!

On 2012-07-17 10:09:52 -0400, Jesse McConnell wrote:

update, until waffle is published in maven central I don't think we'll bother with getting the CQ through for this...it had moved to github and is EPL which is nice

On 2013-05-13 02:23:29 -0400, Michael Hawkshaw wrote:

Looks like Waffle is now available in Maven Central: https://oss.sonatype.org/content/repositories/releases/com/github/dblock/waffle/

migrated from Bugzilla #416688
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 9.0.5 on platform PC
Assigned to: Project Inbox

Original attachment names and IDs:

• test.log (ID 235222)

On 2013-09-06 03:53:00 -0400, Mikhail Mazursky wrote:

Created attachment 235222
Three stacktraces

Please take a look at the attached stacktraces. Can exception be logged only once please? Exception can have much bigger stacktrace and a cause chain. This will result in a lot of traces in logs.

migrated from Bugzilla #399774
status ASSIGNED severity enhancement in component http2 for 9.3.x
Reported in version 9.2.10 on platform PC
Assigned to: Project Inbox

On 2013-02-02 11:54:39 -0500, Simone Bordet wrote:

Currently, ReferrerPushStrategy creates resource dependencies based on the Referer header only.

In case a website does user-agent sniffing to provide different resources based on the user agent, the resource dependencies may be built for e.g. a desktop browser and pushed to a mobile browser.

On 2015-04-01 18:07:45 -0400, Greg Wilkins wrote:

Consider for http2?

migrated from Bugzilla #400738
status ASSIGNED severity normal in component server for 9.0.x
Reported in version 9.0.0 on platform All
Assigned to: Project Inbox

On 2013-02-13 16:27:03 -0500, Joakim Erdfelt wrote:

If you request a range of content from the ResourceHandler it returns the entire file.

On 2013-02-13 16:28:21 -0500, Joakim Erdfelt wrote:

Adding testcase showing failure at
jetty-server/src/test/java/org/eclipse/jetty/server/handler/ResourceHandlerRangeTest.java

in [master f15d4c0]

migrated from Bugzilla #409118
status ASSIGNED severity enhancement in component http2 for 9.3.x
Reported in version unspecified on platform All
Assigned to: Project Inbox

On 2013-05-27 04:45:17 -0400, Thomas Becker wrote:

Build Identifier:

It might make sense to push smaller data frames to be able to react better to browsers who reset push streams. Less data would have been send to the browser in case of RSTs.

Or make sure that data is only sent if the browser already accepted the push stream.

Reproducible: Always

On 2013-05-27 05:32:51 -0400, Simone Bordet wrote:

Thomas, I am not sure how smaller frames will help the client, especially in case of high latency. I guess we will just be slowing down pushes.

Waiting to push content until the browser accepts the stream is also subject to round trip delays, which spdy push attemps to eliminate.

Can you elaborate ?

On 2013-05-27 13:41:43 -0400, pat mcmanus wrote:

(In reply to comment # 1)

Thomas, I am not sure how smaller frames will help the client, especially in
case of high latency. I guess we will just be slowing down pushes.

Hi Simone - I made the suggestion for this bug to Thomas, so I'll elaborate.

Any prioritized muxed protocol needs small frame sizes because once you write the frame data length (in the header) to the wire you are committed to serializing the rest of the frame no matter how long it takes. During that serialization time you cannot react to a new higher priority sending opportunity (such as another stream, or cancellation of the stream your are sending). So its best to minimize the serialization time of each frame.

The latency of the connection doesn't matter to this strategy, because if at the end of the serialization the data stream that just wrote out the frame is still the highest priority stream then it can just immediately write another one - it doesn't need to wait for an ack or anything that might be driven by rtt. Basically, instead of sending 1 64KB frame, I'm suggesting sending 16 4KB frames in the common case. The only thing it costs you is an extra 120 bytes (15 extra 8 byte headers) - which is trivial overhead on 64KB of data. In return the connection stays responsive to higher priority events.

So this comment isn't just about push - imo frame sizes should really never go above 4KB.. below that overhead starts to be come an arugmenet but it's re rally hard to see the downside of 1 byte in 500 overhead.

Even pulled things get canceled all the time.. when you nav between pages and the resources aren't finished loading they get canceled - I want the connection to be able to send the new page data immediately instead of continuing to serialize the old streams.

but push is more likely to run into this problem because pushed streams are more likely to be canceled inherently. This is because they might be pushing things already in the client cache (unknowable to the server at push time), or they might be pushing things the client won't ever fetch due to policy (e.g. adblock plus, or greasemonkey rewriting your html, etc..) or maybe the client just has push disabled due to resource constraints.

Waiting to push content until the browser accepts the stream is also subject
to round trip delays, which spdy push attemps to eliminate.

definitely don't wait :)

hth

On 2015-04-01 18:06:07 -0400, Greg Wilkins wrote:

Consider this suggestion for http2

migrated from Bugzilla #391187
status ASSIGNED severity enhancement in component server for 7.6.x
Reported in version 8.1.7 on platform PC
Assigned to: Jan Bartel

On 2012-10-05 01:27:04 -0400, Jan Bartel wrote:

A further tweak to fix for bug 391080:

Although the 3.0 spec says you can only call Request.getPart()/getParts() from a servlet annotated with @MultiPartConfig or , we want to allow it to be called from any servlet. Currently, if that was done, the tmp files would not be cleaned up, so requires some refactoring to allow it to work.

On 2012-10-07 20:51:53 -0400, Jan Bartel wrote:

Marking this as an enhancement.

migrated from Bugzilla #381368
status ASSIGNED severity enhancement in component server for 9.3.x
Reported in version unspecified on platform All
Assigned to: Greg Wilkins

On 2012-06-01 09:04:18 -0400, Bruno Harbulot wrote:

Build Identifier:

This is a follow up of http://jira.codehaus.org/browse/JETTY-456

Having a quick look at org.eclipse.jetty.util.security.CertificateUtils [1] used by SslContextFactory, it seems it's not able to load a keystore that doesn't depend on a file or input stream, such as PKCS# 11 tokens or Apple's KeychainStore.

The JSSE Reference Guide [2] uses "NONE" as a special file name for these (although another configuration option might be to try to load the keystore if the path is null). "NONE" is the JSSE default, and it's unlikely that anyone would use it as an actual file name.

In these cases, the InputStream passed to load() should be null (the actual configuration is done either via the provider name or via the keystore type).

[1] http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-util/src/main/java/org/eclipse/jetty/util/security/CertificateUtils.java
[2] http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Customization

Reproducible: Always

migrated from Bugzilla #413788
status ASSIGNED severity minor in component server for 9.1.x
Reported in version 9.0.4 on platform All
Assigned to: Simone Bordet

On 2013-07-26 05:21:08 -0400, Mikhail Mazursky wrote:

Using System.currentTimeMillis() is not the best option to measure time intervals inside JVM. System.nanoTime() provides better precision and it do not depend on system clock (!).

E.g. QueuedThreadPool can use System.nanoTime() to measure timeouts and be immune to system clock adjustments (e.g. by NTPD).

If you decide to implement this enhancement, please thoroughly look at nanoTime() javadocs - there is a possibility of overflow if method is used incorrectly.

On 2013-09-05 05:49:24 -0400, Simone Bordet wrote:

Notes: System.nanoTime() is subject to NTP changes under 64-bit Linux, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6900441.

But yes, in general we should use System.nanoTime() everywhere.

On 2013-09-05 06:54:07 -0400, Mikhail Mazursky wrote:

JFYI there is a discussion about this bug happening right now on concurrency mailing list.
cs.oswego.edu/pipermail/concurrency-interest/2013-September/011759.html

This is an enhancement request to include the TLS protocol that was used to establish the connection in the request attributes that SecureRequestCustomizer uses.

This enhancement request is for Jetty 9.2.x +

http://stackoverflow.com/questions/35413971/spring-boot-jetty-catch-upload-error-file-too-big

It seems that Spring's org.springframework.web.multipart.MultipartException is not thrown when running under Jetty, as it is on Tomcat.
In Jetty 9.2.14, we throw a IllegalStateException, which isn't what Spring is expecting.

java.lang.IllegalStateException: Multipart Mime part file exceeds max filesize
at org.eclipse.jetty.util.MultiPartInputStreamParser$MultiPart.write(MultiPartInputStreamParser.java:111) ~[jetty-util-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.util.MultiPartInputStreamParser.parse(MultiPartInputStreamParser.java:681) ~[jetty-util-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.util.MultiPartInputStreamParser.getParts(MultiPartInputStreamParser.java:400) ~[jetty-util-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.server.Request.getParts(Request.java:2146) ~[jetty-server-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.server.Request.extractMultipartParameters(Request.java:386) ~[jetty-server-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.server.Request.extractContentParameters(Request.java:309) ~[jetty-server-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.server.Request.extractParameters(Request.java:257) ~[jetty-server-9.2.14.v20151106.jar:9.2.14.v20151106]
at org.eclipse.jetty.server.Request.getParameter(Request.java:826) ~[jetty-server-9.2.14.v20151106.jar:9.2.14.v20151106]
at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) ~[javax.servlet-api-3.1.0.jar:3.1.0]
at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:70) ~[spring-web-4.2.3.RELEASE.jar:4.2.3.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-4.2.3.RELEASE.jar:4.2.3.RELEASE]

migrated from Bugzilla #387302
status ASSIGNED severity major in component server for 9.0.x
Reported in version 7.5.4 on platform PC
Assigned to: Project Inbox

On 2012-08-15 12:53:41 -0400, Robert Kuhar wrote:

My jetty.xml is configured to produce the Jetty NCSARequestLog like...

<!-- Built-in Jetty AccessLog log -->
<Ref id="AccessLog">
  <Set name="requestLog">
    <New id="RequestLogImpl" class="org.eclipse.jetty.server.NCSARequestLog">
      <Arg><SystemProperty name="jetty.logs" default="/data/logs"/>/dm-app1_access.yyyy_mm_dd.log</Arg>
      <Set name="filenameDateFormat">yyyyMMdd</Set>
      <Set name="retainDays">3</Set>
      <Set name="append">true</Set>
      <Set name="extended">false</Set>
      <Set name="logLatency">true</Set>
      <Set name="LogTimeZone">GMT</Set>
    </New>
  </Set>
</Ref>

In production what we are observing is that the log file frequently fails to rollover to the new day. This results in some logfiles containing 2 or more days worth of request log entries. The effect of this is that our aggregate reporting is having difficulty integrating with Jetty.

Note below how the head and tail of dm-app1_access.20120810.log and dm-app1_access.20120813.log is just 24 hours apart BUT dm-app1_access.20120811.log is 48 hours and dm-app1_access.20120814.log (current) includes more than just one day.

Whats up with that?

[rkuhar@dm-app1 ~]$ ls -l /data/logs/dm-app1_access.2012*log
-rw-r--r-- 1 jetty jetty 91506402 Aug 10 23:53 /data/logs/dm-app1_access.20120810.log
-rw-r--r-- 1 jetty jetty 179615954 Aug 12 23:53 /data/logs/dm-app1_access.20120811.log
-rw-r--r-- 1 jetty jetty 88965122 Aug 13 23:53 /data/logs/dm-app1_access.20120813.log
-rw-r--r-- 1 jetty jetty 155233912 Aug 15 16:29 /data/logs/dm-app1_access.20120814.log

[rkuhar@dm-app1 ~]$ head -n 2 /data/logs/dm-app1_access.20120810.log
10.23.138.134 - - [10/Aug/2012:00:00:17 +0000] "GET /devices/HT25AW303448/config?names=stores HTTP/1.1" 200 139 4
10.23.138.136 - - [10/Aug/2012:00:00:17 +0000] "GET /devices/HT15TT509480/profile HTTP/1.1" 200 166 2
[rkuhar@dm-app1 ~]$ tail -n 2 /data/logs/dm-app1_access.20120810.log
10.23.138.134 - - [11/Aug/2012:00:00:16 +0000] "GET /devices/SH254W107502/profile HTTP/1.1" 200 165 1
10.23.138.136 - - [11/Aug/2012:00:00:16 +0000] "GET /devices/SH23SVP01744/profile HTTP/1.1" 200 165 1
[rkuhar@dm-app1 ~]$ head -n 2 /data/logs/dm-app1_access.20120811.log
10.23.138.136 - - [11/Aug/2012:00:00:17 +0000] "GET /devices/HT16PHX10599/profile HTTP/1.1" 200 165 2
10.23.138.133 - - [11/Aug/2012:00:00:17 +0000] "GET /admin/hb " 200 137 2
[rkuhar@dm-app1 ~]$ tail -n 2 /data/logs/dm-app1_access.20120811.log
10.23.138.136 - - [13/Aug/2012:00:00:16 +0000] "GET /devices/SH24SVP00694/profile HTTP/1.1" 200 165 1
10.23.138.134 - - [13/Aug/2012:00:00:16 +0000] "GET /devices/HT23MW407650/profile HTTP/1.1" 200 165 1
[rkuhar@dm-app1 ~]$ head -n 2 /data/logs/dm-app1_access.20120813.log
10.23.138.134 - - [13/Aug/2012:00:00:17 +0000] "GET /devices/HT26JS405035/profile HTTP/1.1" 200 165 2
10.23.138.133 - - [13/Aug/2012:00:00:18 +0000] "GET /admin/hb " 200 137 1
[rkuhar@dm-app1 ~]$ tail -n 2 /data/logs/dm-app1_access.20120813.log
10.23.138.135 - - [14/Aug/2012:00:00:17 +0000] "GET /devices/HT24GW408085/config?names=stores HTTP/1.1" 200 139 1
10.23.138.135 - - [14/Aug/2012:00:00:17 +0000] "GET /devices/HC27MMG18780/config?names=stores HTTP/1.1" 200 139 2
[rkuhar@dm-app1 ~]$ head -n 2 /data/logs/dm-app1_access.20120814.log
10.23.138.135 - - [14/Aug/2012:00:00:17 +0000] "GET /devices/HT1ATVJ13049/config?names=stores HTTP/1.1" 200 139 2
10.23.138.135 - - [14/Aug/2012:00:00:17 +0000] "GET /devices/HT278S408000/config?names=stores HTTP/1.1" 200 139 2
[rkuhar@dm-app1 ~]$ tail -n 2 /data/logs/dm-app1_access.20120814.log
10.23.138.134 - - [15/Aug/2012:16:46:58 +0000] "PUT /devices/HC1CPMA00945/profile HTTP/1.1" 204 0 1
10.23.138.134 - - [15/Aug/2012:16:46:58 +0000] "GET /devices/12B9WQ2B0073270/profile HTTP/1.1" 200 166 2

While you are at it, the rollover itself always seems to be 16 or 17 seconds beyond the hour. It would be nice if this occurred within a second of midnight.

On 2012-08-15 14:47:02 -0400, Joakim Erdfelt wrote:

NCSARequestLog uses our RolloverFileOutputStream to manage rollover.
Our RolloverFileOutputStream uses java.util.Timer and java.util.TimerTask to perform the nightly (at midnight) rollover of the file.

http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-util/src/main/java/org/eclipse/jetty/util/RolloverFileOutputStream.java#n162

If this is not accurate enough for you, I would recommend using a more robust logging framework such as slf4j + logback + logback-access with its replacement access logging framework for jetty.

http://logback.qos.ch/access.html

We've prepared an example project that integrates slf4j + logback + logback-access at https://github.com/jetty-project/jetty-and-logback-example

On 2012-08-16 18:34:42 -0400, Greg Wilkins wrote:

Rollover is an ancient class.... probably needs a good makeover. Coming soon.

migrated from Bugzilla #402408
status ASSIGNED severity enhancement in component client for 9.0.x
Reported in version 9.0.0.RC2 on platform All
Assigned to: Simone Bordet

On 2013-03-05 03:26:39 -0500, Jo Rabin wrote:

If a request results in redirection, this is not remembered so each request I make to a redirected destination seems to have to go through the same redirection process, even though the redirection is "Moved Permanently".

I'm wondering if this also has some kind of knock on impact on maxConnectionsPerDestination, since Destinations that may think they are different may in fact be the same, following redirection?

migrated from Bugzilla #329177
status ASSIGNED severity enhancement in component server for 7.1.x
Reported in version 8.0.0 on platform All
Assigned to: Jan Bartel

On 2010-11-01 03:22:48 -0400, Jan Bartel wrote:

Consider adding support for the java: namespace hierarchy introduced with Javaee6.

On 2010-11-01 03:28:44 -0400, Jan Bartel wrote:

Depends on bug # 329175 in the sense that in order to do the injection, you need to be able to specify the lookup= params to @resource.

migrated from Bugzilla #402626
status REOPENED severity normal in component server for 9.0.1
Reported in version 9.0.0.RC2 on platform PC
Assigned to: Simone Bordet

Original attachment names and IDs:

• jetty9-client-cert-bug.tar (ID 228050)

On 2013-03-07 05:11:37 -0500, Ben Summers wrote:

Created attachment 228050
tar archive containing keystore & client cert generation scripts and modified example config

I am porting my application to Jetty 9, and while everything else works perfectly and the API is much improved, I cannot get SSL client certificates to work.

In the attached archive, there is a script which generates a Java keystore containing:

• A self-signed server certificate
• A CA for client certificates

It also generates an example client certificate, client.pkcs12, for you to use to test.

The supplied configuration files are the examples from the distribution, except:

• Change keystore passwords to 'password'
• Add true

To test:

• Run ./makekeystore.sh
• Start the Jetty 9 server using the configuration files, eg using ./run.sh after setting CLASSPATH
• Import the client.pkcs12 file on your computer (password is 'password')
• Attempt to connect to the server https://HOSTNAME:8443 with the appropriate hostname.

You will get a certificate warning following by a "choose client certificate" prompt. (I'm using Safari on a Mac). But after that, the connection fails.

Removing NeedClientAuth shows the rest of the SSL server config is OK, but obviously it doesn't ask for a client cert.

I have tried a similar configuration on Jetty 7. Client certs work with this version, so I believe the keystore generation and configuration is correct. (use same makekeystore.sh script, copy example configs, change password and add NeedClientAuth, run server, import client cert, connect to server.)

On 2013-03-07 16:39:14 -0500, Ben Summers wrote:

I have confirmed that the current testing version, jetty-9.0.0.v20130306, also has this problem.

On 2013-03-07 17:00:42 -0500, Greg Wilkins wrote:

Ben,

thanks for the report and test harnesses required to replicate.

I will look today and see if we can get a fix into the 9.0.0 branch, but currently I'm expecting that we'll miss that train and this will be fixed in 9.0.1.

I'll see if we can use your tests to create a unit test for client certificate processing.

Note that jetty 9 has an entirely new SSL connection, so I'm guessing we just forgot to turn on need client cert or similar.

cheers

On 2013-03-07 17:02:51 -0500, Ben Summers wrote:

Thanks for looking at it, very much appreciated. It'd be great to have a fix in 9.0.0 if at all possible.

On 2013-03-07 20:12:32 -0500, Greg Wilkins wrote:

This is the core exception that is causing the handshake failure:

javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1364)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:790)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:758)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:488)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:216)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:240)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:589)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:520)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1703)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:278)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1673)
at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:176)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1301)
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.fill(SslConnection.java:547)
... 5 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:208)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:93)
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:347)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:255)
at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:132)
at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1660)
... 12 more

On 2013-03-07 20:37:57 -0500, Greg Wilkins wrote:

I can't yet find a way to get the trustmanager used by the ssl context to trust localhost. I can see reports of setting a hostnamechecker, but can't find the right magic juice to do this for SSLEngine.

Can you configure jetty logging to printout ignored exceptions, so you should be able to verify that you get the same exception.

We then have to work out how to make it trust localhost, which will either make it work, or reveal the next problem.

On 2013-03-08 04:31:26 -0500, Ben Summers wrote:

I'm afraid I couldn't check the error as I can't seem to get it to display the ignored errors. However, the exception and a quick look at the OpenJDK sources have enabled me to work out the problem.

It's not that client certs don't work, it's that Jetty 9 has a surprising default configuration which is different to that in Jetty 7: it's performing hostname verification of the client on the server side!

Client certificates won't generally use hostnames as common names, as they're generally identifying people not hosts, and just rely on the signing CA having their root certificate in the keystore. Verifying the hostname of the client is probably a rather unusual configuration.

I resolved the issue in my application by calling setEndpointIdentificationAlgorithm(null) on the SslContextFactory.

If you would like to restore the Jetty 7 behaviour, which probably makes sense, then, if and only if the SslContextFactory is ONLY used on the server, you just need to change

/** EndpointIdentificationAlgorithm - when set to "HTTPS" hostname verification will be enabled */
private String _endpointIdentificationAlgorithm = "HTTPS";

to

/** EndpointIdentificationAlgorithm - when set to "HTTPS" hostname verification of the client certificate will be enabled */
private String _endpointIdentificationAlgorithm = null;

If this code is shared with Jetty client, then this would be a very bad change, for obvious reasons.

I suspect the setEndpointIdentificationAlgorithm() Java API is confusingly named. I would have called it setEndpointCommonNameMatchingRules(). If you look in the JDK sources, you can see that the certificate is verified regardless of this option.

Thanks for your help in tracking this down.

Incidentally, I couldn't work out how to set null in the XML configuration. My reading of the docs meant I thought this would do the job:

  <Set name="EndpointIdentificationAlgorithm"></Set>

But it doesn't seem to.

(For showing ignored errors, I tried this command line:

java -Dorg.eclipse.jetty.util.log.IGNORED=true -Dorg.eclipse.jetty.util.log.stderr.LONG=true -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog org.eclipse.jetty.xml.XmlConfiguration jetty.xml jetty-https.xml

which I thought should have worked according to the docs, but didn't.)

On 2013-03-08 08:13:46 -0500, Jesse McConnell wrote:

given the migration of docs from the wiki to the docbook setup can you point out the bad docs?

(jetty-9 docs)

http://www.eclipse.org/jetty/documentation/current/

On 2013-03-08 08:16:52 -0500, Ben Summers wrote:

http://www.eclipse.org/jetty/documentation/current/reference-section.html#jetty-xml-arg

(referred to by the section.)

In the example, it gives:

Which I tried, but it didn't work.

It's possible the docs are correct and I didn't read them properly. Does it use the signature of the setter function to determine type automatically?

On 2013-03-11 02:44:42 -0400, Greg Wilkins wrote:

Ben,

thanks for progressing this.

The best logging documentation is currently at http://wiki.eclipse.org/Jetty/Feature/Jetty_Logging

and all you need to see the exception is

-Dorg.eclipse.jetty.server.HttpConnection.LEVEL=debug

or just

-Dorg.eclipse.jetty.LEVEL=debug

(sorry was miss information about the IGNORED)

We will add a logging section to Jetty-9 doco soon.

Looking at other aspects now

On 2013-03-11 03:01:59 -0400, Greg Wilkins wrote:

(In reply to comment # 8)

http://www.eclipse.org/jetty/documentation/current/reference-section.
html#jetty-xml-arg

(referred to by the section.)

In the example, it gives:

Which I tried, but it didn't work.

It's possible the docs are correct and I didn't read them properly. Does it
use the signature of the setter function to determine type automatically?

I added

to the section in jetty-https.xml that starts with

and that worked fine!

On 2013-03-13 18:26:32 -0400, Greg Wilkins wrote:

Changed the default so that host identity is not done by default.

On 2013-03-13 18:28:05 -0400, Greg Wilkins wrote:

Simone,

can you update the client code/examples so that SslContextFactory.setEndpointIdentificationAlgorithm("HTTPS") is done.

On 2013-06-12 04:29:37 -0400, Prasad BLV wrote:

Are there any updates on the above mentioned issue. I am also facing same problems in 9.0.3.v20130506 version.

On 2013-06-12 04:55:21 -0400, Ben Summers wrote:

Prasad -- read comment 6 and following comments for the solution.

On 2013-06-12 05:38:23 -0400, Prasad BLV wrote:

Thank you for your quick reply. I tried the configuration mentioned after comment 6 but I am getting the below given exception :

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificateChain(SSLSessionImpl.java:446)
at org.eclipse.jetty.util.ssl.SslContextFactory.getCertChain(SslContextFactory.java:1354)
at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:104)
at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:54)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:259)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
at java.lang.Thread.run(Thread.java:722)

Below given is my configuration for SSLContext Factory :

/


/

Please let me know if missing anything...

migrated from Bugzilla #414007
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 9.0.4 on platform All
Assigned to: Joakim Erdfelt

On 2013-07-30 09:53:28 -0400, Joakim Erdfelt wrote:

When using the --exec features of the start.ini, provide a means to set environment variables for the spawned JVM.

On 2014-07-04 10:19:07 -0400, Philippe PRADOS wrote:

It's possible to add -DXXX but no -DXXX=YYY.

migrated from Bugzilla #416482
status ASSIGNED severity normal in component server for 9.0.x
Reported in version 9.0.4 on platform PC
Assigned to: Project Inbox

On 2013-09-03 20:13:15 -0400, Viktor Szathmary wrote:

The default servlet creates a ResourceCache which is supposed to avoid repeated expensive operations. However jetty still repeatedly issues filesystem stat calls (eg. via FileResource.isDirectory and exists).

This can be evidenced by following the operations during file serving using:

strace -f -p -e stat

On 2013-09-05 01:41:41 -0400, Greg Wilkins wrote:

Viktor,

The cache still checks on every access that the file is still valid on the disk and of the same date stamp and type etc.

The resource cache could be made to check these only at intervals. Even if done every second, then this could save many thousands of lookups.

However the problem remains with filemapped buffers that if the file changes, we would see the content changed before we checked the meta data. But in most cases this is not a real risk.

Seen in comment on stackoverflow http://stackoverflow.com/questions/35413971/spring-boot-jetty-catch-upload-error-file-too-big

I'm not certain, but I think this may be a bug in Jetty. With Tomcat, a MultipartException is thrown by Spring MVC from within DispatcherServlet.checkMultipart. This method accesses all of the request's parts. Tomcat throws an exception when one of the parts is too big, triggering the MultipartException. Jetty, on the other hand, allows Spring MVC to retrieve all of the request parts, even when one of them exceeds the maximum size. It then fails later on when a second attempt is made to access the request's parts but it's too late for Spring MVC to throw a MultipartException.

This seems like it might be a behavioral bug.

I think it could be a race between client seeing the close and the server completing the close.
Test ignored for now.

Failed tests:
SessionTrackingTest.testAddRemoveSessions:164->assertServerOpenConnectionCount:178 Session.isopen: WebSocketSession[websocket=JsrAnnotatedEventDriver[websocket=org.eclipse.jetty.websocket.jsr356.server.SessionTrackingTest$EchoSocket@1b4b1ad3],behavior=SERVER,connection=WebSocketServerConnection@E01395AF{endp=SelectChannelEndPoint@5f21eed1{/127.0.0.1:34636<->40254,CLOSED,ISHUT,OSHUT,-,-,7/300000,WebSocketServerConnection}{io=0/0,kio=-1,kro=-1},ios=IOState@158cf7ca[CLOSED,!in,!out,finalClose=CloseInfo[code=1000,reason=null],clean=true,closeSource=REMOTE],f=Flusher[queueSize=0,aggregateSize=0,failure=null],g=Generator[SERVER,validating],p=Parser@11b371a3[ExtensionStack,s=START,c=0,len=2,f=CLOSE[len=2,fin=true,rsv=...,masked=true]]},remote=WebSocketRemoteEndpoint@17efe836[batching=true],incoming=JsrAnnotatedEventDriver[websocket=org.eclipse.jetty.websocket.jsr356.server.SessionTrackingTest$EchoSocket@1b4b1ad3],outgoing=ExtensionStack[queueSize=0,extensions=[],incoming=org.eclipse.jetty.websocket.jsr356.JsrSession,outgoing=org.eclipse.jetty.websocket.server.WebSocketServerConnection]]
Expected: is
but: was

migrated from Bugzilla #414348
status ASSIGNED severity normal in component server for 9.0.x
Reported in version 9.0.4 on platform PC
Assigned to: Greg Wilkins

On 2013-08-02 21:49:16 -0400, Eli Bishop wrote:

This is a race condition so unlikely that I can't think how you could go about reproducing the problem, but I think the code is pretty obviously flawed.

In AbstractSessionIdManager.newSessionId(HttpServletRequest, long), there is a while loop with the condition "id==null||id.length()==0||idInUse(id)"; it continues generating new random session IDs until "idInUse" returns false; then at some point later, it saves the new session using the last ID generated.

However, that doesn't actually ensure that the session ID is unique-- just that it was unique at the top of the loop. If another thread/process happens to generate the same ID at roughly the same time, they will both end up trying to use it.

What is really needed there is an atomic test-and-set - check whether the session ID exists and, if it didn't exist, store some data indicating that it's now in use even though there isn't yet a corresponding session. Unfortunately, the SessionIdManager interface has no method with those semantics, and it wouldn't be safe to redefine idInUse() to work that way because idInUse() is also used elsewhere in a context where you do not want to create that ID. So this would probably have to be a backward-incompatible interface change.

On 2013-08-02 22:34:27 -0400, Eli Bishop wrote:

Note that an attempt by the developer of "jetty-nosql-memcached" to work around this issue - by overriding idInUse() to do what I described in my last paragraph - caused a much more blatant bug (https://github.com/yyuu/jetty-nosql-memcached/issues/18). I don't think there is any valid workaround for this issue in the current Jetty architecture.

Frequently when running full builds in 9.3.x I get:

Running org.eclipse.jetty.http.client.HttpChannelAssociationTest.testIdleTimeoutJustBeforeAssociation[transport: FCGI]()
2016-02-16 16:32:35.291:INFO:oejs.Server:main: jetty-9.3.8-SNAPSHOT
2016-02-16 16:32:35.291:INFO:oejs.ServerConnector:main: Started 
ServerConnector@1f010bf0{fcgi/1.0,[fcgi/1.0]}{0.0.0.0:33332}
2016-02-16 16:32:35.291:INFO:oejs.Server:main: Started @51615ms
2016-02-16 16:32:35.292:INFO:oejus.SslContextFactory:main: x509=X509@1921ad94(mykey,h=[],w=[]) for SslContextFactory@ee86bcb(file:///home/gregw/src/jetty-9.3.x/tests/test-http-client-transport/src/test/resources/keystore.jks,file:///home/gregw/src/jetty-9.3.x/tests/test-http-client-transport/src/test/resources/truststore.jks)
2016-02-16 16:32:37.296:INFO:oejs.ServerConnector:main: Stopped ServerConnector@1f010bf0{fcgi/1.0,[fcgi/1.0]}{0.0.0.0:0}
Tests run: 10, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.134 sec <<< FAILURE! - in org.eclipse.jetty.http.client.HttpChannelAssociationTest
testIdleTimeoutJustBeforeAssociation[transport: H2](org.eclipse.jetty.http.client.HttpChannelAssociationTest)  Time elapsed: 5.009 sec  <<< FAILURE!
java.lang.AssertionError: null
    at org.junit.Assert.fail(Assert.java:86)
    at org.junit.Assert.assertTrue(Assert.java:41)
    at org.junit.Assert.assertTrue(Assert.java:52)
    at org.eclipse.jetty.http.client.HttpChannelAssociationTest.testIdleTimeoutJustBeforeAssociation(HttpChannelAssociationTest.java:124)

migrated from Bugzilla #404328
status ASSIGNED severity minor in component server for 9.3.x
Reported in version 9.0.0 on platform All
Assigned to: Project Inbox

On 2013-03-26 02:01:20 -0400, Greg Wilkins wrote:

It would be good if the request getHost could be logged in the NCSA request log format without breaking its compatibility with common tools.

On 2013-05-21 20:17:04 -0400, Joakim Erdfelt wrote:

We would probably have to support the Extended Log File Format spec a bit better then.

http://www.w3.org/TR/WD-logfile

Such as producing the directives lines at the top of every log file we produce indicating which fields we are emitting.

I think this new field would be "cs-dns".

On 2014-09-22 18:12:57 -0400, Joakim Erdfelt wrote:

Reassigning to default, flagging as helpwanted (our equiv of "low hanging fruit")

On 2015-04-22 20:31:41 -0400, Greg Wilkins wrote:

hmmm serverName is already an option

migrated from Bugzilla #372656
status ASSIGNED severity normal in component osgi for 7.5.x
Reported in version 8.1.1 on platform PC
Assigned to: Jan Bartel

Original attachment names and IDs:

• bugzilla_372656.tgz (ID 211832)

On 2012-02-27 11:06:56 -0500, Caspar MacRae wrote:

Hi,

I can see the work needed to unwrap Bundle original location into something that Jetty can inspect the contents of (ie. the cached copy). The workaround here doesn't work with Karaf/Felix and bundles deployed via the mvn url handler (from PaxUrl).

I'm using Karaf (2.2.4) where it seems the behaviour of the mvn URL handler differs between Equinox and Felix (from what I can see the bundle original location is set to the cached file for Equinox so gets bundle:file: protocol whereas for Felix it's the genuine original URl of mvn://).

The following classes, walk the known path of the Felix cache, using documented behaviour (http://felix.apache.org/site/apache-felix-framework-bundle-cache.html) to find the locally cached version of the bundle.

This is working fine for me when packaged inside a fragment of "org.eclipse.jetty.osgi.boot" - may be this could be merged into
org.eclipse.jetty.osgi.boot.utils.internal.DefaultFileLocatorHelper as there's no dependencies and it's a tiny addition?

Apologies for inline code, but just two classes:

package org.eclipse.jetty.osgi.boot.utils;

import static org.osgi.framework.Constants.FRAMEWORK_STORAGE;

import java.io.File;
import java.io.FileFilter;
import java.net.URL;
import java.util.Enumeration;

import org.osgi.framework.Bundle;

public class FileLocatorHelperImpl implements BundleFileLocatorHelper {

private static final String FELIX_BUNDLE_IMP_CLASS = "org.apache.felix.framework.BundleImpl";

@OverRide
public File getBundleInstallLocation(Bundle bundle) throws Exception
{
File retVal = DEFAULT.getBundleInstallLocation(bundle);

  if(retVal == null && FELIX_BUNDLE_IMP_CLASS.equals(bundle.getClass().getCanonicalName())) {
      File cacheDir = new File(bundle.getBundleContext().getProperty(FRAMEWORK_STORAGE));
      retVal = findBundleCacheDir(bundle, cacheDir);
  }
  return retVal;

}

private File findBundleCacheDir(final Bundle bundle, File cacheDir)
{
File[] files = cacheDir.listFiles(new BundleLocationFilter(bundle));

  if(files == null || files.length != 1) {
      return null;
  }

  File[] subdirs = files[0].listFiles(new FileFilter() {
      @Override
      public boolean accept(File file)
      {
          return file.isDirectory() && file.getName().startsWith("version");
      }
  });

  if(subdirs == null || subdirs.length != 1) {
      return null;
  }
  return new File(subdirs[0] + File.separator + "bundle.jar");

}

@OverRide
public File getFileInBundle(Bundle bundle, String path) throws Exception
{
return DEFAULT.getFileInBundle(bundle, path);
}

@OverRide
public File[] locateJarsInsideBundle(Bundle bundle) throws Exception
{
return DEFAULT.locateJarsInsideBundle(bundle);
}

@OverRide
public Enumeration findEntries(Bundle bundle, String entryPath)
{
return DEFAULT.findEntries(bundle, entryPath);
}

}

package org.eclipse.jetty.osgi.boot.utils;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileFilter;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;

import org.osgi.framework.Bundle;

public class BundleLocationFilter implements FileFilter {

private static final String BUNDLE_LOCATION_FILENAME = "bundle.location";
private Bundle bundle;

BundleLocationFilter(Bundle bundle)
{
this.bundle = bundle;
}

@OverRide
public boolean accept(File file)
{
if(file.isDirectory()) {
File originalLocation = new File(file.getAbsolutePath() + File.separator + BUNDLE_LOCATION_FILENAME);
if(originalLocation.isFile()) {
try {
BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(originalLocation)));
String location = reader.readLine();
if(bundle.getLocation().equals(location.trim())) {
return true;
}
} catch (IOException e) {
return false;
}
}
}
return false;
}
}

thanks,
Caspar

On 2012-02-27 20:53:16 -0500, Hugues Malphettes wrote:

Hi there, thanks for filing this and writing the addition.

It is tempting to provide the functionality out of the box although I don't think we have the resources to actively test and maintain it.
As it is documented it should remain quite stable.

Let me review with the rest of the team.

One question: is not the method BundleLocationFilter.accept leaking file handles?

On 2012-02-28 04:40:41 -0500, Caspar MacRae wrote:

Hi Hugues,

RE: leaked handles - yes and potentially quite a few (cue redface), my only defense is it was hastily written to explore the problem (fixed below).

On one hand I think there's probably a sizable Felix & maven population, that have never deployed a bundle from a file:// url. But I quite understand your position wrt resource/maintenance/testing, especially given that this not the targeted runtime and there's already solutions such as PaxWeb.

thanks

@OverRide
public boolean accept(File file)
{
if(file.isDirectory()) {
File originalLocation = new File(file.getAbsolutePath() + File.separator + BUNDLE_LOCATION_FILENAME);
if(originalLocation.isFile()) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new InputStreamReader(new FileInputStream(originalLocation)));
String location = reader.readLine();
if(bundle.getLocation().equals(location.trim())) {
return true;
}
} catch (IOException e) {
return false;
} finally {
if(reader != null) {
try {
reader.close();
} catch (IOException e) {}
}
}
}
}
return false;
}

On 2012-02-28 05:21:43 -0500, Hugues Malphettes wrote:

(In reply to comment # 2)

Hi Hugues,

RE: leaked handles - yes and potentially quite a few (cue redface), my only
defense is it was hastily written to explore the problem (fixed below).
:) I did not mean to insist on that: It definitely looked like you know what you are doing.

On one hand I think there's probably a sizable Felix & maven population, that
have never deployed a bundle from a file:// url. But I quite understand your
position wrt resource/maintenance/testing, especially given that this not the
targeted runtime and there's already solutions such as PaxWeb.
OK writing a short email to the jetty-dev then.
Always happy to have more adopters anyways.
Cheers,
Hugues

thanks

On 2012-02-28 06:22:33 -0500, Caspar MacRae wrote:

Hi Hugues,

That's great thanks.

Still woefully embarrassed re: handle leaks =)

cheers,
Caspar

On 2012-02-29 03:13:42 -0500, Hugues Malphettes wrote:

Hi Caspar,

We got the nods from the team to commit this with jetty [1].

To support the IP process tools at eclipse, would you mind packaging the stages as an attachment and add a comment that you are the author of those attachments and are licensing them with EPL+ASL20?

Cheers.
Hugues
[1] http://dev.eclipse.org/mhonarc/lists/jetty-dev/msg01253.html

On 2012-02-29 14:08:17 -0500, Caspar MacRae wrote:

Created attachment 211832
Two classes with EPL license headers

On 2012-02-29 14:09:58 -0500, Caspar MacRae wrote:

Hi Hugues,

Wasn't sure of the correct header to add, losely followed some git/gerrit notes on Al Blue's blog. Attached as a tarball and added the following header to both classes:

/**

• http://www.eclipse.org/legal/epl-v10.html
• http://www.apache.org/licenses/LICENSE-2.0.html
  *
• I hereby assert that I authored 100% the content that I am contributing
• I hereby assert that I have the rights to donate the content to EPL / ASL20
• I hereby assert that I contribute the content under the EPL / ASL20
• @see https://bugs.eclipse.org/bugs/show_bug.cgi?id=372656
• @author Caspar MacRae
  */

If it's not ok, please point me to some documentation and I'll correct it.

cheers,
Caspar

On 2012-05-01 05:21:20 -0400, Jan Bartel wrote:

Caspar,

The headers on contributed files should follow this format:
http://eclipse.org/legal/copyrightandlicensenotice.php

Could you resubmit your attachments (with appropriate headers) as a patch to the jetty codebase (integrating the code from your FileLocatorHelperImpl with DefaultFileLocatorHelper IIUC) so we can apply it?

thanks,
Jan

On 2012-05-01 11:01:27 -0400, Jesse McConnell wrote:

also best to make a statement that you authored 100% of the code and you are free to contribute it, just to make sure the lawyers are happy :)

On 2012-05-02 04:34:47 -0400, Caspar MacRae wrote:

Hi Jan/Jesse,

The git links on http://wiki.eclipse.org/Jetty/Contributor/Building seem to be stale, specifically http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git - so took it from source of github mirror git://git.eclipse.org/gitroot/jetty/org.eclipse.jetty.project.git

I'll get this done tonight.

One thing to note with this approach; the zip file closed error https://bugs.eclipse.org/bugs/show_bug.cgi?id=364936 occurs, but the documented fix works perfectly false

cheers,
Caspar

On 2012-05-06 12:43:44 -0400, Caspar MacRae wrote:

Hi Jan/Jesse,

Apologies for not get this done yet, I'm now in Cuba for two weeks, I thought I'd be able to squeeze this in before I left - but got distracted writing a paxexam 1 test to demonstrate before/after patch.

I will absolutely get this submitted on my return - apologies again for the delay.

Best regards,
Caspar

On 2012-06-11 15:35:13 -0400, Dan Gravell wrote:

This is great work but I've noticed that it didn't work for me on Felix 4.0.2 (and I suspect on versions 3 and later). Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=382032 .

On 2012-06-12 09:41:07 -0400, Caspar MacRae wrote:

@Jan/@huges - apologies for the poor time management on this - I will get this sorted this weekend.

@dan, you are right, the documented cache behaviour was changed at some point in the 3.x line - this is an easy fix to accommodate both formats, but I don't like the fact that's it's undocumented.

I will attached an updated patch this weekend and chase this up on the Felix mailing list.

On 2012-06-18 07:20:19 -0400, Caspar MacRae wrote:

Hi,

I did some work on this yesterday, making changes to PaxExam tests to verify the cache access, but I also discovered a classloading issue using Jetty with Felix 4.x.

PaxExam:

The version of pax exam used (1.2.0) doesn't support later frameworks (the range for Felix ends at 2.0.1), version 2.x of PaxExam is more configurable allowing the framework(s) to be provided as a dependency.

I changed the two tests TestJettyOSGiBootCore and TestJettyOSGiBootWithJsp (marked @Ingore), and have the TestJettyOSGiBootCore working in PaxExam 2.4.0 with Equinox (3.6.0.v20100517, existing dependency version) and Felix (checked 2.0.1 and most of the 3.x line and 4.x).

Felix Cache:

The cache behaviour in Felix 3.x is consistent with the documentation (last release 3.2.2), AFAIK this only changed in 4.x, there's now a ticket raising the out-of-date documentation at https://issues.apache.org/jira/browse/FELIX-3561).

Felix 4.x classloading:

The current Jetty classloading for Felix is also affected for versions 4.x

org.eclipse.jetty.osgi.boot.utils.internal.DefaultBundleClassLoaderHelper#internalGetFelixBundleClassLoader(Bundle)
line 142 tries to get the field "m_modules" from org.apache.felix.framework.BundleImpl but throws an exception.

The field "m_modules" referred to a list of org.apache.felix.framework.resolver.Module - a class that no longer exists in Felix 4.0.x with the advent of org.osgi.framework.wiring.BundleRevision in OSGi 4.3

Should I include the fix for the DefaultBundleClassLoaderHelper#internalGetFelixBundleClassLoader(Bundle) in this patch or create a separate ticket? (I have an additional PaxExam test for this which ensures it works in Felix 3.x/4.x)

Jan/Huges/Jesse, I'm a little worried about scope creep here - though I've only touched two modules jetty-osgi-boot and test-jetty-osgi (I have separate branches for paxexam-2.4.0, this ticket and the Felix 4.x classloading issue). How would you like this to proceed?

thanks,
Caspar

On 2012-06-20 06:29:28 -0400, Dan Gravell wrote:

I've more bad news, and something that might want to be considered. When using the OBR project within Felix we get another different location URL String from the bundle again: "obr". Example url string:

obr://my.bundle/-1340186518508

Obviously this doesn't work either. I get:

java.lang.IllegalArgumentException: Unable to locate [jar file] inside unlocated bundle '[bundle name]'

I'm looking for ways of getting around this now... maybe providing my own file locator, so long as OBR provides some way of finding the filesystem location of the bundle.

migrated from Bugzilla #347102
status ASSIGNED severity enhancement in component osgi for 9.0.x
Reported in version 7.4.2 on platform All
Assigned to: Jan Bartel

On 2011-05-24 22:22:20 -0400, Hugues Malphettes wrote:

At the moment JAAS is documented for webapps. In the OSGi world, it would be nice to be able to associate a user realm to a set of servlet/filters registered on the HttpService.

Usecase the new example HttpServices expose the equinox console on-line.
The example configuration of jetty-osgi provided in the EclipseRTWebStarterKit should protect the access to the equinox console.
JAAS is the obvious choice.

migrated from Bugzilla #403632
status ASSIGNED severity enhancement in component maven for 9.0.x
Reported in version unspecified on platform PC
Assigned to: Jan Bartel

On 2013-03-18 09:49:06 -0400, Srgjan Srepfler wrote:

Given an jetty xml configuration declaring an war artifact
example:

> <plugin>
> <groupId>org.mortbay.jetty</groupId>
> <artifactId>jetty-maven-plugin</artifactId>
> <version>...</version>
> <configuration>
> <webAppConfig>
> <contextPath>/main-webapp-context</contextPath>
> </webAppConfig>
> <contextHandlers>
> <contextHandler implementation="org.eclipse.jetty.webapp.WebAppContext">
> <artifact>
> <groupId>thegroup</groupId>
> <artifactId>theartifact</artifactId>
> <version>0.1.0-SNAPSHOT</version>
> </artifact>
> <contextPath>/secondary-webapp-context</contextPath>
> </contextHandler>
> </contextHandlers>
> <connectors>
> <connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
> <port>9960</port>
> <maxIdleTime>60000</maxIdleTime>
> </connector>
> </connectors>
> <stopKey>foo</stopKey>
> <stopPort>9911</stopPort>
> </configuration>
> <executions>
> ...
> </executions>
> </plugin>

When the maven jetty plugin gets activated in the declared execution phases
Then the plugin should fetch the artifact from a repository (local or remote) and deploy it.

On 2013-03-18 09:49:41 -0400, Srgjan Srepfler wrote:

The advantage to this strategy is two fold.
One, the user doesn't need to know where the context sources/war are on the machine (one needs to put a path to a war or a directory structure via the usual contextHandler.
Two, the deployables doesn't even have to be on the machine itself.

A HTTP/2 preface may arrive at the server and end up being processed by the HttpConnection because the default protocol is http/1.1.

However, if the HTTP2CServerConnectionFactory is not configured for that server (this may happen for a TLS server, in case the client does not negotiate HTTP/2 via ALPN, but sends the HTTP/2 preface anyway), then Jetty enters a spin loop in HttpConnection: enter onFillable(), read, parse the HTTP/2 preface, upgrade fails, parser returns false, try to read more, buffer is not consumed, set fill interested, and onFillable() will be called again.

migrated from Bugzilla #329178
status ASSIGNED severity enhancement in component server for 7.1.x
Reported in version 8.0.0 on platform All
Assigned to: Jan Bartel

On 2010-11-01 03:25:28 -0400, Jan Bartel wrote nothing.
On 2010-11-01 03:28:14 -0400, Jan Bartel wrote:

Depends on bug # 329175 in the sense that in order to do the injection, you need to be able to specify the lookup= params to @resource.

The HTTP specification rfc7230 5.3 says that a request line has a target that is either:

request-target = origin-form
                    / absolute-form
                    / authority-form
                    / asterisk-form
origin-form    = absolute-path [ "?" query ]

so essentially it is either an absolute URI, a URI path, an authority or an asterisk.

However, HttpURI class treats a URI like //foo/bar as host=foo path=/bar, which is correct for URIs generally not not specifically for a HTTP target.

migrated from Bugzilla #398997
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 9.0.0 on platform All
Assigned to: Project Inbox

On 2013-01-24 12:24:24 -0500, Haralds Ulmanis wrote:

In java 7 it is possible to implement own file systems and when using Path - it is possible to reference folders/files in such.
Use cases: Files can be stored somewhere in databases and changed centralized on fly. That would add some freedom on multi-node site setups.

On 2013-01-24 17:34:23 -0500, Greg Wilkins wrote:

Jetty has a Resource abstraction that hides if the resource is a File or URL. It should be relatively easy to come up with a PathResource class that uses a Path file system as the backing store.

Unfortunately we are flat out getting 9 out the door without taking on such new functionality ourselves. However we would be very much interested in helping somebody contribute such a feature or sponsoring its development

On 2013-01-25 11:53:26 -0500, Haralds Ulmanis wrote:

It looks kind a simple actually.
I'll give a try next week.

On 2013-01-31 05:49:35 -0500, Haralds Ulmanis wrote:

So, i did simple implementation with Path. It works with standard file system where file:// is prefix. If we speak about custom FS with some other prefix like fs1:// etc. It does not work anymore .. URL complains about unknown protocol, Methods like:
makeTempDirectory(new File(System.getProperty("java.io.tmpdir")),context,true); also will not work. Even Path is wrapped with resource old java Methods does not work with it.

First probably I need to remove old io stuff and replcae with Files, Path etc., maybe diffetent implementation of Resource, replace URL with URI. It will take a more time that expected.

On 2013-01-31 06:45:15 -0500, Haralds Ulmanis wrote:

Btw, maybe someone have idea how to make unified resource.
What i see,
I did not find a straight way to use Path with URL. It means, that there should/can be two method sets (if we want to keep URL). One which will work with Path (any file system) and one which works with network resource URL.
Or ... implement filesystem with URL base. And then everything would work with Path. :)

On 2013-01-31 17:10:06 -0500, Greg Wilkins wrote:

I was thinking that you would make PathResource extend Resource and not URLResource, to avoid the issues with URL conflicts etc..... or are you saying it is some other URL that is complaining about unknown protocol.

Perhaps put you code up on github and we can both have a look?

On 2013-02-05 05:41:07 -0500, Haralds Ulmanis wrote:

I'll try shortly to describe there.
So We have Resource class which to extend, where i added static method
public static Resource newResource(Path path) throws IOException {
return new PathResource(path);
}
to support PathResource.

and
public class PathResource extends Resource {}

The problem is Resource method
public abstract URL getURL();
which I need to implement (not URI). And that method getURL is used inside other code, like:
XmlConfiguration xmlc = new XmlConfiguration(resource.getURL());
BufferedReader br = new BufferedReader(new InputStreamReader(r.addPath(path).getURL().openStream()));
etc.
So that method is used in many places in code. It will work fine with file, http etc. protocols which are supported by URL.

I've custom FS like:
public class CasFSProvider extends FileSystemProvider { ... }
with
@OverRide
public String getScheme() {
return "cas";
}

in general my uri looks like: cas:/path/path/file.ext
When I try to convert URI to URL, I got exception regarding unknown protocol.

What i think. To make it compatible in future with any kind of protocols (and custom ones), getURL probably needs to be replaced with general getURI.

Regards,
Haralds

On 2013-02-06 13:55:18 -0500, Haralds Ulmanis wrote:

I went through code and inspected .getURL uses.
The most common use is to resource.getURL() and then open it again with different method.. something like:
XmlConfiguration xmlc = new XmlConfiguration(resource.getURL());
->
public XmlConfiguration(URL configuration) throws SAXException, IOException
{
synchronized (__parser)
{
_url=configuration;
setConfig(__parser.parse(configuration.toString()));
_dtd=__parser.getDTD();
}
}
-> there is conversion configuration.toString

and .parse methods:
public synchronized Node parse(InputSource source) throws IOException, SAXException
public synchronized Node parse(String url) throws IOException, SAXException
public synchronized Node parse(File file) throws IOException, SAXException
public synchronized Node parse(InputStream in) throws IOException, SAXException

Actually if we have Resource abstraction then extra converts like .getUrl.toString is not needed.
We need to pass Resource as general resource. and in that case ... it would look like
XmlConfiguration xmlc = new XmlConfiguration(resource);

public XmlConfiguration(resource) throws SAXException, IOException{
....
setConfig(__parser.parse(resource)); or setConfig(__parser.parse(resource.getInputStream()))
....}
in case of resource ...
public synchronized Node parse(Resource resource) throws IOException, SAXException {
return parse(resource.getInputStream); }

Not sure when, but i could try to set up workspace and try just to remove .getURL and rewrite places where it is used, rather than doing full scale redesign of Resource as it is now.

On 2013-02-07 14:29:17 -0500, Haralds Ulmanis wrote:

It will take more time than I though initially.
as this:
_classLoader=new URLClassLoader(paths);
will not work .. and there is no such URI class loader.
And other implementations (URIClassLoader) I found already, takes URI and converts to URL. So it means probably there is a need to write new ClassLoader.

On 2013-11-28 20:16:31 -0500, Jan Bartel wrote:

Haralds,

Sounds like you needed to add a URLStreamHandler for the cas:// protocol.

See http://docs.oracle.com/javase/7/docs/api/java/net/URL.html#URL%28java.lang.String,%20java.lang.String,%20int,%20java.lang.String%29

Jan

(In reply to Haralds Ulmanis from comment # 6)

I'll try shortly to describe there.
So We have Resource class which to extend, where i added static method
public static Resource newResource(Path path) throws IOException {
return new PathResource(path);
}
to support PathResource.

and
public class PathResource extends Resource {}

The problem is Resource method
public abstract URL getURL();
which I need to implement (not URI). And that method getURL is used inside
other code, like:
XmlConfiguration xmlc = new XmlConfiguration(resource.getURL());
BufferedReader br = new BufferedReader(new
InputStreamReader(r.addPath(path).getURL().openStream()));
etc.
So that method is used in many places in code. It will work fine with file,
http etc. protocols which are supported by URL.

I've custom FS like:
public class CasFSProvider extends FileSystemProvider { ... }
with
@OverRide
public String getScheme() {
return "cas";
}

in general my uri looks like: cas:/path/path/file.ext
When I try to convert URI to URL, I got exception regarding unknown protocol.

What i think. To make it compatible in future with any kind of protocols
(and custom ones), getURL probably needs to be replaced with general getURI.

Regards,
Haralds

migrated from Bugzilla #404278
status ASSIGNED severity normal in component server for 9.0.x
Reported in version 8.1.8 on platform PC
Assigned to: Project Inbox

On 2013-03-25 11:46:11 -0400, Joe Fago wrote:

In our production environment, even under moderate load, there are system cpu spikes that generally last 1-5 minutes. Running an strace shows the following:

[pid 27153] write(171, "\1", 1) = 1
[pid 27153] read(170, "\1", 128) = 1
[pid 27153] write(171, "\1", 1) = 1
[pid 27153] read(170, "\1", 128) = 1
[pid 27153] write(171, "\1", 1) = 1
[pid 27153] read(170, "\1", 128) = 1
[pid 27153] write(171, "\1", 1) = 1
[pid 27153] read(170, "\1", 128) = 1

read/write pattern repeats 11,000+ times in 10s. File descriptors 170/171 are the read/write ends of a pipe, not a socket.

lr-x------ 1 root root 64 Mar 23 03:40 170 -> pipe:[15520976]
l-wx------ 1 root root 64 Mar 23 03:40 171 -> pipe:[15520976]

Note that the same thread is continuously writing and reading a single byte (value = 1). The jstack output shows this for thread 27153:

Thread 27153: (state = IN_NATIVE)

• sun.nio.ch.EPollArrayWrapper.interrupt(int) @bci=0 (Compiled frame; information may be imprecise)
• sun.nio.ch.EPollArrayWrapper.interrupt() @bci=4, line=256 (Compiled frame)
• sun.nio.ch.EPollSelectorImpl.wakeup() @bci=18, line=175 (Compiled frame)
• org.eclipse.jetty.io.nio.SelectorManager$SelectSet.wakeup() @bci=10, line=822 (Compiled frame)
• org.eclipse.jetty.io.nio.SelectChannelEndPoint.updateKey() @bci=215, line=539 (Compiled frame)
• org.eclipse.jetty.io.nio.SelectChannelEndPoint.schedule() @bci=117, line=173 (Compiled frame)
• org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect() @bci=739, line=619 (Compiled frame)
• org.eclipse.jetty.io.nio.SelectorManager$1.run() @bci=181, line=290 (Compiled frame)
• org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable) @bci=1, line=608 (Interpreted frame)
• org.eclipse.jetty.util.thread.QueuedThreadPool$3.run() @bci=47, line=543 (Interpreted frame)
• java.lang.Thread.run() @bci=11, line=662 (Interpreted frame)

I also see evidence of thread SEGfaults in the strace output - usually after several thousand read/write single-byte repetitions. The thread gets respawned and continues this read/write behaviour.

[pid 27153] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 27153] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

We are running the 1.6 Oracle jvm on Redhat.
OS/JVM/Jetty versions:

Red Hat Enterprise Linux Server release 5.8 (Tikanga)

java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01, mixed mode)

jetty-8.1.8.v20121106 - 06 November 2012

Let me know if there is any more information I can provide. Still digging through logs for more info, but hoping this looks like a known issue.

On 2013-03-25 17:31:22 -0400, Greg Wilkins wrote:

My first guess is that this looks like a JVM bug or at least weirdness. Jetty does not use pipes, so I assume this is part of the implementation of the NIO selector? Hence the EPollXxxx in the stack trace. Also SEGV's imply a JVM problem rather than a Jetty problem.

It would be interesting to know how far out of that stack the thread gets. Is it repeatedly calling updateKey, or is it looping within there or is it looping within EPoll etc?

Your JVM looks recent-ish, although there is a _41 out I think. You could also try java 7

So unfortunately this is not a known issue.

migrated from Bugzilla #398468
status ASSIGNED severity enhancement in component servlet-3.1 for 9.0.1
Reported in version 9.0.0 on platform PC
Assigned to: Project Inbox

On 2013-01-18 00:51:33 -0500, Jan Bartel wrote:

See pg. 2-20 of 3.1 spec for details.

On 2013-06-24 00:38:06 -0400, Greg Wilkins wrote:

Not intended to support in the initial release

migrated from Bugzilla #411104
status ASSIGNED severity major in component server for 9.0.x
Reported in version 9.0.2 on platform PC
Assigned to: Greg Wilkins

On 2013-06-19 06:41:22 -0400, Samuel Fung wrote:

I have a keystore containing many key-pairs. I set the following in jetty-ssl.xml (choosing 1 key-pair):

.. ... ... ...

I've verified several times that the settings are correct, but Jetty keeps throwing this exception:

java.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(KeyProtector.java:328)
at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:138)
at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:55)
at java.security.KeyStore.getKey(KeyStore.java:792)
at sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:131)
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:68)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:259)
at org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:903)
at org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:296)
...

I trace to SslContextFactory.java:903
keyManagerFactory.init(keyStore,_keyManagerPassword == null?(_keyStorePassword == null?null:_keyStorePassword.toString().toCharArray()):_keyManagerPassword.toString().toCharArray());

_keyManagerPassword (corresponds to keytool genkeypair -keypass option)
and
_keyStorePassword (corresponds to keytool genkeypair -storepass option)
are 2 different passwords, they must not be used interchangeably like the above statement.

migrated from Bugzilla #403119
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 7.4.5 on platform All
Assigned to: Jan Bartel

Original attachment names and IDs:

• jaas_role_osgi.diff (ID 228309)

On 2013-03-12 16:26:05 -0400, metatech wrote:

Created attachment 228309
jaas_role_osgi

Jetty JAASLoginService.getGroups() contains some logic to filter JAAS role principals from JAAS user principals.
For that purpose, it tries to load all "role class names" with the "context class loader", which unfortunately has different semantics under OSGi than in a regular Java EE application server.
This can cause ClassNotFoundException when trying to load the class.

The proposed solution is to retrieve all principals from the subject and compare the type hierarchy of each object's class (+ all super-classes and their implemented interfaces) to the list of "role class names" configured in Jetty.
This makes it OSGi-friendly.

Please see implementation in attachment.
Tested under Jetty 7.4.5 within ServiceMix 4.4.2.

java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.karaf.jaas.modules.RolePrincipal not found by mycomponent [204]
at org.eclipse.jetty.plus.jaas.JAASLoginService.getGroups(JAASLoginService.java:279)[58:org.eclipse.jetty.plus:7.4.5.v20110725]
at org.eclipse.jetty.plus.jaas.JAASLoginService.login(JAASLoginService.java:209)[58:org.eclipse.jetty.plus:7.4.5.v20110725]
Caused by: java.lang.ClassNotFoundException: org.apache.karaf.jaas.modules.RolePrincipal not found by mycomponent [204]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)[org.apache.felix.framework-3.0.9.jar:]
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)[org.apache.felix.framework-3.0.9.jar:]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)[org.apache.felix.framework-3.0.9.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_35]
at org.eclipse.jetty.plus.jaas.JAASLoginService.getGroups(JAASLoginService.java:267)[58:org.eclipse.jetty.plus:7.4.5.v20110725]
... 18 more

Thanks.

On 2013-03-27 19:42:51 -0400, Jan Bartel wrote:

metatech,

Firstly, jetty-7.4.5 is really old now, and the impl of the OSGi infrastructure has changed significantly in jetty-8 and jetty-9. Could you please try your test app under at least the latest jetty-8 (but preferably 9) and report if the problem still exists?

If it does, can you provide a small project that demonstrates it please? I'd like to see the manifests of your bundles to understand how you're deploying jetty and your webapp and karaf. If karaf is external to your webapp bundle, then have you declared an import for those classes in the manifest of the bundle of your webapp?? I'm not denying that there could be an issue with the loading of role classes under OSGi, but I need to see a non-working example to be sure that if there is a problem, we fix it the right way.

thanks
Jan

On 2013-03-29 07:06:43 -0400, metatech wrote:

Hi Jan,
Thanks for your answer.
I understand your request to have a stand-alone project which reproduces the problem. Unfortunately, we did extensive customization the software stack we use (based on ServiceMix 4.4.2), so I think it will require significant time for me to produce it, which I do not have in the short term.
A small enhancement that would help us override the default JAASLoginService without patching the Jetty JAR is to convert the method "getGroups" from "private" to "protected".
When I have some time, I will try to create a test project.

migrated from Bugzilla #318264
status ASSIGNED severity enhancement in component server for 7.1.x
Reported in version 7.1.0 on platform All
Assigned to: Project Inbox

On 2010-06-28 20:21:59 -0400, Greg Wilkins wrote:

The stats handler should measure the ave,max and stddev of the time from when the request is first received by the connector until the time it is first seen by the stats handler.

It currently has the request timestamp, so it has this information available.

However, there is a small complication. The request.setTimestamp(long) method is called in two places:

HttpConnection$RequestHandler.startRequest - when the request line is first parsed.

HttpConnection.handleRequest -> Connection.customizeRequest - which is called after the request is dispatched.

I think the second of these should be removed, as it will only be nano seconds before the request is handed to the stats server.

The first of these is after the request is dispatched, but then all handling in Jetty is dispatched - so it will do for now... perhaps we can eventually replace it with a timestamp set on the endpoint representing the last dispatched time. Or maybe we have both?

migrated from Bugzilla #412719
status ASSIGNED severity minor in component server for 9.0.x
Reported in version 9.0.3 on platform All
Assigned to: Jan Bartel

On 2013-07-10 18:00:40 -0400, Joakim Erdfelt wrote:

The webapp configuration process should collect all of the various configuration errors and exceptions together and report them all before failing the deployment of the webapp.

Such as bad entries in the web.xml or
Annotation scanning errors (such as bad expectations when an annotation is encountered)

Ideally, these errors should be ...

• Reported to logging
• Captured internally for reporting to JMX

I see something like a DeployErrorListener or DeployListener that could be configured via the DeploymentManager, which adds it to the WebAppContext before starting/configuring it.

On 2013-07-10 18:01:02 -0400, Joakim Erdfelt wrote:

Assigned to Jan

On 2013-07-10 18:01:46 -0400, Joakim Erdfelt wrote:

Idea / Brainstorming.

If we use the DeployListener approach, then the default implementation simply logs the errors via the Jetty Logger.

migrated from Bugzilla #412983
status ASSIGNED severity major in component server for 9.0.x
Reported in version 9.0.3 on platform PC
Assigned to: Simone Bordet

Original attachment names and IDs:

• __Test_Jetty9ClientAuthBug.java (ID 233480)
• ssl_cneeded_debug.txt (ID 233481)
• jetty9_bugtrace.pcap (ID 233482)
• ssl_jetty9.1.x.txt (ID 233692)

On 2013-07-15 10:50:44 -0400, Lothar Kimmeringer wrote:

Created attachment 233480
JUnit-Testcase to reproduce the problem

Before finding the register-button for Bugzilla I already described the problem in http://dev.eclipse.org/mhonarc/lists/jetty-users/msg03542.html

Here is the mail again:

I'm currenty doing a migration from Jetty 7 to Jetty 9 and
run into problems when setting up an SSL-server with and without
needed client certificates. The problems are similar to the
mail at http://dev.eclipse.org/mhonarc/lists/jetty-users/msg03102.html
but it goes farther.

[...]

The problem is that the server doesn't generate SSL-Alerts leaving
the client in a socket.read() until that client is running into a
timeout (which might be never in dependence on how the socket is
created). The closing of the endpoint in oej.io.ssl.SslConnection
doesn't seem to have any effect. Until there is a garbage collector
run the socket stays open. Sooner or later (on low-traffic systems
expect it to be the latter) the sockets are closed, so at least
you shouldn't be able to construct a DoS-attack with this.

To reproduce the problem I created a JUnit-testcase that allows
an easy reproduction of the problem. As well you can see another
problem occuring if you comment out lines 249-252 leading to the
effect that the server get no server-certificates for the connection.
In that case testSslStandardConnection will also end in a read
timeout (in that case after two minutes).

In addition to that I added the Wireshark-trace of the second
test showing that no SSL-Alert is sent to the client and that
the connection is only closed after the client ran into the timeout.
Don't get confused by the IPs being involved. I ran a TCP-gateway
on a second computer to be able to capture the packets, since
this doesn't work here on the loopback device.

If this bug-report is better sent to jetty-dev, just tell me
JVM being used for the test is JDK 1.7.0_21 on Windows 32 Bit.
The testcase uses BouncyCastle for the creation of the certificates
the server should use. The testcase sets its own KeyStore,
KeyManager and TrustManager, so you don't need to create
file-based KeyStores before starting the test.

This bug stopped our migration, so a fix is highly appreciated

Best regards,

Lothar Kimmeringer

On 2013-07-15 10:51:38 -0400, Lothar Kimmeringer wrote:

Created attachment 233481
Debug-Output when running the testcase

On 2013-07-15 10:52:47 -0400, Lothar Kimmeringer wrote:

Created attachment 233482
Wireshark-Trace showing the ssl-handshake with needClientAuth==true

On 2013-07-18 23:45:34 -0400, Greg Wilkins wrote:

Lothar,

I've made some SSL changes in the 9.1 branch and am wondering if these may have fixed it already.

If you get a chance to try 9.1 before I get a chance to try your unit test, that would be great!

cheers

On 2013-07-19 04:43:16 -0400, Lothar Kimmeringer wrote:

If you have a jar, containing the jetty-classes I can do it. Setting it up with direct access to the repository would take too much time here at the moment.

On 2013-07-22 09:40:13 -0400, Greg Wilkins wrote:

Lothar,

try this distro:

https://oss.sonatype.org/content/groups/jetty-with-staging/org/eclipse/jetty/jetty-distribution/9.1.0-SNAPSHOT/

On 2013-07-23 03:48:48 -0400, Lothar Kimmeringer wrote:

(In reply to comment # 5)

try this distro:
[...]

I tried and have the same effect as with 9.0.3. I will attach the debug-output of my test.

On 2013-07-23 03:50:05 -0400, Lothar Kimmeringer wrote:

Created attachment 233692
Debug-Output when running the testcase with Jetty jetty-9.1.0-SNAPSHOT

On 2013-07-29 10:46:19 -0400, Lothar Kimmeringer wrote:

When replacing the catch-blocks in SslConnection (line 632ff) to the following:

catch (Exception e)
{
    EndPoint ep = getEndPoint();
    try{
        if (e instanceof SSLHandshakeException){
            byte[] data = new byte[]{
                    0x15, 0x03, 0x01, 0x00, 0x02, 0x02, 40
            };
            ep.flush(ByteBuffer.wrap(data));
        }
        if (e instanceof SSLException){
            throw new EofException(e);
        }
    }
    finally{
        ep.close();
    }
    throw e;
}

the client gets an SSLHandshakeException as expected and is no longer running into a timeout. But I see that more as a hack than a fix so I don't add this as a patch, more as a base for discussion ;-)

On 2015-01-03 09:04:47 -0500, Thomas Lu�nig wrote:

Hi,

while i try to get an A+ rating at SSL Labs with TLS_FALLBACK_SCSV.
(https://fweimer.fedorapeople.org/openjdk/tls-fallback-scsv/jdk.patch)
This patch can also be used with JDK8 :-)
I found that jetty missed to transmit the ssl alert message.
The correct fix is not to send and fixed alert message but to check the handshakeStatus and send (flush)
the rest protocol data to the socket.

Package: org.eclipse.jetty.io.ssl
Class SslConnection
Method: int fill(final ByteBuffer buffer);

Change the catch block ad the method end to:

} catch (final Throwable e) {
SslConnection.this._encryptedInput.clear();
if(SslConnection.this._sslEngine.getHandshakeStatus()==HandshakeStatus.NEED_WRAP) { flush(__FILL_CALLED_FLUSH); }
getEndPoint().close();
throw e;
} finally {

migrated from Bugzilla #353817
status ASSIGNED severity enhancement in component server for 7.5.x
Reported in version 7.4.0 on platform All
Assigned to: Project Inbox

On 2011-08-03 15:25:45 -0400, Michael Gorovoy wrote:

Originally created as http://jira.codehaus.org/browse/JETTY-1384 by Nick Nygaard ([email protected])

Classloader for applet cannot find main class, if any library is pack200 packed (pack.gz) and applet requests server for pack200 files:

...

Even if only a dependency library is packed with pack200, the main class cannot be found.

Is content encoding correct when client receives packed jars: content-encoding=pack200-gzip?

The code works in another Java container.

On 2011-09-20 13:43:04 -0400, Joakim Erdfelt wrote:

Lowering priority

migrated from Bugzilla #346819
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 7.4.2 on platform All
Assigned to: Project Inbox

On 2011-05-22 23:42:53 -0400, Greg Wilkins wrote:

http://www.tomcatexpert.com/blog/2011/05/18/crawler-session-manager-valve

migrated from Bugzilla #419191
status ASSIGNED severity normal in component server for 9.1.x
Reported in version 8.1.13 on platform All
Assigned to: Greg Wilkins

On 2013-10-10 22:00:15 -0400, xzer lr wrote:

At first, the background is that we using a shell to login into the
remote server and restart the jetty service on the remote server by
ssh, it works well until the version 8.1.8.

Then, we decided to upgrade our jetty distributions to the newest
8.1.13, as a test result, we found that the startJetty.sh will hang up
the remote ssh session.

I dug the new startJetty.sh and found that it will not use
start-stop-daemon to start jetty process when the current user is not
root. I tried to study the commit logs, then I found the commit
(commit id:SHA: 38d7017)
for bug[403281]: "jetty.sh waits for started before OK".

##################################################

Setup JAVA if unset

@@ -407,23 +428,15 @@ case "$ACTION" in
exit
fi

• if type start-stop-daemon > /dev/null 2>&1
• if [ $UID -eq 0 ] && type start-stop-daemon > /dev/null 2>&1
  then
  unset CH_USER
  if [ -n "$JETTY_USER" ]
  then
  CH_USER="-c$JETTY_USER"
  fi

•  if start-stop-daemon -S -p"$JETTY_PID" $CH_USER -d"$JETTY_HOME" -b -m -a "$JAVA" -- "${RUN_ARGS[@]}" --daemon
  

•  then
  

•    sleep 1
  

•    if running "$JETTY_PID"
  

•    then
  

•      echo "OK"
  

•    else
  

•      echo "FAILED"
  

•    fi
  

•  fi
  

•  start-stop-daemon -S -p"$JETTY_PID" $CH_USER -d"$JETTY_HOME" -b -m -a "$JAVA" -- "${RUN_ARGS[@]}" --daemon
  

Then I checked the bug ticket too: https://bugs.eclipse.org/bugs/show_bug.cgi?id=403281,
but there seems be nothing about the root user check.

On 2013-10-13 22:54:25 -0400, Greg Wilkins wrote:

start-stop-daemon is intended for system processes, hence we added that test.

Can you explain what you mean by "hang up the remote ssh session"?

The alternative to start-stop-daemon does a disown of the process, so it should be running correctly in the background.

On 2013-10-14 21:36:04 -0400, xzer lr wrote:

sorry, it seems that I missed typing some words in my description.

we are using a shell script to login into the remote server automatically and restart the jetty server on the remote server by the following command:

ssh [email protected] 'jetty.sh restart'

since the 'someuser' is not root, your new jetty.sh will not start jetty by start-stop-daemon, hence the ssh session will catch the sysout and syserr from jetty process then hang up to wait the jetty process to finish.

migrated from Bugzilla #382032
status ASSIGNED severity normal in component osgi for 7.6.x
Reported in version unspecified on platform PC
Assigned to: Jan Bartel

On 2012-06-07 13:20:10 -0400, Dan Gravell wrote:

Build Identifier:

This is Jetty 7.6.1.

I have followed the instructions (http://wiki.eclipse.org/Jetty/Feature/Jetty_OSGi) to create an OSGI bundle that, when started, both registers a Server and WebAppContext Service. Here's my code for the latter:

WebAppContext blissUiContextHandler = new WebAppContext();
Dictionary blissUiProps = new Hashtable();
blissUiProps.put(OSGiWebappConstants.SERVICE_PROP_WAR,"target/classes");
blissUiProps.put(OSGiServerConstants.MANAGED_JETTY_SERVER_NAME, serverName);
context.registerService(ContextHandler.class.getName(),blissUiContextHandler,blissUiProps);

Notice that the 'target/classes' folder is specified as the location for the WAR structure inside my bundle.

At development time, running in the Eclipse OSGi runner, this works fine. All the code for the web app goes into target/classes and it all works nicely.

At runtime, within Felix, it doesn't work. Here's what I get in way of output:

2012-06-07 18:02:32.700:WARN:oejobis.DefaultJettyAtJettyHomeHelper:No default jetty started.
2012-06-07 18:02:32.784:INFO:oejs.Server:jetty-7.6.1.v20120215
2012-06-07 18:02:32.802:INFO:oejdp.ScanningAppProvider:Deployment monitor /home/gravelld/eclipse-workspaces/bliss/com.elsten.bliss.installer/release/xyz at interval 10
2012-06-07 18:02:32.815:INFO:oejs.AbstractConnector:Started [email protected]:3220
2012-06-07 18:02:59.687:INFO:oejd.DeploymentManager:Deployable added: com.elsten.bliss.ui-1.0.0.0/target/classes
2012-06-07 18:02:59.694:INFO:oejw.WebInfConfiguration:Extract bundle://10.0:0/target/classes/ to /tmp/jetty-0.0.0.0-3220-classes--any-/webapp
2012-06-07 18:02:59.733:INFO:oejw.StandardDescriptorProcessor:NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
2012-06-07 18:02:59.745:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{/,file:/tmp/jetty-0.0.0.0-3220-classes--any-/webapp/},bundle://10.0:0/target/classes/

If I attempt to access the server I get a blank directory listing.

Note that /tmp/jetty-0.0.0.0-3220-classes-_-any-/webapp is empty.

I stepped through this with a debugger particularly looking at WebBundleDeployerHelper. This returns the location of the web app as bundle://10.0:0/target/classes/, whereas at runtime this is a file:// url which can be seen to exist (I don't know how the resolution of felix bundle:// URLs work although I note you have some code for this.

I inspected the bundle JAR by hand. The target/classes folder is there, fully populated, and is including in Bundle-Classpath.

Are there any workarounds? Am I initialising the WebAppContext in the wrong way?

Reproducible: Always

On 2012-06-07 21:49:49 -0400, Hugues Malphettes wrote:

Hi Dan,
It looks like the support for locating java.io.File in Felix is lagging.
You can provide your own implementation of org.eclipse.jetty.osgi.boot.utils.BundleFileLocatorHelper:

org.eclipse.jetty.osgi.boot.utils.BundleFileLocatorHelper.DEFAULT = felixAbleBundleFileLocatorHelper;

If you would consider contributing it back we would be interested.
Let us know how it goes.

On 2012-06-07 21:53:52 -0400, Hugues Malphettes wrote:

Hum, it looks like it was already solved by Caspar here: bug 372656.

On 2012-06-08 04:11:57 -0400, Dan Gravell wrote:

Thanks, I'll try that out.

On 2012-06-11 15:34:09 -0400, Dan Gravell wrote:

I took a look at this today. It took a little more work than expected to get it working, I suspect because that code was for a version of Felix before v3. Felix is ATM at 4.0.2.

I installed Casper's code (with his change in BundleLocationFilter.accept) but for me the first line in FileLocatorHelperImpl worked every time:

File retVal = DEFAULT.getBundleInstallLocation(bundle);

retVal always returned a file:// URL to the original location of the bundle (not the cache). And I assume this was still incorrect.

I disabled this line to force Casper's code to run. But the cache was never found because it relies on a bundle.location being present. It seems that since v3 of Felix the bundle data has been consolidated in "bundle.info". So I changed that to check bundle.info (I just do a readLine twice... this is probably slow / prone to error).

Put another way, http://felix.apache.org/site/apache-felix-framework-bundle-cache.html seems to be waaaaay out of date.

That wasn't all though. Initially I had the SERVICE_PROP_WAR set to a sub directory of the bundle JAR ("target/classes"). This was correctly built into the bundle JAR file but I remembered that I had this working previously with a built JAR/WAR embedded within the bundle JAR. So I changed the build to that (I'm using PDE build in Eclipse) and that worked.

Maybe you should consider this Felix versioning issue before accepting this code? Or at least adding some comments/documentation, because I don't think this will work for Felix 3+.

Here's my revised version of Casper's code. I'd welcome your comments as to improvements, because it would also be great if we could incorporate this into Jetty.

package org.eclipse.jetty.osgi.boot.utils;

import static org.osgi.framework.Constants.FRAMEWORK_STORAGE;

import java.io.File;
import java.io.FileFilter;
import java.net.URL;
import java.util.Enumeration;

import org.osgi.framework.Bundle;

public class FileLocatorHelperImpl implements BundleFileLocatorHelper {

private static final String FELIX_BUNDLE_IMP_CLASS =

"org.apache.felix.framework.BundleImpl";

@Override
public File getBundleInstallLocation(Bundle bundle) throws Exception
{
    File retVal = DEFAULT.getBundleInstallLocation(bundle);

    if(FELIX_BUNDLE_IMP_CLASS.equals(bundle.getClass().getCanonicalName())) {
        File cacheDir = new

File(bundle.getBundleContext().getProperty(FRAMEWORK_STORAGE));
retVal = findBundleCacheDir(bundle, cacheDir);
}
return retVal;
}

private File findBundleCacheDir(final Bundle bundle, File cacheDir)
{
    File[] files = cacheDir.listFiles(new BundleLocationFilter(bundle));

    if(files == null || files.length != 1) {
        return null;
    }

    File[] subdirs = files[0].listFiles(new FileFilter() {
        @Override
        public boolean accept(File file)
        {
            return file.isDirectory() &&

file.getName().startsWith("version");
}
});

    if(subdirs == null || subdirs.length != 1) {
        return null;
    }
    return new File(subdirs[0] + File.separator + "bundle.jar");
}


@Override
public File getFileInBundle(Bundle bundle, String path) throws Exception
{
    return DEFAULT.getFileInBundle(bundle, path);
}


@Override
public File[] locateJarsInsideBundle(Bundle bundle) throws Exception
{
    return DEFAULT.locateJarsInsideBundle(bundle);
}


@Override
public Enumeration<URL> findEntries(Bundle bundle, String entryPath)
{
    return DEFAULT.findEntries(bundle, entryPath);
}

}

package org.eclipse.jetty.osgi.boot.utils;

import java.io.BufferedReader;
import java.io.File;
import java.io.FileFilter;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;

import org.osgi.framework.Bundle;

public class BundleLocationFilter implements FileFilter {

private static final String BUNDLE_LOCATION_FILENAME = "bundle.info";
private Bundle bundle;

BundleLocationFilter(Bundle bundle)
{
    this.bundle = bundle;
}

@Override
public boolean accept(File file)
{
    if(file.isDirectory()) {
        File originalLocation = new File(file.getAbsolutePath() +

File.separator + BUNDLE_LOCATION_FILENAME);
if(originalLocation.isFile()) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new InputStreamReader(new
FileInputStream(originalLocation)));
String id = reader.readLine();
String location = reader.readLine();
if(bundle.getLocation().equals(location.trim())) {
return true;
}
} catch (IOException e) {
return false;
} finally {
if(reader != null) {
try {
reader.close();
} catch (IOException e) {}
}
}
}
}
return false;
}
}

Obvious issues:

• That code does a DEFAULT.getBundleInstallLocation(bundle) and that then gets ignored
• 2x readLines may not be optimal
• We're still reliant on an unpublished standard

On 2012-06-12 05:30:53 -0400, Dan Gravell wrote:

Additionally, I just found out that I don't even need Caspar's patch if I use an embedded JAR. So I suppose this bug is just about finding folder level resources (which are a valid WAR structure) in a bundle.

On 2012-06-12 20:40:54 -0400, Hugues Malphettes wrote:

(In reply to comment # 5)

Additionally, I just found out that I don't even need Caspar's patch if I use
an embedded JAR. So I suppose this bug is just about finding folder level
resources (which are a valid WAR structure) in a bundle.

That sounds like a good workaround.
Keep us updated.

On 2012-06-13 05:30:12 -0400, Dan Gravell wrote:

Everything appears to work fine with the embedded JAR. As far as my own application is concerned I am happy with that, although I think it's still an issue that needs to be addressed in the Jetty/Felix interaction, no?

Better still, shouldn't this be spec'd in the OSGi spec so you don't have to do the horrible URL introspection?

On 2012-06-15 03:03:33 -0400, Hugues Malphettes wrote:

(In reply to comment # 7)

Everything appears to work fine with the embedded JAR. As far as my own
application is concerned I am happy with that, although I think it's still an
issue that needs to be addressed in the Jetty/Felix interaction, no?
Yes it remains an issue.

Better still, shouldn't this be spec'd in the OSGi spec so you don't have to do
the horrible URL introspection?
Yes it is most horrible. There is no standard API to access the file system in OSGi as far as I know. Unless the OSGi spec was updated in this regard in the last year.
My naive understanding is that OSGi does not map the bundles resources to a filesystem; in order to support transparent distributed services or very small or very constrained installations.

Let us know if there is now a none proprietary API in OSGi to access the filesystem.

On 2012-06-15 05:15:05 -0400, Dan Gravell wrote:

Yeah, you're right, I wasn't thinking. By specifying a folder as the web app path I'm implying a file system. Instead, if I specify a URL to a resource with WAR structure which is in the Bundle-Classpath I guess everything just works by virtue of the OSGi classloading.

If this is true, in many ways you could see an argument for completely withdrawing support for folder locations as it's not 'OSGi' enough. However, I hope you don't because it would make development time work extremely cumbersome.

On 2012-06-15 05:56:30 -0400, Hugues Malphettes wrote:

(In reply to comment # 9)

Yeah, you're right, I wasn't thinking. By specifying a folder as the web app
path I'm implying a file system. Instead, if I specify a URL to a resource with
WAR structure which is in the Bundle-Classpath I guess everything just works by
virtue of the OSGi classloading.

If this is true, in many ways you could see an argument for completely
withdrawing support for folder locations as it's not 'OSGi' enough. However, I
hope you don't because it would make development time work extremely
cumbersome.
All my projects do want a file system returned and do many web frameworks that just won't work if the webapp is not unzipped: not anywhere near removing it.

It is here:
javax.servlet.ServletContext#getRealPath(java.lang.String)
And it won't return null in OSGi thanks to this ugly introspection.
Virgo uses a fragment specific to equinox or felix if I remember well.

On 2012-06-15 07:47:26 -0400, Dan Gravell wrote:

Cool, well thanks for your insights. I suppose, then, this remains open until Felix is supported.

On 2013-10-23 20:26:03 -0400, Jan Bartel wrote:

Hi Dan,

Sorry this issue has been open a while.

Do you know if this has actually been fixed? Our unit tests use felix 3.2.2 and 4.0.2 and it seems to work ... however, as its actually running inside eclipse I'm not confident that it would be the same as running in a standalone osgi container.

Could you possibly test this with the most recent version of jetty (something like 9.1.0.RC0) and report if this is still a problem or not?

thanks,
Jan

On 2013-10-24 03:40:11 -0400, Dan Gravell wrote:

I can try... I'm pretty sure you need to run it standalone though. If you run it in Eclipse then the Equinox URL handling for bundles will take over, which will mean it will work.

On 2014-09-19 03:14:51 -0400, Jan Bartel wrote:

Hi Dan,

Well its been a while ... where are we at with this bug? The jetty osgi code has undergone some major revisions in the interim. I've also tested jetty-2.4-SNAPSHOT with felix 4.4.1 and webapps deployed as bundles are working fine.

After all the back-and-forth on this issue, can we restate the original actual problem? Is it that you can't deploy a webapp as a packed bundle where the webapp base directory is expressed as a location relative to the root of the bundle itself?

thanks
Jan

(In reply to Dan Gravell from comment # 13)

I can try... I'm pretty sure you need to run it standalone though. If you
run it in Eclipse then the Equinox URL handling for bundles will take over,
which will mean it will work.

On 2014-11-05 14:46:56 -0500, Dan Gravell wrote:

Yes, that's right. My bundle activator was starting a Jetty instance, but the path I was specifying as OSGiWebappConstants.SERVICE_PROP_WAR, which contained a bunch of files in the standard WAR structure, was not being found.

It appeared that the OOTB behaviour just did not cater for Felix. Maybe it does now?

Personally, I continue to use the workaround detailed above.

On 2014-11-06 00:12:51 -0500, Jan Bartel wrote:

Hi Dan,

(In reply to Dan Gravell from comment # 15)

Yes, that's right. My bundle activator was starting a Jetty instance, but
the path I was specifying as OSGiWebappConstants.SERVICE_PROP_WAR, which
contained a bunch of files in the standard WAR structure, was not being
found.

Thanks for the confirmation of the situation.

It appeared that the OOTB behaviour just did not cater for Felix. Maybe it
does now?

Nope, your particular use-case (webapp as directory inside bundle) does not work.

Personally, I continue to use the workaround detailed above.

The workaround of using a webapp as a packed war embedded into the bundle I can confirm is working, so if its working for you, I suggest you keep using it for a while.

It seems to be problematic to obtain the location of the cached felix bundle, rather than the location of the bundle that was deployed.

Bundle.getLocation() on felix returns the original location of the bundle that was deployed, not the cached location. Reading your previous postings of your and Caspar's efforts to obtain the cached location, and consulting the felix source, plus observing the cache when deploying different configurations of bundles, my conclusion is that this will be difficult and messy!

For example, if I have a bundle that contains a webapp as a subdirectory (ie your case), like so:

example-bundle.jar:
META-INF/MANIFEST.MF
target/
target/classes/
target/classes/index.html
target/classes/com/
target/classes/com/acme/
target/classes/com/acme/osgi/
target/classes/com/acme/osgi/Activator.class

then felix puts it into the cache like this:
bundle38
��� bundle.info
��� version0.0
��� bundle.jar
��� bundle.jar-embedded
�   ��� target
�   ��� classes
��� revision.location

If instead I have an embedded packed war like so:

example-bundle-embedded.jar:
META-INF/MANIFEST.MF
com/
com/acme/
com/acme/osgi/
com/acme/osgi/Activator.class
embedded.war

then felix puts it into the cache like this:
bundle38
��� bundle.info
��� version0.4
��� bundle.jar
��� revision.location

I think the way forward is to use a lot of reflection to try and obtain the cached file location (rather than to hard-code an expectation of the above directory layout). However, this work will have a low priority as there is an effective workaround (using an embedded war rather than a directory).

thanks
Jan

On 2014-11-10 14:41:40 -0500, Dan Gravell wrote:

Sounds sensible.

migrated from Bugzilla #404508
status REOPENED severity normal in component server for 9.0.x
Reported in version 9.0.0 on platform PC
Assigned to: Joakim Erdfelt

On 2013-03-27 18:12:06 -0400, Greg Wilkins wrote:

port the overlay deployer to jetty-9

On 2013-05-13 16:46:06 -0400, Jesse McConnell wrote:

I have this brought over locally, am still sorting out how to reconcile with the lose of the contexts directory and the general direction we are going with deployment.

leaning towards perhaps jetty.home/webapps/overlays.d with that being configurable.

On 2013-05-20 10:25:05 -0400, Jesse McConnell wrote:

overlay is renabled, decided to keep things they way they were for the time being with regards to the overlay directory and we can review this for 9.1 when we roll in the new startup configuration process

On 2013-07-05 08:38:38 -0400, Sergey Korzhevsky wrote:

I cannot find overlay components in jetty-distribution-9.0.4.v20130625.tar.gz, e.g. there are no
etc/jetty-overlay.xml
lib/jetty-overlay-deployer*

Although they are exist in jetty-distribution-8.1.11.v20130520

On 2013-07-05 08:45:06 -0400, Jesse McConnell wrote:

hm. they made it into the repository but not the distro looks like

http://repo2.maven.org/maven2/org/eclipse/jetty/jetty-overlay-deployer/9.0.4.v20130625/

if you unjar the -config artifact from the above user and put the actual binary jar into the lib dir it should work, we'll have to take a look at what didn't work in the distro for this

On 2013-07-05 09:56:16 -0400, Sergey Korzhevsky wrote:

Thank you, Jesse!

On 2013-08-20 12:35:21 -0400, Jesse McConnell wrote:

Greg, I am passing this over to you since I don't think it is worth doing more on this for 9.0 but it should be a use case for 9.1 distro rejiggering work

On 2014-06-16 12:52:12 -0400, Jan Bartel wrote:

*** Bug 437468 has been marked as a duplicate of this bug. ***

On 2014-06-24 16:14:10 -0400, Greg Wilkins wrote:

Joakim,

I'm passing this one to you as I've not got time to consider it. This is not a high priority, but if you wanted a pet project it would be interesting to make the overlays work with the multiple base directories of start.jar mechanism as there are some very similar deployment concepts there.

But not a huge priority unless a sponsor come forward - remember the only thing worse than generalizing from one example is to generalize from no examples :)

migrated from Bugzilla #329175
status ASSIGNED severity enhancement in component server for 7.1.x
Reported in version 8.0.0 on platform All
Assigned to: Jan Bartel

On 2010-11-01 02:56:59 -0400, Jan Bartel wrote nothing.

migrated from Bugzilla #370088
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 8.1.0 on platform All
Assigned to: Project Inbox

On 2012-01-30 01:23:59 -0500, Greg Wilkins wrote:

Currently jetty keeps request/response objects associated with a connection and reuses them for each request received.

With modern garbage collectors, this may not be an ideal strategy, as it may encourage request/response object (and their associated objects) to migrate into old generation, since the lifetime of a connection is often be many minutes.

It may be better to simply recreate new request/response objects for each request. This would free memory while the connection is idle and reduce the chances of those objects ending up in old gen.

Note that Async Servlets and techniques like long polling will fight against this, as they increase the lifespan of request objects. However protocols like websocket may make long polling less utilised.

Another problem with recycling request/responses/continuations/AsyncContexts, is that it makes it harder to detect programming errors in asynchronous code, which wrongly holds onto a reference beyond the objects lifecycle.

We need to evaluate if recycling is still a net benefit.

On 2012-01-31 04:16:26 -0500, Simone Bordet wrote:

In addition to the comment above, we need to investigate if recycling of data contained in the request object is effective.

The HTTP headers name/values will sum up for a large amount of memory occupied by each request, so using interned strings for those may be more effective than recycling the request object that wraps them.

On 2013-01-24 19:57:03 -0500, Greg Wilkins wrote:

Evaluations in Jetty-9 have show

migrated from Bugzilla #375013
status ASSIGNED severity normal in component server for 9.0.0.RC0
Reported in version 7.6.2 on platform All
Assigned to: Jan Bartel

On 2012-03-21 22:48:36 -0400, Jan Bartel wrote:

Servlet spec 3.0, sec. 2.3.3.2, pg 10:

If a permanent unavailability is indicated by the UnavailableException, the servlet
container must remove the servlet from service, call its destroy method, and release
the servlet instance. Any requests refused by the container by that cause must be
returned with a SC_NOT_FOUND (404) response.

...

The container may choose to ignore the distinction between a permanent and
temporary unavailability and treat all UnavailableExceptions as permanent,
thereby removing a servlet that throws any UnavailableException from service.

migrated from Bugzilla #293394
status ASSIGNED severity enhancement in component server for 9.0.x
Reported in version 7.0.0 on platform PC
Assigned to: Jan Bartel

On 2009-10-27 03:29:22 -0400, Greg Wilkins wrote:

The jetty-maven plugin can only run a single web project, and it is sometimes desirable to run multiple contexts in development mode.

A deployer provider could be developed that scans a configured set of maven projects and deploys the webapps described by the poms. This could either be from deployed artefacts, or in development mode - from the unassembled source of the project (like the jetty-maven-plugin).

On 2011-09-20 12:28:36 -0400, Joakim Erdfelt wrote:

Moving importance down to Enhancement.