[jetty-user] how do I enable put and delete for static content?

Re: [jetty-user] how do I enable put and delete for static content?

first off, jetty 7.5.0 and 8.0.0 have both been released so if your
just getting started it make no sense to start back in the jetty6
days.

second, we don't support put and delete on the base resource handler,
but you can write your own handler to do these things without too much
trouble and if you wanted to contribute that back to the project your
more then welcome to :)

barring that, if you would like to open an issue for an enhancement,
please do so in bugs.eclipse.org for jetty 7 and up.  You can open one
in jira.codehaus.org but I'll tell you now that the chances of our
adding new behavior to jetty6 is remote at best.

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell <at> gmail.com

On Tue, Sep 6, 2011 at 07:39, Richard Murray
<Richard.Murray <at> orchard-systems.co.uk> wrote:
> Hi,
>
> I'm  trying to configure Jetty to serve static content (I'm creating a
> repository for Apache Ivy - its all static content but I need to allow get,
> put and delete operations)
>
> I've installed Jetty-6.1.26, and have created a file in
> JBOSS_HOME/contexts/ivy-repo.xml (which is a copy of the javadoc.xml
> example).  I've setup the file as follows:
>
> <Configure class="org.mortbay.jetty.handler.ContextHandler">
>
>   <Set name="contextPath">/ivyrepo</Set>
>   <Set name="resourceBase">F:/ivy-repo/</Set>
>
>   <Call name="addHandler">
>        <Arg>
>            <New class="org.mortbay.jetty.handler.ResourceHandler"/>
>        </Arg>
>    </Call>
> </Configure>
>
> The get operations are working OK, but I get 405 errors attempting a post
>
> Cause: java.io.IOException: PUT operation to URL
> http://localhost:8080/ivyrepo/ois/serverUtils/jars/oisServerUtils-1.0.jar
> failed with status code 405
> : HTTP method PUT is not supported by this URL
>
> NOTE: I also have a couple of web apps deployed that are separate from the
> static content I am trying to serve, so I don't want to break any of the
> existing deployments.
>
> Can anyone help?
>
>
>
> Apologies if this get’s posted twice, my original message got bounced back
> from my gmail account.
>
>
>
> Thanks.

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

    http://xircles.codehaus.org/manage_email

RE: [jetty-user] how do I enable put and delete for static content?

Hi, 

Thanks for the quick response.  I'm not just starting we already have a Jetty
6 system running.  I've installed version 6 locally to try and figure out how
to add the static content before tinkering with the production system.

Would writing a handler involve creating Java code or just another xml config
file?

Thanks,

-----Original Message-----
From: Jesse McConnell [mailto:jesse.mcconnell <at> gmail.com] 
Sent: 06 September 2011 13:53
To: user <at> jetty.codehaus.org
Subject: Re: [jetty-user] how do I enable put and delete for static content?

first off, jetty 7.5.0 and 8.0.0 have both been released so if your just
getting started it make no sense to start back in the jetty6 days.

second, we don't support put and delete on the base resource handler, but you
can write your own handler to do these things without too much trouble and if
you wanted to contribute that back to the project your more then welcome to
:)

barring that, if you would like to open an issue for an enhancement, please
do so in bugs.eclipse.org for jetty 7 and up.  You can open one in
jira.codehaus.org but I'll tell you now that the chances of our adding new
behavior to jetty6 is remote at best.


cheers,
jesse

--
jesse mcconnell
jesse.mcconnell <at> gmail.com



On Tue, Sep 6, 2011 at 07:39, Richard Murray
<Richard.Murray <at> orchard-systems.co.uk> wrote:
> Hi,
>
> I'm  trying to configure Jetty to serve static content (I'm creating a 
> repository for Apache Ivy - its all static content but I need to allow 
> get, put and delete operations)
>
> I've installed Jetty-6.1.26, and have created a file in 
> JBOSS_HOME/contexts/ivy-repo.xml (which is a copy of the javadoc.xml 
> example).  I've setup the file as follows:
>
> <Configure class="org.mortbay.jetty.handler.ContextHandler">
>
>   <Set name="contextPath">/ivyrepo</Set>
>   <Set name="resourceBase">F:/ivy-repo/</Set>
>
>   <Call name="addHandler">
>        <Arg>
>            <New class="org.mortbay.jetty.handler.ResourceHandler"/>
>        </Arg>
>    </Call>
> </Configure>
>
> The get operations are working OK, but I get 405 errors attempting a 
> post
>
> Cause: java.io.IOException: PUT operation to URL 
> http://localhost:8080/ivyrepo/ois/serverUtils/jars/oisServerUtils-1.0.

> jar
> failed with status code 405
> : HTTP method PUT is not supported by this URL
>
> NOTE: I also have a couple of web apps deployed that are separate from 
> the static content I am trying to serve, so I don't want to break any 
> of the existing deployments.
>
> Can anyone help?
>
>
>
> Apologies if this get’s posted twice, my original message got bounced 
> back from my gmail account.
>
>
>
> Thanks.

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

    http://xircles.codehaus.org/manage_email

Re: [jetty-user] how do I enable put and delete for static content?

sorry, writing a handler is more java code, but it ought to be pretty
easy to whip up

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell <at> gmail.com

On Tue, Sep 6, 2011 at 08:03, Richard Murray
<Richard.Murray <at> orchard-systems.co.uk> wrote:
> Hi,
>
> Thanks for the quick response.  I'm not just starting we already have a Jetty
> 6 system running.  I've installed version 6 locally to try and figure out how
> to add the static content before tinkering with the production system.
>
> Would writing a handler involve creating Java code or just another xml config
> file?
>
> Thanks,
>
> -----Original Message-----
> From: Jesse McConnell [mailto:jesse.mcconnell <at> gmail.com]
> Sent: 06 September 2011 13:53
> To: user <at> jetty.codehaus.org
> Subject: Re: [jetty-user] how do I enable put and delete for static content?
>
> first off, jetty 7.5.0 and 8.0.0 have both been released so if your just
> getting started it make no sense to start back in the jetty6 days.
>
> second, we don't support put and delete on the base resource handler, but you
> can write your own handler to do these things without too much trouble and if
> you wanted to contribute that back to the project your more then welcome to
> :)
>
> barring that, if you would like to open an issue for an enhancement, please
> do so in bugs.eclipse.org for jetty 7 and up.  You can open one in
> jira.codehaus.org but I'll tell you now that the chances of our adding new
> behavior to jetty6 is remote at best.
>
>
> cheers,
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell <at> gmail.com
>
>
>
> On Tue, Sep 6, 2011 at 07:39, Richard Murray
> <Richard.Murray <at> orchard-systems.co.uk> wrote:
>> Hi,
>>
>> I'm  trying to configure Jetty to serve static content (I'm creating a
>> repository for Apache Ivy - its all static content but I need to allow
>> get, put and delete operations)
>>
>> I've installed Jetty-6.1.26, and have created a file in
>> JBOSS_HOME/contexts/ivy-repo.xml (which is a copy of the javadoc.xml
>> example).  I've setup the file as follows:
>>
>> <Configure class="org.mortbay.jetty.handler.ContextHandler">
>>
>>   <Set name="contextPath">/ivyrepo</Set>
>>   <Set name="resourceBase">F:/ivy-repo/</Set>
>>
>>   <Call name="addHandler">
>>        <Arg>
>>            <New class="org.mortbay.jetty.handler.ResourceHandler"/>
>>        </Arg>
>>    </Call>
>> </Configure>
>>
>> The get operations are working OK, but I get 405 errors attempting a
>> post
>>
>> Cause: java.io.IOException: PUT operation to URL
>> http://localhost:8080/ivyrepo/ois/serverUtils/jars/oisServerUtils-1.0.
>> jar
>> failed with status code 405
>> : HTTP method PUT is not supported by this URL
>>
>> NOTE: I also have a couple of web apps deployed that are separate from
>> the static content I am trying to serve, so I don't want to break any
>> of the existing deployments.
>>
>> Can anyone help?
>>
>>
>>
>> Apologies if this get’s posted twice, my original message got bounced
>> back from my gmail account.
>>
>>
>>
>> Thanks.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[jetty-user] questions on the asynch nio and does framework support it

Re: [jetty-user] questions on the asynch nio and does framework support it

Yes you should be able to do something like this if I follow your line
of thinking, take a look at jetty continuations for servlet 2.5 and
these sorts of async behaviors are built into servlet 3.0

http://wiki.eclipse.org/Jetty/Feature/Continuations

cheers and good luck :)

jesse

--
jesse mcconnell
jesse <at> intalio.com

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)

On Fri, Sep 9, 2011 at 10:11, Dean Hiller <dean <at> alvazan.com> wrote:
> We would like to do something like the below.  Is this possible with jetty
> and the nio implementation?
>
> doGet(ServletReq req, ServletResp servletResponse) {
>    noSqlDatabase.asynchRead(keys, new CallbackForRead(servletResponse));
> }
>
> CallbackForRead implements NoSqlReadCallback {
>     private ServletResponse resp;
>     public CallbackForRead(ServletResponse r) { resp = r; }
>     public void dataRead(Data data) {
>         String response = formResponse(data);
>         resp.write(response);
>     }
> }
>
> NOTE: The jetty thread that fed us the request RETURNS while we wait for a
> response from the nosql database or any external system for that matter.
> When we are fed back the response of data, we are on a different thread but
> want to feed the servlet response back into the ServletResponse object(ie.
> the socket for the client is still open even though the thread returned).
>
> Why?  Well, it turns out we can use 10x less servers in this model because
> existing threads can be used which eliminates alot of cost as we can use 1
> server instead of 10.  The 10x number varies greatly depending on the
> network latency to the back end system whether database or DNS....the more
> latency the 10x number can increase even more significantly but 1 computer
> instead of 10 is already a really nice savings $$$$$.
>
> thanks,
> Dean
>
>

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

    http://xircles.codehaus.org/manage_email

[jetty-user] 7.5.1 and 8.0.1 Released!

We are pleased to announce the immediate availability of Jetty
7.5.1.v20110908 and 8.0.1.v20110908

All artifacts are present in maven central and are also available from
the normal download locations at eclipse and codehaus.

- http://download.eclipse.org/jetty
- http://dist.codehaus.org/jetty

Deb and rpm artifacts for these builds that incorporate the
jetty-hightide distribution.  These are also in maven central under
the org.mortbay.jetty.dist:jetty-deb and
org.mortbay.jetty.dist:jetty-rpm coordinates or also from the codehaus
downloads directory.

- http://dist.codehaus.org/jetty/deb
- http://dist.codehaus.org/jetty/rpm

It looks like we forgot to formally announce the last releases so this
announcement will pickup changes from all the versions.  7.5 picks up
a lot of performance enhancements and 8.0 represents the release of
our servlet 3.0 support.  8.0 is really a thin layer over the
functionality that is already battle hardened and proven in jetty 7 so
if you want servlet 3 support, go ahead and pick that up.

The list of issues resolved follow at the tail end of this mail.

cheers,
jesse

Jetty 7:

jetty-7.5.1.v20110908 - 08 September 2011
 + 350634 Added Resource.newResource(File)
 + 356190 fix monodb tests  for changed test api
 + 356428 removed timed waits from test
 + 356693 reduce visibility to webapp of websocket implementations
 + 356695 jetty server jars are provided for websockets
 + 356726 Instead of the sessionDestroyed called sessionCreated after
   invalidate session
 + 356751 Add null protection to ServletContextHandler.doStop
 + 356823 correctly decode close codes.  Send not utf-8 close code.
 + 357058 Acceptor thread blocking

jetty-7.5.0.v20110901 - 01 September 2011
 + 356421 Upgraded websocket to draft 13 support
 + 353073 better warnings

jetty-7.5.0.RC2 - 30 August 2011
 + 293739 Hide stacks in named log testing. Various other minor log cleanups in
   output.
 + 352188 TestClient correctly processes --host option in jetty-websocket
 + 352222 Moved JmxMonitor functionality from Codehaus
 + 353014 TimeoutExchangeTest run time reduced
 + 353073 deprecated non factory method for websocket clients
 + 353192 Better warning for classes of wrong type
 + 353623 Added new methods to HttpExchange
 + 353624 HttpURI accepts java.net.URI object in constructor
 + 354080 ServletContextHandler allows to replace any subordinate handler when
   restarted
 + 355478 set public to HashedSession, looks like honest mistake and not by
   design to be this way
 + 355854 remove automatic conversion in favor of issuing a warning for
   jetty-web.xml that can't be processed
 + 356128 Moved integration tests from jetty-monitor to test-integration module
 + 356137 Upgrade to jsp implementation version 2.1.3-b10
 + 356144 added SelectorManager.setSelectorPriorityDelta(int)
 + JETTY-1410 handle 1xx in similar fashion to 401s and 302s

jetty-7.5.0.RC1 - 19 August 2011
 + 276670 SLF4J loggers show correct location information
 + 335001 Eliminate expected exceptions from log when running in JBoss
 + 355103 Make allowCredentials default to true in CrossOriginFilter
 + 355162 Allow creating an empty resource collection
 + JETTY-1410 HTTP client handles CONTINUE 100 response correctly
 + JETTY-1414 HashLoginService doesn't refresh realm if specified config
   filename is not an absolute platform specific value

jetty-7.5.0.RC0 - 15 August 2011
 + 298502 Handle 200 Connect responses with no content-length
 + 347484 / - > ${/} in some paths in grant codebases
 + 349005 add javadoc detailing the convenience hack of removing leading /'s
 + 351516 Refactored sessions to better support nosql session managers
 + 351576 Do not use deprecated method File.toURL()
 + 352046 Need try/catch around features set in XmlParser
 + 352133 Generally resolve java 1.5isms
 + 352176 xml parsing on startElement should be more flexible on using qName or
   localName
 + 352421 HttpURI paths beginning with '.'
 + 352684 Implemented spinning thread analyzer
 + 352786 GzipFilter fails to pass parameters to GzipResponseWrapper
 + 352999 ExpireTest running too long
 + 353073 WebSocketClient
 + 353095 maven-jetty-plugin: PermGen leak due to javax.el.BeanELResolver
 + 353165 addJars can follow symbolic link jar files
 + 353210 Bundle-Version in o.e.j.o.boot.logback fix
 + 353465 JAASLoginService ignores callbackHandlerClass
 + 353563 HttpDestinationQueueTest too slow
 + 353862 Improve performance of QuotedStringTokenizer.quote()
 + 354014 Content-Length is passed to wrapped response in GZipFilter
 + 354204 Charset encodings property file not used
 + 354397 RewriteRegexRule handles special characters in regex group
 + 354466 Typo in example config of jetty-plus.xml

jetty <at> codehaus-7.5.1.v20110908 - 08 September 2011
 + JETTY-1419 remove jetty-monitor from codehaus side
 + JETTY-1425 jboss-jetty sar uses old slf4j libs

jetty <at> codehaus-7.5.0.v20110901 - 01 September 2011
 + JETTY-1218 delete example extra webapp, too much bitrot

jetty <at> codehaus-7.5.0.RC2 - 30 August 2011
 + 293739 Deprecate static Jetty Log usage in favor of named logs

jetty <at> codehaus-7.5.0.RC1 - 19 August 2011

jetty <at> codehaus-7.5.0.RC0 - 15 August 2011
 + Fix test-jaas-webapp/authfail.html format
 + JETTY-991 Implement run-forked mojo for jetty-maven-plugin
 + JETTY-1383 Provide Debian and RPM binary distribution of Core Jetty
 + JETTY-1393 add jetty-jboss session manager methods
 + JETTY-1394 Do not use deprecated method File.toURL()
 + JETTY-1399 Add more setters for jetty-maven-plugin configuration parameters
 + JETTY-1401 migrate jetty-jmx-ws module
 + JETTY-1404 Allow configuring resource path precedence in jetty-maven-plugin
 + JETTY-1412 runner ignores log config from config
 + 352512 setup archetypes into jetty codehaus build
 + 353932 add file server archetype

Jetty 8:

jetty-8.0.1.v20110908 - 08 September 2011
 + 350634 Added Resource.newResource(File)
 + 356190 fix mongodb tests  for changed test api
 + 356428 removed timed waits from test
 + 356693 reduce visibility to webapp of websocket implementations
 + 356695 jetty server jars are provided for websockets
 + 356726 Instead of the sessionDestroyed called sessionCreated after
   invalidate session
 + 356751 Add null protection to ServletContextHandler.doStop
 + 356823 correctly decode close codes.  Send not utf-8 close code.
 + 357058 Acceptor thread blocking

jetty-8.0.0.v20110901 - 01 September 2011
 + 352565 cookie httponly flag ignored
 + 353073 better warnings
 + 353285 ServletSecurity annotation ignored
 + 356421 Upgraded websocket to draft 13 support

jetty <at> codehaus-8.0.1.v20110908 - 08 September 2011
 + JETTY-1419 remove jetty-monitor from codehaus side
 + JETTY-1425 jboss-jetty sar uses old slf4j libs

jetty <at> codehaus-8.0.0.v20110901 - 01 September 2011
 + 293739 Deprecate static Jetty Log usage in favor of named logs
 + JETTY-1218 delete example extra webapp, too much bitrot

jetty <at> codehaus-8.0.0.RC0 - 16 August 2011
 + merge of 7.5.0.RC0
 + 353285 ServletSecurity annotation ignored

--
jesse mcconnell
jesse <at> intalio.com

http://webtide.com / http://intalio.com
(the folks behind jetty and cometd)

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

    http://xircles.codehaus.org/manage_email

[jetty-user] jetty-maven-plugin forked execution

https://jira.codehaus.org/browse/JETTY-991

I've been doing some work on the above issue in order to remove the
dependency on the jetty-runner jar
that was introduced recently to support a forked execution of the
jetty plugin. I've taken this opportunity
to revisit the code. The work is being done in the branch named
"forked-runner" on the codehaus git
repo if you're interested.

What I've implemented so far is the ability to fork off a new process
to run jetty on the *unassembled* webapp.
So, its now very similar to the jetty:run mojo, but just in a new jvm.

I'm posting this to the jetty lists to solicit some feedback to help
me complete the work. In particular,
I'd really appreciate some use-cases from people who have been asking
for forked executions - by that
I mean small example webapps with pom configuration for the style of
plugin execution that is wanted.

As background, here's some info on how the new "mvn jetty:run-forked"
mojo is configured:

<configure>
  <!-- where the unassembled web.xml is (optional: default value shown) -->
  <webXml>${basedir}/src/main/webapp/WEB-INF/web.xml</webXml>

  <!-- where the root of the unassembled webapp is (optional: default
value shown) -->
  <webAppSourceDirectory>${basedir}/src/main/webapp</webAppSourceDirectory>

  <!-- where the tmp directory for the webapp is (optional: default
value shown) -->
  <tmpDirectory>${project.build.directory}/tmp</tmpDirectory>

  <!-- where the classes for the webapp are (optional: default value shown) -->
  <classesDirectory>${project.build.outputDirectory}</classesDirectory>

  <!-- where the test classes for the webapp are (optional: default
value shown) -->
  <testClassesDirectory>${project.build.testOutputDirectory}</testClassesDirectory>

  <!-- whether or not to put the test classes on the webapp's
classpath (default shown) -->
  <useTestClasspath>false</useTestClasspath>

  <!-- context xml file to configure the WebAppContext (optional) -->
  <contextXml>src/main/config/context.xml</contextXml>

  <!-- the path for the deployed webapp (mandatory) -->
  <contextPath>/foo</contextPath>

  <!-- comma sep list of jetty xml files to configure the Server (optional) -->
  <jettyXml>src/main/config/jetty1.xml,src/main/config/jetty2.xml</jettyXml>

  <!-- stop port -->
  <stopPort></stopPort>

  <!-- stop key -->
  <stopKey></stopKey>

  <!-- skip the execution or not (default shown) -->
  <skip>false</skip>
</configure>

You'll notice the configuration is somewhat different to the "mvn
jetty:run" config. For example,
you cannot use the <webAppConfig> element to configure the
WebAppContext representing the
webapp, nor the <connectors>, <loginServices> and <requestLog> to
configure the jetty Server.
Instead, you use context xml and jetty xml files instead (actually,
I've been intending  for some time
to entirely remove the <connectors>, <loginServices> and <requestLog>
elements, as using jetty xml
files is a much better way to do it).

When run with "mvn jetty:run-forked" the above example would start up
a separate jvm, and start a
Server which is configured by the src/main/config/jetty1.xml and
src/main/config/jetty2.xml files, and
then create and deploy a WebAppContext to it representing the
unassembled webapp that is configured
by a combination of the src/main/config/context.xml file, the pom, and
generated by the plugin.

The forked vm will continue to execute until a "mvn jetty:stop" is
issued (in another terminal window).

What is not clear to me is what is the desired lifecycle relationship
between the plugin and the forked process:

  -should the plugin wait for the child process to finish?
  or
  -should the plugin finish immediately after forking?

  - if the plugin finishes immediately, how will we avoid orphan jetty
processes?

  -if the plugin waits for the child process to finish, does stopping
the plugin also stop the forked process?

If some of you could provide example webapps and poms of how you'd
like to run these forked executions
that I could test with, that would be very helpful.

thanks
Jan

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

    http://xircles.codehaus.org/manage_email

[jetty-user] SSLv3/TLSv1 Security Exploit

On September 19, 2011 an exploit of a vulnerability in SSL 3.0 and TLS
1.0 (and below) was demonstrated that allows an attacker to decrypt
communications between 2 parties.  The demonstration was against a
PayPal Authentication cookie, which took 10 minutes to decipher with
the aid of a packet sniffer and some hostile javascript running in the
browser.

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

While TLS 1.1 and 1.2 are not vulnerable, these versions are not yet
commonly available in browsers and JVMs.   Java 6 currently only
supports TLS 1.0, while Java 7 supports TLS 1.1 and 1.2.  It has not
yet been announced if a TLS 1.1 provider will be made available for
Java 6. As of recently, the browser support for TLS can be seen at
http://en.wikipedia.org/wiki/Transport_Layer_Security#Browser_implementations.
 Google Chrome has already announced imminent support for 1.2 and it
is expected that the other browsers will follow shortly (see
http://www.theregister.co.uk/2011/09/21/google_chrome_patch_for_beast/).

Jetty when used with it's default configuration of SSL will use the
highest common version of TLS available that is shared by the browsers
and JVM.  Thus if jetty is running on java 7 today, it will
automatically use TLS 1.1 or 1.2 if it is available in the browser.
However there is currently no mechanism to disable protocol versions
within Jetty (unless they are disabled in the JVM).

Jetty-7.5.2-SNAPSHOT has now been modified to support lists of
included and excluded protocols in the configuration of the
SslContextFactory class used to configure SSL clients and server
connectors.  This will allow TLS 1.0 to be excluded once clients that
support it are widely deployed. A stable release of 7.5.2 will be
available next week.

We strongly recommend that you  upgrade your systems (browser and
JVMs) to support TLS 1.1 or later.  For Jetty servers, this currently
means running on java 7.  Until TLS 1.1 is widely available in
browsers, it is recommended that you evaluate the risks of continuing
to provide your services over SSL and TLS.

regards

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

    http://xircles.codehaus.org/manage_email

[jetty-user] Configuring a SslContextFactory from an input stream