headers
Jesse McConnell | 22 May 2013 18:52
Favicon

[jetty-user] Released: Jetty 7.6.11.v20130520 / Jetty 8.1.11.v20130520

We are pleased to announce the availability of new Jetty 7.6 and Jetty 8.1 releases.  The issues resolved are listed below.

Distribution Downloads:


The artifacts are also available in Maven Central.

cheers,
jesse

-----
jetty-7.6.11.v20130520 - 20 May 2013 + 402844 STOP.PORT & STOP.KEY behaviour has changed + 403281 jetty.sh waits for started or failure before returning + 403513 jetty:run goal cannot be executed twice during the maven build + 403570 Asynchronous Request Logging + 404010 fix cast exception in mongodb session manager + 404128 Add Vary headers rather than set them + 404283 org.eclipse.jetty.util.Scanner.scanFile() dies with an NPE if listFiles() returns null + 404325 data constraint redirection does send default port + 404517 Close connection if request received after half close + 404789 Support IPv6 addresses in DoSFilter white list. + 404958 Fixed Resource.newSystemResource striped / handling + 405281 allow filemappedbuffers to not be used + 405537 NPE in rendering JSP using SPDY and wrapped ServletRequest + 406437 Digest Auth supports out of order nc + 406923 CR line termination + 407136 <at> PreDestroy called after Servlet.destroy() + 407173 java.lang.IllegalStateException: null when using JDBCSessionManager + 407976 JDBCSessionIdManager potentially leaves server in bad state after startup + 408077 HashSessionManager leaves file handles open after being stopped + 408446 Multipart parsing issue with boundry and charset in ContentType header

jetty-8.1.11.v20130520 - 20 May 2013 + 402844 STOP.PORT & STOP.KEY behaviour has changed + 403281 jetty.sh waits for started or failure before returning + 403513 jetty:run goal cannot be executed twice during the maven build + 403570 Asynchronous Request Logging + 404010 fix cast exception in mongodb session manager + 404128 Add Vary headers rather than set them + 404283 org.eclipse.jetty.util.Scanner.scanFile() dies with an NPE if listFiles() returns null + 404325 data constraint redirection does send default port + 404517 Close connection if request received after half close + 404789 Support IPv6 addresses in DoSFilter white list. + 404958 Fixed Resource.newSystemResource striped / handling + 405281 allow filemappedbuffers to not be used + 405537 NPE in rendering JSP using SPDY and wrapped ServletRequest + 406437 Digest Auth supports out of order nc + 406618 Jetty startup in OSGi Equinox fails when using option jetty.home.bundle=org.eclipse.jetty.osgi.boot + 406923 CR line termination + 407136 <at> PreDestroy called after Servlet.destroy() + 407173 java.lang.IllegalStateException: null when using JDBCSessionManager + 407931 Add toggle for failing on servlet availability + 407976 JDBCSessionIdManager potentially leaves server in bad state after startup + 408077 HashSessionManager leaves file handles open after being stopped + 408446 Multipart parsing issue with boundry and charset in ContentType header
jetty <at> codehaus-7.6.11.v20130520 - 20 May 2013
jetty <at> codehaus-8.1.11.v20130520 - 20 May 2013 + 407812 jetty-maven-plugin can not handle whitespaces in equivalent of WEB-INF/classes paths

--
Jesse McConnell <jesse <at> intalio.com>
www.intalio.com/jetty – Developer advice, services and support from the Jetty & CometD experts.
Permalink | Reply | 0 comments |
headers
Alan | 25 Apr 2013 04:38

[jetty-user] Embedded Jetty and SSL.

I'm using embedded Jetty to deploy several war files and would like some
advice on how to make it run under SSL. (I've bought a CERT from a CA and
now need to figure out how to use it for the login and admin war files. 

Here are may war files and how I would like to use them. 

MainPage.war           accessed as:     http://mydomain.com/                
(port 80 not SSL)
Login.war                accessed as:     https://mydomain.com/login         
(port 443 + SSL)
Admin.war              accessed as:      https://mydomain.com/admin       
(port 443 + SSL)

Currently I do something like   (greatly simplified to make shorter here)

//--- Start Code ---//
Server = new Server(80);

List<Handler> hList = new ArrayList<Handler>();
hList.add( new WebAppContext("../webapps/MainPage.war","/") );
hList.add( new WebAppContext("../webapps/Login.war","/login") );
hList.add( new WebAppContext("../webapps/Admin.war","/admin") );

ContextHandlerCollection contexts = new ContextHandlerCollection();
contexts.setHandlers(handlerList.toArray(new Handler[handlerList.size()]));
server.setHandler(contexts);

server.start();
server.join();

//--- End Code ---//

My question is 

#1) How do I change that to get SSL running on a different port?

#2) How do I specify the location of the .crt and .jks files with the CA
SSL?

#3) Am I better off creating a different Jetty server just to run the SSL
ports? 

P.S. I'm running Jetty 8.x in case it makes any difference.

Thanks for any advice.
Alan

--
View this message in context: http://jetty.4.x6.nabble.com/Embedded-Jetty-and-SSL-tp4960438.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
johnrg | 23 Apr 2013 23:24
Picon
Favicon

[jetty-user] Jetty webapps external jar files

Hi,

I am new to jetty and I am using jetty version 9. I have an war file
deployed to my app server. the web-inf/lib file has a few jar files  but I
need to deploy some other jar files that are not included in the web-inf/lib

I tried to copy the jar file  into jetty.home/lib/ext    but this is not
working.

please let me know how to do this so that the application can load the class
files.

thanks
John

--
View this message in context: http://jetty.4.x6.nabble.com/Jetty-webapps-external-jar-files-tp4960434.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 2 comments |
headers
Walter.Heestermans | 11 Apr 2013 04:17

[jetty-user] AUTO: Walter Heestermans/TMME is out of the office. (returning 15/04/2013)


I am out of the office until 15/04/2013.

I will respond to your message as soon as possible. For urgent issues,
contact WebSphere Support group for Java-WebSphere related activities or
unix.admin group for Unix-WebSphere-Jetty related activities

Note: This is an automated response to your message  "[jetty-user] Jetty
9.0.1.v20130408 Released!" sent on 10/04/2013 22:52:03.

This is the only notification you will receive while this person is away.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Jesse McConnell | 10 Apr 2013 22:52
Favicon

[jetty-user] Jetty 9.0.1.v20130408 Released!


Hard to believe we released Jetty 9 a mere month ago but we have been busy resolving some small issues and added to the new documentation hub.  If you haven't seen the new documentation take a look, and feel free to contribute through the github project that houses it.

Distribution Downloads:


The artifacts are also available in Maven Central.

Documentation:


I'll attach the resolves issues at the end of this mail, but we have been very happy with the response we have gotten from the Jetty 9 release and are looking forward to future versions.  Just as bit of a note for those interested, we'll be releasing 9.1 once the servlet 3.1 spec has finalized and likely the JSR 356 Websocket api spec has released, hopefully these will wrap up around the same time.  

cheers,
jesse




--
Jesse McConnell <jesse <at> intalio.com>
www.webtide.com – Developer advice, services and support from the Jetty & CometD experts.
Permalink | Reply | 1 comment |
headers
ghetolay | 26 Mar 2013 14:23
Picon

[jetty-user] Re: jetty 9: java.nio.channels.WritePendingException on WebSocket.connect over SSL

I had this warning but turns out error wasn't related to that.
When I switch to TRACE log I noticed I had an error about ssl handshake.

In my case it's because I change my jre from 1.6 to 1.7 because of jetty 9.
On 1.7 oracle is more strict about TLS handshake.

Now that I solve this problem I still get this same warning but looks like
everything works fine.

--
View this message in context: http://jetty.4.n6.nabble.com/jetty-9-java-nio-channels-WritePendingException-on-WebSocket-connect-over-SSL-tp4960023p4960305.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 0 comments |
headers
Jesse McConnell | 14 Mar 2013 17:01
Picon
Gravatar

[jetty-user] Jetty 7.6.10.v20130312 / Jetty 8.1.10.v20130312 Released!


Hot on the heels of our Jetty 9 release, we have released updates to our two mature versions.  We will continue releasing updates to 7 and 8, roughly every couple of months for the foreseeable future.


Releases are available in Maven Central as well.

cheers,
jesse

The list of changes are:

jetty-7.6.10.v20130312 - 12 March 2013 + 376273 Early EOF because of SSL Protocol Error on https://api-3t.paypal.com/nvp. + 381521 allow compress methods to be configured + 394064 ensure that JarFile instances are closed on JarFileResource.release() + 398649 ServletContextListener.contextDestroyed() is not called on ContextHandler unregistration + 399703 made encoding error handling consistent + 399799 do not hold lock while calling invalidation listeners + 399967 Shutdown hook calls destroy + 400040 NullPointerException in HttpGenerator.prepareBuffers + 400142 ConcurrentModificationException in JDBC SessionManger + 400144 When loading a session fails the JDBCSessionManger produces duplicate session IDs + 400457 Thread context classloader hierarchy not searched when finding webapp's java:comp/env + 400859 limit max size of writes from cached content + 401211 Remove requirement for jetty-websocket.jar in WEB-INF/lib + 401317 Make Safari 5.x websocket support minVersion level error more clear + 401382 Prevent parseAvailable from parsing next chunk when previous has not been consumed. Handle no content-type in chunked request. + 401474 Performance problem in org.eclipse.jetty.annotation.AnnotationParser + 401531 StringIndexOutOfBoundsException for "/*" <url-pattern> of <jsp-property-group> fix for multiple mappings to *.jsp + 401908 Enhance DosFilter to allow dynamic configuration of attributes. + 402048 org.eclipse.jetty.server.ShutdownMonitor doesn't stop after the jetty server is stopped + 402485 reseed secure random + 402735 jetty.sh to support status which is == check + 402833 Test harness for global error page and hide exception message from reason string
(no changes for jetty <at> codehaus for jetty 7)

jetty-8.1.10.v20130312 - 12 March 2013 + 376273 Early EOF because of SSL Protocol Error on https://api-3t.paypal.com/nvp. + 381521 allow compress methods to be configured + 392129 fixed handling of timeouts after startAsync + 394064 ensure that JarFile instances are closed on JarFileResource.release() + 398649 ServletContextListener.contextDestroyed() is not called on ContextHandler unregistration + 399703 made encoding error handling consistent + 399799 do not hold lock while calling invalidation listeners + 399967 Shutdown hook calls destroy + 400040 NullPointerException in HttpGenerator.prepareBuffers + 400142 ConcurrentModificationException in JDBC SessionManger + 400144 When loading a session fails the JDBCSessionManger produces duplicate session IDs + 400312 ServletContextListener.contextInitialized() is not called when added in ServletContainerInitializer.onStartup + 400457 Thread context classloader hierarchy not searched when finding webapp's java:comp/env + 400859 limit max size of writes from cached content + 401211 Remove requirement for jetty-websocket.jar in WEB-INF/lib + 401317 Make Safari 5.x websocket support minVersion level error more clear + 401382 Prevent parseAvailable from parsing next chunk when previous has not been consumed. Handle no content-type in chunked request. + 401474 Performance problem in org.eclipse.jetty.annotation.AnnotationParser + 401485 zip file closed exception + 401531 StringIndexOutOfBoundsException for "/*" <url-pattern> of <jsp-property-group> fix for multiple mappings to *.jsp + 401908 Enhance DosFilter to allow dynamic configuration of attributes. + 402048 org.eclipse.jetty.server.ShutdownMonitor doesn't stop after the jetty server is stopped + 402485 reseed secure random + 402735 jetty.sh to support status which is == check + 402833 Test harness for global error page and hide exception message from reason string
jetty <at> codehaus-8.1.10.v20130312 - 12 March 2013 + 400312 ServletContextListener.contextInitialized() is not called when added in ServletContainerInitializer.onStartup
Permalink | Reply | 0 comments |
headers
kevinc | 10 Mar 2013 21:40
Picon

[jetty-user] Re: Jetty 7.6.9: STOP.PORT & STOP.KEY behavior has changed

The issue with the STOP.KEY behaviour changing in 7.6.9 seems related to the
following patch:

  *Bug 391623 - Add option to --stop to wait for target jetty to stop*

Looking at the changes made within this commit it seems that the
auto-generation of the STOP.KEY will never occur as it will always default
to "eclipse" and never be assigned /null/.

The diff can be found here (note the references to STOP.KEY/this.key):

 
https://eclipse.googlesource.com/jetty/org.eclipse.jetty.project/+/b65973afdd280459b8762678d5c5341abf2680ca%5E!/#F0

--
View this message in context: http://jetty.4.n6.nabble.com/Jetty-7-6-9-STOP-PORT-STOP-KEY-behavior-has-changed-tp4960180p4960212.html
Sent from the Jetty Support mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email
Permalink | Reply | 4 comments |
headers
Joakim Erdfelt | 9 Mar 2013 01:33
Favicon

[jetty-user] Announcing Jetty 9.0.0

The Eclipse Jetty Project team is proud to announce the first release of the new Jetty 9

        Jetty 9.0.0.v20130308

The Java Web Server with support for SPDY and WebSocket.

Distributions Downloads:

Java Artifacts Available on Maven Central:

<groupId>org.eclipse.jetty</groupId>
<version>9.0.0.v20130308</version>

Jetty 9.x Features:
  • Completely overhauled I/O layer
  • Servlet API 3.0
  • JSP 2.2
  • SPDY/3
  • WebSocket (RFC-6455)
Notes for those migrating to Jetty 9.x:
  • Requires Java 1.7 or newer.
  • Jetty Maven Plugin has now been moved to org.eclipse.jetty groupId
  • There is no org.mortbay or codehaus components
  • Support for early WebSocket drafts has been dropped, only support released RFC-6455 spec.
  • There now only 1 aggregate jar, called jetty-all.
  • Bad UTF8 encoding will result in replacement characters being passed into the application to handle. (older versions of Jetty would fail the request)
  • Removal of all traditional Socket (BIO) Connectors.
    • Only supporting NIO for Connectors.
  • Consolidated all of the various Deployment technique and scenarios into one.
    • ContextDeployer and WebAppDeployer have been removed
    • DeploymentManager has only 1 AppProvider now, the WebAppProvider
    • WebAppProvider supports both Deployment Descriptors deployment and traditional Automatic WAR deployment.
  • New Jetty Async Http Client
  • New Jetty WebSocket Servlet & WebSocket Client
  • A new Jetty XML DTD (http://www.eclipse.org/jetty/configure_9.0.dtd) changes the <Ref id=""> syntax in your Jetty XML to <Ref refid="">
  • Removed Jetty6Continuation support

--
Joakim Erdfelt <joakim <at> intalio.com>
Developer advice, services and support
from the Jetty & CometD experts
Permalink | Reply | 0 comments |
headers
Valery Dubrava | 8 Mar 2013 20:20
Picon

[jetty-user] Async Context does not accept simultaneous requests

I tried to create context for accepting many simultaneous requests by using AsyncServelet/Continuation. But the all requests to one context are queued. I will provide some code blocks for introducing into the problem. Please, help me with this issue. Maybe I understand something wrong and use this technology to the wrong way? A simple spring xml config for JettyServer:

<bean name="jettyThreadPool" class="org.eclipse.jetty.util.thread.QueuedThreadPool"> <property name="name" value="jettyThreadPool" /> <property name="minThreads" value="10" /> <property name="maxThreads" value="100" /> </bean> <bean name="jettyConnector" class="org.eclipse.jetty.server.nio.SelectChannelConnector"> <property name="host" value="0.0.0.0" /> <property name="port" value="8080" /> <!-- The number of thread dedicated to accepting incoming connections. <= 2*processors --> <property name="acceptors" value="4" /> <!-- Number of connection requests that can be queued up before the operating system starts to send rejections. --> <property name="acceptQueueSize" value="1" /> <property name="resolveNames" value="false" /> <property name="threadPool" ref="jettyThreadPool" /> </bean> <bean name="server" class="org.eclipse.jetty.server.Server"> <property name="connectors"> <array> <ref bean="jettyConnector" /> </array> </property> <property name="handler"> <bean class="org.eclipse.jetty.server.handler.HandlerCollection"> <property name="handlers"> <array> <bean class="org.eclipse.jetty.server.handler.ContextHandler"> <property name="contextPath" value="/check" /> <property name="handler"> <bean class="com.oak.handlers.AsyncCheckHandler" /> </property> </bean> </array> </property> </bean> </property> </bean> The AsyncCheckHandler is only for testing. In future it will make request to remote resources which takes several seconds. That why I call a sleep with 5 seconds interval. public class AsyncCheckHandler extends AbstractHandler { <at> Override public void handle(String target, final Request baseRequest, final HttpServletRequest req, final HttpServletResponse rsp) throws IOException, ServletException { final AsyncContext context = req.startAsync(req, rsp); context.start(new Runnable() { <at> Override public void run() { try { Date date = new Date(); Thread.sleep(5000L); context.getResponse().getWriter().print("Request date " + date + ", " + "" + Thread.currentThread().getName()); baseRequest.setHandled(true); } catch (InterruptedException | IOException e) { e.printStackTrace(); } finally { context.complete(); } } }); } } And main class is very simple: ApplicationContext context = new ClassPathXmlApplicationContext("context.xml"); Server server = (Server) context.getBean("server"); try { server.start(); server.join(); } catch (Exception e) { e.printStackTrace(); } When I run it and make several parallel requests to http://localhost:8080/check each of this requests is suspended until previous was done. That is the problem for me. I expected that after it returns from handler it will be ready to accept new requests to this context. Also I've tried the same thing with ServletContext and with Continuation. Jetty version is 8.1.9.v20130131, spring is 3.2.1.RELEASE. Java 1.7.0_13 I've tried this on windows7 and debian.
View this message in context: Async Context does not accept simultaneous requests
Sent from the Jetty Support mailing list archive at Nabble.com.
Permalink | Reply | 4 comments |
headers
Scott Morgan | 7 Mar 2013 06:01

[jetty-user] Java WebSocket Client from main(String [] args)

Hi,

   Sorry for the cross post, I don't know where this should go.  I would like to use the jetty web socket-client in stand alone java applications (outside of a jetty web app ie main(String[] args)).
   Does the jetty web socket client support this?
   
If not I would suggest it as I am maintaining (somewhat poorly) a WebSocketClient here;

I am getting

java.io.IOException: Invalid handshake response 'HTTP/1.1 400 Unsupported websocket version specification: 2147483647' should be 'HTTP/1.1 101 Web Socket Protocol Handshake'


TIA,

Scott


Permalink | Reply | 0 comments |

Gmane