jetty-discuss — Discussion of Jetty development issues

[jetty-discuss] Jack (himars@gmail.com) personally selected you to receive a Shop It To Me invite

[Jack v. S. It To Me <in...@sh...>]

<p>I know you like good deals on clothing/fashion so I got you a private invitation for Shop It To Me:</p>
Go here:
http://www.shopittome.com/expiring_invitation/abv4a6a1800

-Jack

This private invitation will expire in 24 hours.


Jack (hi...@gm...) has sent you a private invitation for Shop It To Me. If you do not want to receive these messages, paste the following link into your browser:
http://www.shopittome.com/blocked_email/amV0dHktZGlzY3Vzc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ_
 

Shop It To Me, Inc.  340 Brannan Street #201   San Francisco, CA 94107

[jetty-discuss] Deadlocks in Jetty

[Robert N. <rob...@gm...>]

Hi,

Just wondering has the following deadlock in Jetty been addressed yet?

We are using jetty 6.1.9

"2028005587@qtp-3981922-2012":
   waiting to lock monitor 0x0000002aa99b0620 (object 0x0000002aa18ee520, a
java.util.HashSet),
   which is held by "978748939@qtp-3981922-1 - Acceptor0
SelectChannelConnector@0.0.0.0:9101"
 "978748939@qtp-3981922-1 - Acceptor0 SelectChannelConnector@0.0.0.0:9101":
   waiting to lock monitor 0x0000002aa99b0698 (object 0x0000002aa6d4c1d8, a
java.lang.Object),
   which is held by "2028005587@qtp-3981922-2012"

[jetty-discuss] HTTP Request logging with Log4J

[Chance Y. <cy...@ca...>]

Hi,

I have posted some initial code for Log4J Request Logging with Jetty6.  Some config examples are included in the readme file.  If anyone has any feedback, please let me know.

http://jira.codehaus.org/browse/JETTY-835

Thanks,

Chance


--
Center for the Application of Information Technologies

[jetty-discuss] Google summer of code 09

[C. B. <cbe...@ne...>]

Hi everyone..

I've mentioned this before on irc, but for those who may be possible 
mentors or have good ideas for google summer of code.. gsoc deadlines 
are around the corner.

Initial thought..

    - admin interface

More ideas?


Thanks

./Christopher

[jetty-discuss] No chunked encoding in post response

[Mike G. <mik...@ca...>]

Hi,

In the response to a post request i do not set the Content-Length (as it is
unknown), but the returned http message does not use chunked encoding like
it should (so I understand). In the response Content-Length is not in the
header and neither is Transfer-Encoding. The body is written directly as if
Content-Length was set.

It is a problem for me as my client assumes that if the content length is
not set then the response is chunked - and then gets confused looking for
the chunk length (perhaps the client should be more robust) .

I am using jetty 6.1.14 (a custom server based on org.mortbay.jetty.Server).
Originally I was using 6.1.0, but saw in the change logs a mention of what
looked to be a similar issues and upgraded, but it did not help. Thoughts
appreciated,

thanks,

mike

[jetty-discuss] Jetty-7 jaspi update

[David J. <dav...@ya...>]

I reviewed the state of the jaspi integration in the jetty7-jaspi  
branch and updated it a bit, while integrating these changes into  
geronimo (sandbox).  The geronimo integration is now using the  
ServerAuthentication interface I proposed and everything seems to be  
working ok.

I made some changes...

1. AuthenticationManager is still less that satisfactory.  I updated  
it so that its parameterized with T and has a method T  
getServerAuthentication().  This lets us replace the silly

((AbstractAuthenticationManager)authManager).validateRequest(...) call  
with authManager.getServerAuthentication().validateRequest(...).  This  
is not too bad but...

2. I reimplemented the JaspiAuthenticationManager to use the somewhat  
convoluted spec method of getting a ServerAuthContext.  This requires  
a whole different set of parameters than the  
DefaultAuthenticationManager.... actually mostly the ContextRoot for  
the web app.  I think that perhaps subclassing  
DefaultAuthenticationManager is better, I'll think about this some  
more.  Anyway there isn't any way that I know of right now to use  
jaspi....

3. deprecated the sample auth modules that implement the built in auth  
methods.  No one should use these except as examples.  I also think  
the CredentialValidationCallback is not useful....  
PasswordValidationCallback is required by the spec and I hope anyone  
implementing a jetty specific auth method will use the  
ServerAuthentication interface rather than the jaspi stuff.  If they  
want jaspi for portability they need to use the PVC from the spec.  I  
think we should move these back to being spec auth modules and maybe  
put them in some kind of samples subproject.

yet to do:

I think it might be a good idea to have an easy way to deploy a single  
ServerAuthModule without a whole jaspi implementation.
I think we can simplify the AuthenticationManager implementations a  
bit more, and deployment isn't completely implemented yet.
I doubt I'll have time to test the jaspi impl against a complete jaspi  
impl (from geronimo components).

Hopefully this is coherent enough to be of some value :-)
thanks
david jencks

Re: [jetty-discuss] POST Encoding Problem after Jetty Upgrade

[Chris H. <ch...@ha...>]

On Friday, January 9, 2009 at 12:28:27 AM, Simone Bordet wrote:
.
> I think most (if not all) modern browsers encode form data using the
> charset of the page they received, so if you specify the charset in
> the form page, you know which charset to set in the request on server
> side.


The only certain way of getting the encoding you want from all browsers is to use <form ... accept-charset='UTF-8'> </form>

Chris

Re: [jetty-discuss] POST Encoding Problem after Jetty Upgrade

[Simone B. <sim...@gm...>]

Hi,

On Fri, Jan 9, 2009 at 00:42, Adam Augusta <ro...@gm...> wrote:
> Hi Simon,
>
> Thank you very much for following up with the info.  I'll repost at
> the other list.
>
>> Can you post the value of the file.encoding system property ?
>> I'm trying to exclude the fact that you only get the garbling because
>> you print on the console.
>
> A runtime check of the file.encoding property shows that the
> file.encoding property is "UTF-8".  FYI, the "(c)" in my e-mail is
> GMail's substitute for the actual copyright symbol.
>
> Something pertinent I forgot to mention:
> I used Fiddler2 to hijack the HTTP request body.  I found that if I
> took the line:
> Content-Type: application/x-www-form-urlencoded
> and changed it to:
> Content-Type: application/x-www-form-urlencoded; Charset=utf-8
>
> ... then the request was interpreted correctly.  Browsers don't
> support this behavior -- I get the impression that UTF-8 is assumed.

This is a general problem of protocols that, failing to specify the
encoding in which they send bytes, can only expect the server to do
reasonable guesses.
Lacking this encoding information, Jetty assumes ISO-8859-1 (which is,
most of the times, a correct guess but, most important IIRC, it is
mandated by the servlet specification because it is the default
charset of HTTP 1.1).
In your case the guess is wrong, and the reason of your garbling.

You should call request.setCharacterEncoding("UTF-8") before you
attempt to first read any parameter from the request. This may be done
in a servlet filter.

I think most (if not all) modern browsers encode form data using the
charset of the page they received, so if you specify the charset in
the form page, you know which charset to set in the request on server
side.

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Re: [jetty-discuss] POST Encoding Problem after Jetty Upgrade

[Adam A. <ro...@gm...>]

Hi Simon,

Thank you very much for following up with the info.  I'll repost at
the other list.

> Can you post the value of the file.encoding system property ?
> I'm trying to exclude the fact that you only get the garbling because
> you print on the console.

A runtime check of the file.encoding property shows that the
file.encoding property is "UTF-8".  FYI, the "(c)" in my e-mail is
GMail's substitute for the actual copyright symbol.

Something pertinent I forgot to mention:
I used Fiddler2 to hijack the HTTP request body.  I found that if I
took the line:
Content-Type: application/x-www-form-urlencoded
and changed it to:
Content-Type: application/x-www-form-urlencoded; Charset=utf-8

... then the request was interpreted correctly.  Browsers don't
support this behavior -- I get the impression that UTF-8 is assumed.

-Adam

Re: [jetty-discuss] POST Encoding Problem after Jetty Upgrade

[Simone B. <sim...@gm...>]

Hi,

first of all you may want to use the CodeHaus mailing lists, as the
SourceForge ones are being discontinued.
More information here:
http://docs.codehaus.org/display/JETTY/Jetty+Wiki (scroll one page).

On Thu, Jan 8, 2009 at 21:50, Adam Augusta <ro...@gm...> wrote:
> I'm having an encoding issue after upgrading from Jetty 6.1.11 to
> Jetty 6.1.14.  Text data submitted via POST no longer gets
> interpretted as UTF-8.  If I post "Héy." the request object gives me
> "HÃ(c)y." in the resultant Java string.
>
> I get the same problem with Jetty 6.1.12.  Reverting to Jetty 6.1.11
> fixes the problem.  I tried adding
> "-Dorg.mortbay.util.URI.charset=utf-8" to my VM parameters with no
> luck.  I intercepted the HTTP request with Fiddler2 (MS proxy), and
> the correct bytes are encoded in the request.  (Fiddler2 also
> correctly identifies the post data as "Héy.")  Also, explicitly
> setting the enctype and the accept-charset attributes on the Form
> didn't help.
>
> I've included a simplified version of the web page and the controller
> code below.  Does anyone have any suggestions?  Is this a bug in Jetty
> or a configuration issue?
>
> Web page:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <title>Submission to check encoding</title><meta content="text/html;
> Charset=utf-8" http-equiv="content-type" />
> </head><body>
> <form method="post"
> action="/www.einvite.com-6.0-SNAPSHOT/email/wording" id="theForm">
> <textarea name="testText" id="group1" rows="3" cols="40">Héy.</textarea>
> <input name="textSubmit" id="textSubmit" value="Submit Text" type="submit" />
> </form>
> </body>
> </html>
>
> Controller method: (Spring 2.5 gives the request object to the method):
>    @RequestMapping(value = "/texttest", method = RequestMethod.POST)
>    public String postTestText(final HttpServletRequest request) {
>        final String testText = request.getParameter("testText");
>        System.out.println("Text text: " + testText);
>        return "testText";
>    }

Can you post the value of the file.encoding system property ?
I'm trying to exclude the fact that you only get the garbling because
you print on the console.

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

[jetty-discuss] POST Encoding Problem after Jetty Upgrade

[Adam A. <ro...@gm...>]

I'm having an encoding issue after upgrading from Jetty 6.1.11 to
Jetty 6.1.14.  Text data submitted via POST no longer gets
interpretted as UTF-8.  If I post "Héy." the request object gives me
"HÃ(c)y." in the resultant Java string.

I get the same problem with Jetty 6.1.12.  Reverting to Jetty 6.1.11
fixes the problem.  I tried adding
"-Dorg.mortbay.util.URI.charset=utf-8" to my VM parameters with no
luck.  I intercepted the HTTP request with Fiddler2 (MS proxy), and
the correct bytes are encoded in the request.  (Fiddler2 also
correctly identifies the post data as "Héy.")  Also, explicitly
setting the enctype and the accept-charset attributes on the Form
didn't help.

I've included a simplified version of the web page and the controller
code below.  Does anyone have any suggestions?  Is this a bug in Jetty
or a configuration issue?

Web page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Submission to check encoding</title><meta content="text/html;
Charset=utf-8" http-equiv="content-type" />
</head><body>
<form method="post"
action="/www.einvite.com-6.0-SNAPSHOT/email/wording" id="theForm">
<textarea name="testText" id="group1" rows="3" cols="40">Héy.</textarea>
<input name="textSubmit" id="textSubmit" value="Submit Text" type="submit" />
</form>
</body>
</html>

Controller method: (Spring 2.5 gives the request object to the method):
    @RequestMapping(value = "/texttest", method = RequestMethod.POST)
    public String postTestText(final HttpServletRequest request) {
        final String testText = request.getParameter("testText");
        System.out.println("Text text: " + testText);
        return "testText";
    }

Re: [jetty-discuss] [jetty-dev] Jetty @ Eclipse ?

[Greg W. <gr...@mo...>]

Thanks all for the many (mostly positive) private responses
received to this post.   However, it would be valuable if
people could post their thoughts to the lists so that others
could see their concerns and/or otherwise.

cheers

Re: [jetty-discuss] Jetty @ Eclipse ?

[Greg W. <gr...@mo...>]

Juancarlo Añez wrote:
> Greg,
> 
> On my part, it's your call.
> 
> One of the risks I see is that eclipsefying Jetty could make it more
> complex, when one of the hallmarks of Jetty is simplicity and minimalism.

Juancarlo,

that indeed was one of my initial fears - that eclipse would expect changes
to the core of Jetty and perhaps OSGi dependencies.

But in my discussions with them, it has become clear that they truly are
component minded, and that while they are keen for Jetty to better work
with OSGi, they are not about to insist that we change the core.

However, I actually see the effort to become more OSGi friendly as a way
to increase the simplicity and minimalism of Jetty.    Building Jetty
as an app server tends to allow extra dependencies to develop and we've
probably made a few packaging mistakes in the past with Jetty.

Renewing our focus on components, will mean that we need to cleanup
those dependencies and packaging somewhat, so that Jetty - already very
modular - will become even more so.

I see the focus of the project at eclipse would be to build great
HTTP and servlet components.

The Jetty hightide project would remain at codehaus and would be focused
on providing a great application server, built from the eclipse (and other)
components.

cheers

Re: [jetty-discuss] Jetty @ Eclipse ?

[Juancarlo A. <ap...@gm...>]

Greg,

On my part, it's your call.

One of the risks I see is that eclipsefying Jetty could make it more
complex, when one of the hallmarks of Jetty is simplicity and minimalism.

Juanca
--
Juancarlo Añez
-
http://www.neogeny.org
http://blog.neogeny.org 
mailto:ju...@ne...
---  

> -----Original Message-----
> From: Greg Wilkins [mailto:gr...@mo...] 
> Sent: Friday, December 05, 2008 6:22 AM
> To: Discussion for Jetty development.; jetty-dev; jetty-user; 
> jetty-announce
> Subject: [jetty-discuss] Jetty @ Eclipse ?
> 
> 
> Dear Jetty committers, contributors & community,
> 
> It has been suggested that the Jetty project submit a proposal to move
> to the Eclipse foundation.  This is an suggestion that I 
> believe should
> be given serious consideration as I can see benefits for all the
> stakeholders.
> 
> The Eclipse foundation is about much more than the Eclipse 
> IDE.  Through
> it's equinox, OSGi and runtime efforts, it is an open source 
> foundation
> very much committed to providing the legal, procedural and technical
> infrastructure for component based software, developed by 
> communities and
> used by everyone from hobbyists through enterprises.
> 
> The Jetty project is a successful HTTP server and servlet container,
> developed by communities, with a component-based OSGi-friendly
> architecture, used by hundreds of thousands of websites and embedded
> in many many projects and products: not least the Eclipse IDE and
> equinox runtime.
> 
> There are obvious synergies between Eclipse and Jetty, thus we have
> already responded to the suggestion with some preliminary discussions
> as to how Jetty @ Eclipse could work:
> 
>   + The Jetty 6.x version would not be effected. It would remain
>     at codehaus and would continue to be maintained for some time.
> 
>   + The upcoming Jetty 7.x version for servlet-3.0 be hosted 
> by Eclipse
>     and would be dual licensed with both the current Apache 
> 2.0 license
>     and the Eclipse Public License (EPL).
> 
>   + Copyright assignment would remain as they are and the contributor
>     license agreements would be updated, probably remaining 
> substantially
>     on the lines of the apache contributors agreement, but 
> with aspects
>     of the Eclipse as well.
> 
>   + The project leadership would essentially remain the same,
>     but with perhaps a little less despotic power.
> 
>   + The core jetty source would be updated to use an org.eclipse
>     package hierarchy.
> 
>   + Some contrib packages and bundles would remain at codehaus
>     (eg grizzly, ant, hightide) or be offered to the related
>     projects (eg cometd to dojo, jboss integration to redhat).
>     Potentially hightide @ codehaus could receive more focus
>     as the app server bundle of Jetty, while jetty @ eclipse
>     would be the component based core.
> 
>   + The project would continue under the current leadership, with
>     some assistance from Eclipse sponsors.  I intend to
>     continue to lead the project for the foreseeable
>     future.
> 
> Importantly, Jetty @ eclipse would
> 
>   - not be dependent on OSGi.  Jetty is already OSGi friendly and I
>     would expect it to become more so. But Jetty will remain
>     framework neutral and the components will continue to be
>     able to be assembled with your choice of java, jetty XML,
>     spring, OSGi, plexus, xbean, geronimo, jboss, Jonas,
>     groovy, etc. etc.
> 
>   - not be a commercial deal. No payments or contracts would be
>     involved. Obviously the key contributors (eg webtide) do not
>     see such a move as harmful to their commercial interests, but the
>     deal would not change the fact that those contributors would still
>     need to find clients and sell them their particular value
>     add with regards to the project.
> 
>   - not be the creation of an Eclipse Java EE application server.
>     Jetty would continue to be a component that integrates
>     well with many many software projects, including most
>     Java EE application servers.
> 
> So is there a need to move or change? Why can't Jetty just
> stay at codehaus and continue as a  despotocracy?
> 
> Well, we could just stay. but I think we would be leaving
> a great opportunity on the table if we did so. An opportunity
> that I see as having very little downside for the project
> or the community.
> 
> The key opportunity of a move to Eclipse is to grow the
> Jetty community and a growing community is good for all
> parties as it:
> 
>   + brings new use-cases and ideas to the project.
> 
>   + brings new potential contributors and resources.
> 
>   + provides increased opportunities for contributors
>     to make a commercial return on their investment in the
>     project, and thus in turn invest more in the project.
> 
>   + maintains momentum and activity to avoid the project
>     stagnating.
> 
> I believe that a move to Eclipse will grow the Jetty
> community for a number of reasons:
> 
>   + Publicity of the change and use of the Eclipse brand.
> 
>   + The addition of the choice of the EPL
> 
>   + Closer relationships with the growing OSGi communities
> 
>   + Diminishing the perception that Jetty is a 1 man or
>     1 company project ( although I plan to continue to
>     lead the project for the foreseeable future).
> 
>   + Improved quality through more rigorous release policies
>     and procedures.
> 
>   + Improved legal status through the foundations due
>     diligence and procedures.
> 
> Additional positives from such a move would be:
> 
>   + taking the opportunity of repackaging to fix some
>     bad practises (eg packages split over jars).
> 
>   + potentially some greater gravitas when representing
>     the projects interests in standards bodies etc.
> 
>   + the opportunity to help drive the OSGi standards
>     past the 2.4 servlet spec.
> 
> So what would be the down side of this?
> 
>   - There will be a bit more procedure and process needed
>     before making releases.  Considering the dufas 6.1.12
>     release, this is a good thing for the community and
>     will only be a cost to the core contributors.
> 
>   - Developers will need to change their code to use
>     the org.eclipse packages.   But this will be done
>     with the move to jetty 7, which will require some
>     API changes anyway, and tools can be provided to
>     ease the change.    We will also take the opportunity
>     to fix some of the incorrect packaging issues that
>     have developed over the years.
> 
>   - There will be the faff of moving mailing lists and
>     websites etc.  But I'm hoping that there may be some
>     additional resources available to help improve the
>     website.
> 
>   - We will be substantially moving away from codehaus,
>     who have provided us with a home for many years.
>     However, potentially there could be more focus on
>     Hightide @ codehaus as the app server distro of jetty.
> 
>   - I don't know? you tell me? What other issues
>     do you see or concerns do you have,  if we were to
>     move the project to Eclipse?
> 
> 
> The process of a move to Eclipse would be that after
> soliciting feedback from yourselves I will then
> solicit feedback from the jetty community.
> 
> I would prepare a proposal to be presented to the Eclipse
> foundation in January 2009.   If accepted, we would target
> EclipseCon in March for the code to be moved
> to Eclipse, with a target stable release of Jetty 7
> in time for JavaOne in June.
> 
> If any of you have explicitly maintained the copyright
> of code contributed to Jetty, then I would like to seek
> your confirmation that dual licensing with the EPL.
> 
> Thanks again for your contributions to this project
> and I hope that together we can continue to make Jetty
> a quality software component used by many.
> 
> regards
> 
> 
> 
> 
> --------------------------------------------------------------
> ----------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las 
> Vegas, Nevada.
> The future of the web can't happen without you.  Join us at 
> MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009
> .visitmix.com/
> _______________________________________________
> jetty-discuss mailing list
> jet...@li...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss

[jetty-discuss] Jetty @ Eclipse ?

[Greg W. <gr...@mo...>]

Dear Jetty committers, contributors & community,

It has been suggested that the Jetty project submit a proposal to move
to the Eclipse foundation.  This is an suggestion that I believe should
be given serious consideration as I can see benefits for all the
stakeholders.

The Eclipse foundation is about much more than the Eclipse IDE.  Through
it's equinox, OSGi and runtime efforts, it is an open source foundation
very much committed to providing the legal, procedural and technical
infrastructure for component based software, developed by communities and
used by everyone from hobbyists through enterprises.

The Jetty project is a successful HTTP server and servlet container,
developed by communities, with a component-based OSGi-friendly
architecture, used by hundreds of thousands of websites and embedded
in many many projects and products: not least the Eclipse IDE and
equinox runtime.

There are obvious synergies between Eclipse and Jetty, thus we have
already responded to the suggestion with some preliminary discussions
as to how Jetty @ Eclipse could work:

  + The Jetty 6.x version would not be effected. It would remain
    at codehaus and would continue to be maintained for some time.

  + The upcoming Jetty 7.x version for servlet-3.0 be hosted by Eclipse
    and would be dual licensed with both the current Apache 2.0 license
    and the Eclipse Public License (EPL).

  + Copyright assignment would remain as they are and the contributor
    license agreements would be updated, probably remaining substantially
    on the lines of the apache contributors agreement, but with aspects
    of the Eclipse as well.

  + The project leadership would essentially remain the same,
    but with perhaps a little less despotic power.

  + The core jetty source would be updated to use an org.eclipse
    package hierarchy.

  + Some contrib packages and bundles would remain at codehaus
    (eg grizzly, ant, hightide) or be offered to the related
    projects (eg cometd to dojo, jboss integration to redhat).
    Potentially hightide @ codehaus could receive more focus
    as the app server bundle of Jetty, while jetty @ eclipse
    would be the component based core.

  + The project would continue under the current leadership, with
    some assistance from Eclipse sponsors.  I intend to
    continue to lead the project for the foreseeable
    future.

Importantly, Jetty @ eclipse would

  - not be dependent on OSGi.  Jetty is already OSGi friendly and I
    would expect it to become more so. But Jetty will remain
    framework neutral and the components will continue to be
    able to be assembled with your choice of java, jetty XML,
    spring, OSGi, plexus, xbean, geronimo, jboss, Jonas,
    groovy, etc. etc.

  - not be a commercial deal. No payments or contracts would be
    involved. Obviously the key contributors (eg webtide) do not
    see such a move as harmful to their commercial interests, but the
    deal would not change the fact that those contributors would still
    need to find clients and sell them their particular value
    add with regards to the project.

  - not be the creation of an Eclipse Java EE application server.
    Jetty would continue to be a component that integrates
    well with many many software projects, including most
    Java EE application servers.

So is there a need to move or change? Why can't Jetty just
stay at codehaus and continue as a  despotocracy?

Well, we could just stay. but I think we would be leaving
a great opportunity on the table if we did so. An opportunity
that I see as having very little downside for the project
or the community.

The key opportunity of a move to Eclipse is to grow the
Jetty community and a growing community is good for all
parties as it:

  + brings new use-cases and ideas to the project.

  + brings new potential contributors and resources.

  + provides increased opportunities for contributors
    to make a commercial return on their investment in the
    project, and thus in turn invest more in the project.

  + maintains momentum and activity to avoid the project
    stagnating.

I believe that a move to Eclipse will grow the Jetty
community for a number of reasons:

  + Publicity of the change and use of the Eclipse brand.

  + The addition of the choice of the EPL

  + Closer relationships with the growing OSGi communities

  + Diminishing the perception that Jetty is a 1 man or
    1 company project ( although I plan to continue to
    lead the project for the foreseeable future).

  + Improved quality through more rigorous release policies
    and procedures.

  + Improved legal status through the foundations due
    diligence and procedures.

Additional positives from such a move would be:

  + taking the opportunity of repackaging to fix some
    bad practises (eg packages split over jars).

  + potentially some greater gravitas when representing
    the projects interests in standards bodies etc.

  + the opportunity to help drive the OSGi standards
    past the 2.4 servlet spec.

So what would be the down side of this?

  - There will be a bit more procedure and process needed
    before making releases.  Considering the dufas 6.1.12
    release, this is a good thing for the community and
    will only be a cost to the core contributors.

  - Developers will need to change their code to use
    the org.eclipse packages.   But this will be done
    with the move to jetty 7, which will require some
    API changes anyway, and tools can be provided to
    ease the change.    We will also take the opportunity
    to fix some of the incorrect packaging issues that
    have developed over the years.

  - There will be the faff of moving mailing lists and
    websites etc.  But I'm hoping that there may be some
    additional resources available to help improve the
    website.

  - We will be substantially moving away from codehaus,
    who have provided us with a home for many years.
    However, potentially there could be more focus on
    Hightide @ codehaus as the app server distro of jetty.

  - I don't know? you tell me? What other issues
    do you see or concerns do you have,  if we were to
    move the project to Eclipse?


The process of a move to Eclipse would be that after
soliciting feedback from yourselves I will then
solicit feedback from the jetty community.

I would prepare a proposal to be presented to the Eclipse
foundation in January 2009.   If accepted, we would target
EclipseCon in March for the code to be moved
to Eclipse, with a target stable release of Jetty 7
in time for JavaOne in June.

If any of you have explicitly maintained the copyright
of code contributed to Jetty, then I would like to seek
your confirmation that dual licensing with the EPL.

Thanks again for your contributions to this project
and I hope that together we can continue to make Jetty
a quality software component used by many.

regards

Re: [jetty-discuss] About BoundedThreadPool.dispatch implementation

[Jesse M. <jes...@gm...>]

two things

1) this list is not being used anymore, use the
us...@je...(this is cc'd there)

2) BoundedThreadPool has been deprecated in favor of QueuedThreadPool so
give that a whirl :)

cheers!
jesse

On Wed, Oct 29, 2008 at 8:28 AM, Aleksi Kallio <ale...@cs...> wrote:

> Hi,
>
> > Of course testing will reveal if updating from 6.1.1 to 6.1.12 will
> > resolve the issue, but as it is quite laborous to reproduce and not very
> > repeatable, it would be nice to know a bit more about what has happened
> > at the code level.
>
> We did now some testing. We have one Jetty instance, serving HTTP and
> acting as a file broker in our system. It is an embedded Jetty with
> default settings.
>
> When we hit 6.1.1 it with requests from 10 machines we get "dispatch
> failed", and the socket closes. After updating to 6.1.11 there is no
> "dispatch failed", but unfortunately Jetty is stuck anyway.
>
> I will keep reading the BoundedThreadPool source code and try to figure
> out what is wrong. Also we will redo the testing with debug logging
> enabled.
>
> All suggestions are of course warmly welcome. :)
>
> Cheers,
> Aleksi
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> jetty-discuss mailing list
> jet...@li...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>



-- 
jesse mcconnell
jes...@gm...

Re: [jetty-discuss] About BoundedThreadPool.dispatch implementation

[Aleksi K. <ale...@cs...>]

Hi,

> Of course testing will reveal if updating from 6.1.1 to 6.1.12 will
> resolve the issue, but as it is quite laborous to reproduce and not very
> repeatable, it would be nice to know a bit more about what has happened
> at the code level.

We did now some testing. We have one Jetty instance, serving HTTP and 
acting as a file broker in our system. It is an embedded Jetty with 
default settings.

When we hit 6.1.1 it with requests from 10 machines we get "dispatch 
failed", and the socket closes. After updating to 6.1.11 there is no 
"dispatch failed", but unfortunately Jetty is stuck anyway.

I will keep reading the BoundedThreadPool source code and try to figure 
out what is wrong. Also we will redo the testing with debug logging enabled.

All suggestions are of course warmly welcome. :)

Cheers,
Aleksi

[jetty-discuss] About BoundedThreadPool.dispatch implementation

[Aleksi K. <ale...@cs...>]

Hello,

We have been experiencing problems with Jetty (version 6.1.1), where 
high traffic hangs to whole server. The exact cause is dispatch method 
in BoundedThreadPool returning false, and making the socket connector to 
close itself. The server is left running, but with no server sockets 
listening to requests.

I see that the implementation of dispatch method has changed a lot in 
the newer versions. Has it been changed to improve stability?

Of course testing will reveal if updating from 6.1.1 to 6.1.12 will 
resolve the issue, but as it is quite laborous to reproduce and not very 
repeatable, it would be nice to know a bit more about what has happened 
at the code level.

Cheers,
Aleksi

Re: [jetty-discuss] Fwd: forward requests to a different server?

[Gleb R. <gr...@gm...>]

Thank you, David.

What about the clain on the main jetty page that it has a forward (proxy)
feature: http://www.mortbay.com/software/Jetty.html#Forwarding

How is that done via a config file? Thanks!
Gleb.

On Mon, Oct 6, 2008 at 2:49 AM, David Yu <dy...@we...> wrote:

> See
>
> http://svn.codehaus.org/jetty/jetty/trunk/modules/extra/jetty-servlet/src/main/java/org/mortbay/servlet/ProxyServlet.java
> You could customize it to make it work for your needs.  (line 101 to 104)
>
> Then you could add that in your jetty.xml
>
>    <New class="org.mortbay.jetty.servlet.Context">
>      <Arg><Ref id="Contexts"/></Arg>
>      <Arg>/</Arg>
>      <Call name="addServlet">
>        <Arg>org.mortbay.servlet.ProxyServlet</Arg>
>        <Arg>/patha/*</Arg>
>      </Call>
>    </New>
>
> Hope that helps,
> dyu
>
> Gleb Rybkin wrote:
> >
> >
> > ---------- Forwarded message ----------
> > From: *Gleb Rybkin* <gr...@gm... <mailto:gr...@gm...>>
> > Date: Sat, Oct 4, 2008 at 9:10 AM
> > Subject: forward requests to a different server?
> > To: jet...@li...
> > <mailto:jet...@li...>
> >
> >
> > Hello,
> >
> > The front jetty page clearly says that it's possible to forward
> > requests to a different server, but I can't find any examples on how
> > to do so in the config files (jetty.xml).
> >
> > I'd like to be able to forward (proxy) requests made to
> > http://www.servera.com/patha to http://www.serverb.com/pathb
> >
> > Can anybody help?
> >
> > Thanks,
> > Gleb.
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > jetty-discuss mailing list
> > jet...@li...
> > https://lists.sourceforge.net/lists/listinfo/jetty-discuss
> >
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> jetty-discuss mailing list
> jet...@li...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>

Re: [jetty-discuss] Fwd: forward requests to a different server?

[David Yu <dy...@we...>]

See 
http://svn.codehaus.org/jetty/jetty/trunk/modules/extra/jetty-servlet/src/main/java/org/mortbay/servlet/ProxyServlet.java
You could customize it to make it work for your needs.  (line 101 to 104)

Then you could add that in your jetty.xml

    <New class="org.mortbay.jetty.servlet.Context">
      <Arg><Ref id="Contexts"/></Arg>
      <Arg>/</Arg>
      <Call name="addServlet">
        <Arg>org.mortbay.servlet.ProxyServlet</Arg>
        <Arg>/patha/*</Arg>
      </Call>
    </New>

Hope that helps,
dyu

Gleb Rybkin wrote:
>
>
> ---------- Forwarded message ----------
> From: *Gleb Rybkin* <gr...@gm... <mailto:gr...@gm...>>
> Date: Sat, Oct 4, 2008 at 9:10 AM
> Subject: forward requests to a different server?
> To: jet...@li... 
> <mailto:jet...@li...>
>
>
> Hello,
>
> The front jetty page clearly says that it's possible to forward 
> requests to a different server, but I can't find any examples on how 
> to do so in the config files (jetty.xml).
>
> I'd like to be able to forward (proxy) requests made to 
> http://www.servera.com/patha to http://www.serverb.com/pathb
>
> Can anybody help?
>
> Thanks,
> Gleb.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> jetty-discuss mailing list
> jet...@li...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>   

[jetty-discuss] Fwd: forward requests to a different server?

[Gleb R. <gr...@gm...>]

---------- Forwarded message ----------
From: Gleb Rybkin <gr...@gm...>
Date: Sat, Oct 4, 2008 at 9:10 AM
Subject: forward requests to a different server?
To: jet...@li...


Hello,

The front jetty page clearly says that it's possible to forward requests to
a different server, but I can't find any examples on how to do so in the
config files (jetty.xml).

I'd like to be able to forward (proxy) requests made to
http://www.servera.com/patha to http://www.serverb.com/pathb

Can anybody help?

Thanks,
Gleb.

[jetty-discuss] deadlock between org.mortbay.component.Container and org.mortbay.management.MBeanContainer

[Henning B. <hen...@gm...>]

Hi,

  I observed a deadlock in Jetty 6.1.0, actually twice, but 
unfortunately I didn't manage to reproduce it today and didn't keep the 
stack traces (but at least I saw them). Thought I can explain it 
nevertheless. Btw. I think the relevant code did not change in later 
6.1.x releases. Ok, here it is:

  When using Jetty's org.mortbay.management.MBeanContainer, e.g. via a 
jetty.xml like this one:

<Configure class="org.mortbay.jetty.Server">
<!-- ... -->

    <!-- initialize the Jetty MBean container -->
    <Get name="container">
        <Call name="addEventListener">
            <Arg>
                <New class="org.mortbay.management.MBeanContainer">
                    <Arg>
                        <Ref id="MBeanServer" />
                    </Arg>
                    <Call name="start" />
                </New>
            </Arg>
        </Call>
    </Get>

<!-- .. -->

the MBean container gets registered with an 
org.mortbay.component.Container. Now, in the MBeanContainer 
implementation, at line 171, within the synchronized removeBean() 
method, it calls the Container instances synchronized method  update(...).

It seems that when starting a web app, while another webapp is stopping, 
this can lead to a deadlock, as AbstractHandler calls 
Container.removeBean (which is not synchronized, just as 
Container.addBean) that calls MBeanContainer.removeBean (that is 
synchronized) which in turn calls Container.update (which is 
synchronized). So that thread locks MBeanContainer and tries to lock 
Container.

Another thread may have entered the scenery via Container.update 
(synchronized), for example via ContextHandler, that calls 
Container.remove/addBean and consequently will try to lock 
MBeanContainer by calling MBeanContainer.removeBean (or addBean) and 
we're stuck, since that thread locks Container and waits to lock 
MBeanContainer.

If the call sequence Container-->MBeanContainer can be guaranteed (not 
sure that is true), then making Container.addBean and 
Container.removeBean synchronized should fix that problem - I would guess.

For now, I will simply remove the MbeanContainer from my setup.

Thanks,
  Henning

[jetty-discuss] jetty 6.1.12 rc1

[Greg W. <gr...@we...>]

Jetty 6.1.12 release candidate 1 is now available via http://jetty.mortbay.org

There has been a lot of activity fixing minor bugs and adding some minor
new features and demos.


jetty-6.1.12rc1 1 August 2008
  + Upgrade jsp 2.1 to SJSAS-9_1_02-B04-11_Apr_2008
  + JETTY-319 Get unavailable exception and added startWithUnavailable option
  + JETTY-381 JETTY-622 Multiple Web Application Source Directory
  + JETTY-442 Accessors for mimeType on ResourceHandler
  + JETTY-502 forward of an include should hide include attributes
  + JETTY-562 RewriteHandler support for virtual hosts
  + JETTY-563 GWT OpenRemoteServiceServlet GWT1.5M2+
  + JETTY-564 Consider optionally importing org.apache.jasper.servlet
  + JETTY-571 SelectChannelConnector throws Exception on close on Windows
  + JETTY-596 Proxy authorization support in HttpClient
  + JETTY-599 handle buffers consistently handle invalid index for poke
  + JETTY-603 Handle IPv6 in HttpURI
  + JETTY-605 Added optional threadpool to BayeuxService
  + JETTY-606 better writeTo impl for BIO
  + JETTY-607 Add GigaSpaces session clustering
  + JETTY-610 jetty.class.path not being interpreted
  + JETTY-613 website module now generates site-component for jetty-site
  + JETTY-614 scanner allocated hashmap on every scan
  + JETTY-623 ServletContext.getServerInfo() non compliant
  + JETTY-626 Null protect reading the dtd resource from classloader
  + JETTY-628 Rewrite rule for rewriting scheme
  + JETTY-629 Don't hold timeout lock during expiry call.
  + JETTY-632 OSGi tags for Jetty client
  + JETTY-633 Default form encoding 8859_1 rather than utf-8
  + JETTY-635 Correctly merge request parameters when doing forward
  + JETTY-637 empty date headers throw IllegalArgumentException
  + JETTY-641 JDBC Realm purge cache problem
  + JETTY-642 NPE in LdapLoginModule
  + JETTY-644 LdapLoginModule uses proper filters when searching
  + JETTY-646 Should set Cache-Control header when sending errors to avoid caching
  + JETTY-647 suspended POSTs with binary data do too many resumes
  + JETTY-650 Parse "*" URI for HTTP OPTIONS request
  + JETTY-651 Release resources during destroy
  + JETTY-654 Allow Cometd Bayeux object to be JMX manageable
  + JETTY-655 Support parsing application/x-www-form-urlencoded parameters via http PUT
  + JETTY-656 HttpClient defaults to async mode
  + JETTY-657 Backport jetty-7 sslengine
  + JETTY-658 backport latest HttpClient from jetty-7 to jetty-6
  + JETTY-659 ContentExchange and missing headers in HttpClient
  + JETTY-660 Backported QoSFilter
  + JETTY-663 AbstractDatabaseLoginModule handle not found UserInfo and userName
  + JETTY-665 Support merging class directories
  + JETTY-666 scanTargetPatterns override the values already being set by scanTarget
  + JETTY-667 HttpClient handles chunked content
  + JETTY-669 Http methods other than GET and POST should not have error page content

[jetty-discuss] Fresh eyes for wiki documentation?

[Greg W. <gr...@mo...>]

All,

I've been working on the wiki a bit for the last few days, and would not mind some
fresh eyes checking over the new layout and content.


New/renovated pages include:

   http://docs.codehaus.org/display/JETTY/Suspendable+Requests
   http://docs.codehaus.org/display/JETTY/Quality+of+Service+Filter
   http://docs.codehaus.org/display/JETTY/Building+from+Source
   http://docs.codehaus.org/display/JETTY/Contributing
   http://docs.codehaus.org/display/JETTY/Downloading+Jetty

any/all feedback welcome.


cheers

[jetty-discuss] SSL Close

[Greg W. <gr...@mo...>]

Jesse,

I had a look at the server side of the ssl close, and indeed
we were not running the close hand-shake to completion if we
initialized the close.

attached is a patch that fixes this, but unfortunately breaks the
SSL client tests.   I've run out of time to look at that - hence
I have not committed.

cheers