Any Tutorial about Jetty Sourcecode?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Any Tutorial about Jetty Sourcecode?

Lebing Xie
Hallo,
I am doing some research on Web Application Server, just finished
reading Tomcat source code (with help a book). I found a Jetty-Tutorial
on jetty homepage, but it is about jetty4 and not so concrete.

Is there any more information about it? or what is the most important
difference between TC and Jetty (Structure) and where should I begin my
trip in Jetty world?

Thanx alot for the great work!

ur Lebing



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Greg Wilkins-5

Lebing,

there are no books to help with the code, but I believe it is very straight
forward and have received many comments to that affect.  The Jetty 6 code in
CVS is very clean and simplified.

I think the main differences between TC and Jetty are focus.  Jetty is
focused on being a good HTTP and Servlet component used by applications
or application servers.   TC wants to be a standalone application server
in it's own right.   Many other differences flow from that change of focus.

If you have any more questions, just ask the lists (although my apologies
for the Mort Bay folks being mostly AWOL over the last month....).

regards



Lebing Xie wrote:

> Hallo,
> I am doing some research on Web Application Server, just finished
> reading Tomcat source code (with help a book). I found a Jetty-Tutorial
> on jetty homepage, but it is about jetty4 and not so concrete.
>
> Is there any more information about it? or what is the most important
> difference between TC and Jetty (Structure) and where should I begin my
> trip in Jetty world?
>
> Thanx alot for the great work!
>
> ur Lebing
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

First and foremost, Tomcat is /the/ reference implementation for the
Web-container side of J2EE.  As a meta-specification for common
application services, many of the support services of J2EE (naming,
persistence, transaction management, etc.), apply equally to the
Web-container as they do to the EJB side of the specification.  It is,
therefore, not unreasonable that a stand-alone J2EE compliant
Web-container provide some of these services, though it is otherwise an
incomplete implementation of the full J2EE "application server" stack.
/Jetty-Plus/ provides a similar solution set in this regard...

Regards,

Anthony


Greg Wilkins wrote:

> Lebing,
>
> there are no books to help with the code, but I believe it is very straight
> forward and have received many comments to that affect.  The Jetty 6 code in
> CVS is very clean and simplified.
>
> I think the main differences between TC and Jetty are focus.  Jetty is
> focused on being a good HTTP and Servlet component used by applications
> or application servers.   TC wants to be a standalone application server
> in it's own right.   Many other differences flow from that change of focus.
>
> If you have any more questions, just ask the lists (although my apologies
> for the Mort Bay folks being mostly AWOL over the last month....).
>
> regards
>
>
>
> Lebing Xie wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFC5qJA8KND+nha8AoRAj12AJoDLqO7DllYpFrkOXnYbBcwBxaExwCfaMTc
8B6cbL39YpphxBArkQpfyIw=
=5iUR
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

David Jencks-2
This might be nitpicking but "standalone J2EE compliant Web-container"
is a contradiction in terms.  If it is J2EE compliant, it has ejbs,
connectors, app clients, etc etc.  If its standalone, as defined by the
standalone servlet tck, which is what tomcat is the reference
implementation of, it doesn't need these things.

I think Greg's comment about difference of focus is very accurate.  
Although I still have some minor issues, it is not hard to install
jetty into an alternative component framework, using the frameworks
wiring rather than jetty's.  Trying to do the same with tomcat is many
orders of magnitude harder, due to tomcat's desire to be the universal
framework controlling everything, i.e. an app server.  It's just not a
J2EE app server.

thanks
david jencks

On Jul 26, 2005, at 1:51 PM, Anthony Cook wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Greetings,
>
> First and foremost, Tomcat is /the/ reference implementation for the
> Web-container side of J2EE.  As a meta-specification for common
> application services, many of the support services of J2EE (naming,
> persistence, transaction management, etc.), apply equally to the
> Web-container as they do to the EJB side of the specification.  It is,
> therefore, not unreasonable that a stand-alone J2EE compliant
> Web-container provide some of these services, though it is otherwise an
> incomplete implementation of the full J2EE "application server" stack.
> /Jetty-Plus/ provides a similar solution set in this regard...
>
> Regards,
>
> Anthony
>
>
> Greg Wilkins wrote:
>> Lebing,
>>
>> there are no books to help with the code, but I believe it is very
>> straight
>> forward and have received many comments to that affect.  The Jetty 6
>> code in
>> CVS is very clean and simplified.
>>
>> I think the main differences between TC and Jetty are focus.  Jetty is
>> focused on being a good HTTP and Servlet component used by
>> applications
>> or application servers.   TC wants to be a standalone application
>> server
>> in it's own right.   Many other differences flow from that change of
>> focus.
>>
>> If you have any more questions, just ask the lists (although my
>> apologies
>> for the Mort Bay folks being mostly AWOL over the last month....).
>>
>> regards
>>
>>
>>
>> Lebing Xie wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFC5qJA8KND+nha8AoRAj12AJoDLqO7DllYpFrkOXnYbBcwBxaExwCfaMTc
> 8B6cbL39YpphxBArkQpfyIw=
> =5iUR
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook

David Jencks wrote:
> This might be nitpicking but "standalone J2EE compliant Web-container"
> is a contradiction in terms.  If it is J2EE compliant, it has ejbs,
 >

You're right, it is "nitpicking".  My implication was that it is
compliant with Web-container side of the J2EE stack, being certain
"standard services" compatible with HTTP as well as several other
explicit and implicit APIs.  I was not suggesting that it is "fully J2EE
compliant", which I'm also quite sure I implied where I wrote ''though
it is otherwise an incomplete implementation of the full J2EE
"application server" stack''.

"J2EE" is a meta-specification which specifies several "standard
services" and APIs found in a "J2EE compliant" server, whether that
server is a full or only partial implementation of the complete
meta-spec.  [[ Note that, though not explicitly correct usage, by "J2EE
compliance" here I refer to adherence to one or more of the underlying
specifications of J2EE, not to passing a full TCK battery or qualifying
for the "J2EE" logo appellation. ]]

A complete list of those "standard services" is found in section
J2EE.2.6. of the current 1.4 specification...

> connectors, app clients, etc etc.  If its standalone, as defined by the
> standalone servlet tck, which is what tomcat is the reference
> implementation of, it doesn't need these things.
>

"Apache Tomcat is the servlet container that is used in the official
Reference Implementation for the Java Servlet and JavaServer Pages
technologies." -- Jakarta Tomcat home page

"Tomcat is a free, open-source implementation of Java Servlet and
JavaServer Pages technologies developed under the Jakarta project at the
Apache Software Foundation. Sun adapts and integrates the Tomcat code
base into the J2EE Reference Implementation." -- Sun J2EE download pages

/At its core/, Tomcat is the "official Reference Implementation" for the
Servlet and JSP specifications.  At their cores, these two
specifications explicitly provide the HTTP and HTTPS "J2EE standard
services", along with the Servlet and JSP APIs.  The "Security" standard
service is also an indicated requirement of the Servlet (and by
inheritance, JSP), APIs.

However, looking beyond the bare explicits, the Servlet /specification/
also specifies /Web Applications/.  Concerning /Web Applications/, the
Servlet specification provides that:

"A Web application is a collection of servlets, HTML pages, classes and
_/other resources/ that make up a /complete application/_ on a Web
server." -- Servlet 2.4, SRV.9

Historically (a history which the specification explicitly
acknowledges), those "other resources" include access to data sources,
messaging systems, mail servers, etc., all of which the Servlet
specification implicitly abstracts into "Utility classes".  In any case,
a "stand-alone" Web-container can not be presumed to provide support for
"complete Web applications" if access to such "other resources" are not
somehow supported.

> I think Greg's comment about difference of focus is very accurate.  
> Although I still have some minor issues, it is not hard to install jetty
> into an alternative component framework, using the frameworks wiring
> rather than jetty's.  Trying to do the same with tomcat is many orders
> of magnitude harder, due to tomcat's desire to be the universal
> framework controlling everything, i.e. an app server.  It's just not a
> J2EE app server.
>

Per its intended purpose, and specification adherence, Tomcat is indeed
an "application server", at least with regard to "Web applications".

At its core, /Jetty/ is an HTTP server and "Servlet container".  Just
what /Jetty/ means by "Servlet container" is questionable, since /Jetty/
certainly does not implement the full /Servlet specification/ (as
implied in SRV.9).  When /Jetty/ is compared to /Tomcat/ the comparison
is "apples to oranges", due to the breadth of "Tomcat"; but if only
"names" are to be considered then, in this vein, I agree that Greg's
comments are accurate, their "foci" are different.  However, a more
correct comparison for /Jetty/ is to Coyote+Catalina, which are no more
"orders of magnitude" harder to embed in an application framework than
/Jetty/.  Conversely, when comparing "Tomcat" to "Jetty", it is more
correct to compare to /Jetty-Plus/ which, like /Tomcat/, also "desires
to be an application server", at least with regard to "Web applications".

> thanks
> david jencks
>

Regards,

Anthony Cook

vschade.vcf (226 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

djencks
I apologize most humbly for daring to express my opinion and
experiences in the face of your obviously much greater wisdom and
knowledge.  I will be sure never to find the temerity to do so again.

david jencks

On Jul 26, 2005, at 1:56 PM, Anthony Cook wrote:

>
> David Jencks wrote:
>> This might be nitpicking but "standalone J2EE compliant
>> Web-container" is a contradiction in terms.  If it is J2EE compliant,
>> it has ejbs,
> >
>
> You're right, it is "nitpicking".  My implication was that it is
> compliant with Web-container side of the J2EE stack, being certain
> "standard services" compatible with HTTP as well as several other
> explicit and implicit APIs.  I was not suggesting that it is "fully
> J2EE compliant", which I'm also quite sure I implied where I wrote
> ''though it is otherwise an incomplete implementation of the full J2EE
> "application server" stack''.
>
> "J2EE" is a meta-specification which specifies several "standard
> services" and APIs found in a "J2EE compliant" server, whether that
> server is a full or only partial implementation of the complete
> meta-spec.  [[ Note that, though not explicitly correct usage, by
> "J2EE compliance" here I refer to adherence to one or more of the
> underlying specifications of J2EE, not to passing a full TCK battery
> or qualifying for the "J2EE" logo appellation. ]]
>
> A complete list of those "standard services" is found in section
> J2EE.2.6. of the current 1.4 specification...
>
>> connectors, app clients, etc etc.  If its standalone, as defined by
>> the standalone servlet tck, which is what tomcat is the reference
>> implementation of, it doesn't need these things.
>
> "Apache Tomcat is the servlet container that is used in the official
> Reference Implementation for the Java Servlet and JavaServer Pages
> technologies." -- Jakarta Tomcat home page
>
> "Tomcat is a free, open-source implementation of Java Servlet and
> JavaServer Pages technologies developed under the Jakarta project at
> the Apache Software Foundation. Sun adapts and integrates the Tomcat
> code base into the J2EE Reference Implementation." -- Sun J2EE
> download pages
>
> /At its core/, Tomcat is the "official Reference Implementation" for
> the Servlet and JSP specifications.  At their cores, these two
> specifications explicitly provide the HTTP and HTTPS "J2EE standard
> services", along with the Servlet and JSP APIs.  The "Security"
> standard service is also an indicated requirement of the Servlet (and
> by inheritance, JSP), APIs.
>
> However, looking beyond the bare explicits, the Servlet
> /specification/ also specifies /Web Applications/.  Concerning /Web
> Applications/, the Servlet specification provides that:
>
> "A Web application is a collection of servlets, HTML pages, classes
> and _/other resources/ that make up a /complete application/_ on a Web
> server." -- Servlet 2.4, SRV.9
>
> Historically (a history which the specification explicitly
> acknowledges), those "other resources" include access to data sources,
> messaging systems, mail servers, etc., all of which the Servlet
> specification implicitly abstracts into "Utility classes".  In any
> case, a "stand-alone" Web-container can not be presumed to provide
> support for "complete Web applications" if access to such "other
> resources" are not somehow supported.
>
>> I think Greg's comment about difference of focus is very accurate.  
>> Although I still have some minor issues, it is not hard to install
>> jetty into an alternative component framework, using the frameworks
>> wiring rather than jetty's.  Trying to do the same with tomcat is
>> many orders of magnitude harder, due to tomcat's desire to be the
>> universal framework controlling everything, i.e. an app server.  It's
>> just not a J2EE app server.
>
> Per its intended purpose, and specification adherence, Tomcat is
> indeed an "application server", at least with regard to "Web
> applications".
>
> At its core, /Jetty/ is an HTTP server and "Servlet container".  Just
> what /Jetty/ means by "Servlet container" is questionable, since
> /Jetty/ certainly does not implement the full /Servlet specification/
> (as implied in SRV.9).  When /Jetty/ is compared to /Tomcat/ the
> comparison is "apples to oranges", due to the breadth of "Tomcat"; but
> if only "names" are to be considered then, in this vein, I agree that
> Greg's comments are accurate, their "foci" are different.  However, a
> more correct comparison for /Jetty/ is to Coyote+Catalina, which are
> no more "orders of magnitude" harder to embed in an application
> framework than /Jetty/.  Conversely, when comparing "Tomcat" to
> "Jetty", it is more correct to compare to /Jetty-Plus/ which, like
> /Tomcat/, also "desires to be an application server", at least with
> regard to "Web applications".
>
>> thanks
>> david jencks
>
> Regards,
>
> Anthony Cook
> <vschade.vcf>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Greg Wilkins-5
In reply to this post by Anthony Cook
Anthony Cook wrote:

> At its core, /Jetty/ is an HTTP server and "Servlet container".  Just
> what /Jetty/ means by "Servlet container" is questionable, since /Jetty/
> certainly does not implement the full /Servlet specification/ (as
> implied in SRV.9).

Jetty most certainly does implement the full /Servlet specification/.
While it is not certified as such, it has certainly been well tested
against the specification.

If there are deficiencies, please raise them as bugs and we will comply
with the specification.

regards




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook
Greg,

Didn't mean to offend.  Jetty is a fine piece of work.  However, there
are many cases where Jetty behaves outside the scope of the
specification.  Several of these have been raised recently: session
identification, context separation, and direct handling of certain HTTP
headers are what presently come to mind.  Concerning the last, it was
demonstrated that his behavior differs in Jetty than in the reference
implentation, yet your final position on the matter was that such
demonstrations were irrelevant and you're keeping Jetty the way it is
(which, in fact, is the way it /was/ before a patch was applied which
took Jetty even further out of specification and on which a lengthy
thread of discussion subsequently ensued, though you subsequently
informed us that the patch was being removed).

That's all well and good... some of these issues can be considered
"value adds", and subtle differences in spec. interpretation and
implementation foster healthy competition.  As I said, I find Jetty to
be a fine piece of software, and I continue to use it for a significant
number of projects.  However, where I must be assured of proper spec.
compliance I feel I must pass on Jetty and go with Tomcat or other
certified containers.

Regards,

Anthony Cook


Greg Wilkins wrote:

> Anthony Cook wrote:
>
>
>>At its core, /Jetty/ is an HTTP server and "Servlet container".  Just
>>what /Jetty/ means by "Servlet container" is questionable, since /Jetty/
>>certainly does not implement the full /Servlet specification/ (as
>>implied in SRV.9).
>
>
> Jetty most certainly does implement the full /Servlet specification/.
> While it is not certified as such, it has certainly been well tested
> against the specification.
>
> If there are deficiencies, please raise them as bugs and we will comply
> with the specification.
>
> regards

vschade.vcf (226 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook
In reply to this post by djencks
No appologies necessary... yes, please do express your opinions and
experiences, as is all I do, though you should expect your opinions, at
the least, to be debated, as do I.

"[O]bviously much greater wisdom and knowledge"?  I make no such claim.
  However, I do contend to have a fair understanding of the
specification, as I've immersed myself in it for many years.  Notice I
said "fair understanding", as I also continue to learn "something new"
whenever I take another look at it.  I also happen to believe in strict
adherence to the specification, first and foremost, otherwise its
promises of portability and compatibility are impacted and this hurts
the community, if not the technology, as a whole.  Too much "loose
compliance" and emphasis on "proprietary extension" of a great many
other technology specifications in other platforms has lead to a
plethora of problems that now widely affect those who do not even use
those platforms (like me).  So, I make no qualms and no appologies for
championing strict specification compliance.

"[O]bviously much greater wisdom and knowledge"?  No... less /ignorant/
perhaps and, in light of your response, certainly "more grown up".

All of the preceding is, of course, my /opinion/ and you are certainly
free to debate it.

Anthony Cook


David Jencks wrote:
> I apologize most humbly for daring to express my opinion and experiences
> in the face of your obviously much greater wisdom and knowledge.  I will
> be sure never to find the temerity to do so again.
>
> david jencks
>

vschade.vcf (226 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Niclas Hedhman
On Wednesday 27 July 2005 18:35, Anthony Cook wrote:
> However, I do contend to have a fair understanding of the
> specification, as I've immersed myself in it for many years.

http://www.jcp.org/en/jsr/detail?id=154

To put self-appraisal in perspective, I think Greg has an understanding of the
spefication above and beyond your own home studies.... ;o)

RI != Specification.

It is not uncommon that reference implementations and/or TCK have bugs, and/or
the specification is too unclear and will be clarified in future amendments.
Catagorically saying that, Tomcat is the reference implementation and
therefor by definition does everything correct is ludicrous and makes you
look like a fool to me.
Now, I am not saying that Jetty is implementing the specification better than
Tomcat, as I have not enough knowledge about that, but my experience is that
it IS a magnitude easier to get Jetty to work "anywhere" compared to the
"Catalina+Coyote" combo you mentioned. You are obviously not aware of the
Catalina classloader nightmares you get if you try.

Never the less, Jetty and Tomcat are different and both have their purposes,
and apparently you agree with that.

If you are so concerned about specification adherence, and like Jetty as much
as you say, why don't you take time to help polish off the rough edges that
you claim is there. Putting up "wide" definitions of things that "behaves
outside the scope of the specification" is not about caring, it is close to
instigating FUD and should be avoided. Bring stuff up, one by one and let's
discuss it.


Cheers
Niclas


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Greg Wilkins-5
In reply to this post by Anthony Cook

All,

I would like you to consider the tone and style of your contributions
to this list.    All opinions are welcome, but not in combatative tones.

The Jetty lists have historically been a friendly and cooperative place.
Let's work to keep it that way.

regards



Anthony Cook wrote:

> No appologies necessary... yes, please do express your opinions and
> experiences, as is all I do, though you should expect your opinions, at
> the least, to be debated, as do I.
>
> "[O]bviously much greater wisdom and knowledge"?  I make no such claim.
>  However, I do contend to have a fair understanding of the
> specification, as I've immersed myself in it for many years.  Notice I
> said "fair understanding", as I also continue to learn "something new"
> whenever I take another look at it.  I also happen to believe in strict
> adherence to the specification, first and foremost, otherwise its
> promises of portability and compatibility are impacted and this hurts
> the community, if not the technology, as a whole.  Too much "loose
> compliance" and emphasis on "proprietary extension" of a great many
> other technology specifications in other platforms has lead to a
> plethora of problems that now widely affect those who do not even use
> those platforms (like me).  So, I make no qualms and no appologies for
> championing strict specification compliance.
>
> "[O]bviously much greater wisdom and knowledge"?  No... less /ignorant/
> perhaps and, in light of your response, certainly "more grown up".
>
> All of the preceding is, of course, my /opinion/ and you are certainly
> free to debate it.
>
> Anthony Cook
>
>
> David Jencks wrote:
>
>> I apologize most humbly for daring to express my opinion and
>> experiences in the face of your obviously much greater wisdom and
>> knowledge.  I will be sure never to find the temerity to do so again.
>>
>> david jencks
>>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Greg Wilkins-5
In reply to this post by Anthony Cook

Anthony,

If you have *ANY* examples of where jetty differs from the *SPEC* or
of *ANY* TCK compliance tests that Jetty fails to pass.

There are differences with tomcat, but you have not made your case
that these covered by the specification.    The recent example of
100 continue, is not a specification issue as it is not covered by
the servlet specification at all.

regards


Anthony Cook wrote:

> Greg,
>
> Didn't mean to offend.  Jetty is a fine piece of work.  However, there
> are many cases where Jetty behaves outside the scope of the
> specification.  Several of these have been raised recently: session
> identification, context separation, and direct handling of certain HTTP
> headers are what presently come to mind.  Concerning the last, it was
> demonstrated that his behavior differs in Jetty than in the reference
> implentation, yet your final position on the matter was that such
> demonstrations were irrelevant and you're keeping Jetty the way it is
> (which, in fact, is the way it /was/ before a patch was applied which
> took Jetty even further out of specification and on which a lengthy
> thread of discussion subsequently ensued, though you subsequently
> informed us that the patch was being removed).
>
> That's all well and good... some of these issues can be considered
> "value adds", and subtle differences in spec. interpretation and
> implementation foster healthy competition.  As I said, I find Jetty to
> be a fine piece of software, and I continue to use it for a significant
> number of projects.  However, where I must be assured of proper spec.
> compliance I feel I must pass on Jetty and go with Tomcat or other
> certified containers.
>
> Regards,
>
> Anthony Cook
>
>
> Greg Wilkins wrote:
>
>> Anthony Cook wrote:
>>
>>
>>> At its core, /Jetty/ is an HTTP server and "Servlet container".  Just
>>> what /Jetty/ means by "Servlet container" is questionable, since /Jetty/
>>> certainly does not implement the full /Servlet specification/ (as
>>> implied in SRV.9).
>>
>>
>>
>> Jetty most certainly does implement the full /Servlet specification/.
>> While it is not certified as such, it has certainly been well tested
>> against the specification.
>>
>> If there are deficiencies, please raise them as bugs and we will comply
>> with the specification.
>>
>> regards



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
In reply to this post by Niclas Hedhman
Niclas Hedhman wrote:
> On Wednesday 27 July 2005 18:35, Anthony Cook wrote:
>
> To put self-appraisal in perspective, I think Greg has an understanding of the
> spefication above and beyond your own home studies.... ;o)
>

Yes, I'm sure Greg has an excellent grasp of the spec and I never
disputed whether he does.  So, why bother having these discussions, or
this list for them, at all... we should just wait for the next Jetty
release and see how things are supposed to be. :-/

> RI != Specification.
>

No, RI = "base for implementation comparison".  Comparing an
implementation's behaviour against the "reference implementation" is
part of the "compatibility certification" process.  Well, at least it
/was/ during my time as a J2EE instructor at Sun, though I guess that
("RI part of certification") could have changed in the last three years. :-/

> It is not uncommon that reference implementations and/or TCK have bugs, and/or
> the specification is too unclear and will be clarified in future amendments.
>

Yes, understood... and, so do non-reference implementations: have bugs,
and corrections.

> Catagorically saying that, Tomcat is the reference implementation and
> therefor by definition does everything correct is ludicrous and makes you
> look like a fool to me.
>

Again, someone else taking words out of context. :-/  I never said "it
does everything correct since it is the reference implementation".  I
said, as the reference implementation, it is the standard for
operational comparison.

> If you are so concerned about specification adherence, and like Jetty as much
> as you say, why don't you take time to help polish off the rough edges that
>

Yet, that is what I thought this list was for... to contribute and "help
polish off" through observation, recommendation, and discussion.
Admittedly, I'm not much of a systems programmer, though I like to
"tinker" in that area.  As an applications programmer (yea, I know, just
a weeny compared to all you systems gods :-/ ), I do have to rely on the
platform behaving in accordance with the published specifications... er,
imperfect as they may be, and at least within the limits my own "home
studies" lead me to understand them... for my applications to perform
"correctly".  As a consultant working on a disparity of implementations,
including Jetty, this is even more important to me.  Though, I guess I
have these points wrong too and, so, really have nothing to contribute.

> you claim is there. Putting up "wide" definitions of things that "behaves
>

I made mention of a few issues about which specification adherence was
recently raised, in this forum.  Iow, I made "reference" to something
already put up.

> outside the scope of the specification" is not about caring, it is close to
> instigating FUD and should be avoided. Bring stuff up, one by one and let's
> discuss it.
>

Yes, my nefarious plan to destroy Jetty has been rooted out.

> Cheers
> Niclas
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
In reply to this post by Greg Wilkins-5
Greg Wilkins wrote:
> that these covered by the specification.    The recent example of
> 100 continue, is not a specification issue as it is not covered by
> the servlet specification at all.
>

No, but it is part of the HTTP specification, which the Servlet
specification says the container also "implements", and the thread of
discussion was over how much and to what extent the container handles
HTTP, versus what the servlet handles.  My position is that the Expect
header, regardless of attribute, is to be passed to the servlet
unhandled (the servlet is, afterall, the server "extension").  This I
based on my own testing with Tomcat (as the "reference implementation"),
and Resin (the most widely used OSS implementation per Netcraft).  Your
final position was that Jetty, the servlet container, is to handle
'Expect: 100-continue', so I'm not sure where you're making a
distinction now.  As for other forms of the Expect header, Jetty also
"handles" them, but by returning a 417.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Niclas Hedhman
On Thursday 28 July 2005 22:17, Anthony Cook wrote:

> No, but it is part of the HTTP specification, which the Servlet
> specification says the container also "implements", and the thread of
> discussion was over how much and to what extent the container handles
> HTTP, versus what the servlet handles.

I stayed out of this before as I felt it was a really peripheral subject to my
own concerns.

> My position is that the Expect
> header, regardless of attribute, is to be passed to the servlet
> unhandled (the servlet is, afterall, the server "extension").  This I
> based on my own testing with Tomcat (as the "reference implementation"),
> and Resin (the most widely used OSS implementation per Netcraft)

Ok. The Servlet spec does not explicitly mention this, and IMNSHO that means
that it is "unspecified" and *not* something a portable user can depend on.

You make an lawyer-like line of reasoning that;

 1. Servlet containers must implement HTTP.
 2. Servlets are extensions of the Servlet container (are they?).
 3. Therefor all aspects of HTTP should be accessible to the Servlet.

Well, that is plainly not true for other aspects of the HTTP protocol, port to
be connected to, virtual hosting, forced disconnects between requests and so
forth.

So, the simple answer is that I think you are wrong about your stance, that
compliant implementations must mimic the RI at all times. Bad example of
highlighting the absurdity of requiring independent implementations to
mimickk the RI;
Assuming for a second that Tomcat exposed (for instance, bad classloading
strategy and class is sitting visible in system classloader) some nifty
little util class;

   org.apache.tomcat.util.DoWhatINeed

Does that mean all independent implementations must implement/provide that? If
not, then I can write a Servlet that won't run in another container but the
RI.
Where do you draw the line in the sand, between the above absurd example and
your own interpretation of things that may or may not be implied in the spec
itself? For me the answer is very simple; the specification has 3 states for
any "true or false" asked question;
   true     false    undefined
and for undefined items *compatible* users MUST NOT depend on either the true
or false possibilities.
And hopefully, the community at large can bring the issue(s) in question back
to the Specification group for clarification in either a memorandum or the
next version, and the "undefined" becomes either a "true" or "false".

(Personally, I think the whole Servlet spec needs a massive rewrite, where
content production, connection management and session management (possibly
other areas) are totally separated. But I guess that is more than to hope
for :o( )

Now, OTOH, Jetty's modularity should allow you to exchange the section of code
that does the "continue" handling with your own implementation. I have not
looked at the code in question, but I have been bolting with non-standard
Jetty setups for a while now, and seldom come across anything that requires
more than a day of work.


Cheers
Niclas


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
Niclas Hedhman wrote:

> On Thursday 28 July 2005 22:17, Anthony Cook wrote:
>
>>My position is that the Expect
>>header, regardless of attribute, is to be passed to the servlet
>>unhandled (the servlet is, afterall, the server "extension").  This I
>>based on my own testing with Tomcat (as the "reference implementation"),
>>and Resin (the most widely used OSS implementation per Netcraft)
>
> Ok. The Servlet spec does not explicitly mention this, and IMNSHO that means
> that it is "unspecified" and *not* something a portable user can depend on.
>

Ok.  The Servlet spec. is ''intended to be a clear and complete
explanation of /Java servlets/'', not of HTTP, of which the "clear and
complete explanation" is left to the HTTP specification(s), to which the
Servlet spec. makes reference.  However, to provide a "clear and
complete" explanation of Java servlets by necessity entails specifying
how a servlet or container is to respond to certain aspects of the
referred to specification(s), where such might otherwise be ambiguous.
Is that an unreasonable statement?  Is it too "lawyer-like"?  In this
regard, the specification explicitly states ("specifies") what the
container does handle or do.  What it does not say the container does is
presumed to be left to the servlet.  Or, IYNSHO, is that also incorrect?

> You make an lawyer-like line of reasoning that;
>
>  1. Servlet containers must implement HTTP.
>

No, my reasoning, based on what the specification says, as well as on
historical perspective and intention, is as already stated: the
container handles what is explicitly specified for it to do so, and the
rest is left to the servlet.  Servlet containers, per the specification,
are extensions of a Web server and ''must support HTTP as a protocol for
requests and responses''.  Per the specification, those requests and
responses are handled by the servlet, excepting those aspects which are
not explicitly specified for the container to handle.

>  2. Servlets are extensions of the Servlet container (are they?).
>

No, servlets "extend the functionality of a /Web server/", just as do,
for example, CGI scripts and proprietary extension APIs.  This at least
is what the spec. informed us up until version 2.2, when "servlet
engines" became "servlet containers" and part of not just Web servers
but also "application servers".  Now, based on my "lawyer-like" reading
of the current specification, it is the "servlet container" which
extends the Web server, or application server, by providing ''the
network services over which the requests and responses are sent'' and by
''manag[ing] servlets through their lifecycle''.  However, the
historical perspective of the /servlet/ as being that which actually
provides the server's "extended functionality" has not changed and is
still also maintained by the spec.

>  3. Therefor all aspects of HTTP should be accessible to the Servlet.
>

No, only those aspects not specifically directed to the container, such
as...

> Well, that is plainly not true for other aspects of the HTTP protocol, port to
> be connected to, virtual hosting, forced disconnects between requests and so
> forth.
>

...er, these things, for example.

> So, the simple answer is that I think you are wrong about your stance, that
> compliant implementations must mimic the RI at all times. Bad example of
> highlighting the absurdity of requiring independent implementations to
> mimickk the RI;
>

Then you must also think Sun to be wrong in their stance, no?

''A reference implementation (RI) has been made available which provides
a /behavioral benchmark/ for this specification.  Where the
specification leaves implementation of a particular feature open to
interpretation, implementors may use the reference implementation /as a
model of how to carry out the intention of the specification/.'' --
Servlet Specification 2.4, SRV.P.1, "Additional Sources" [emphasis mine]

> Assuming for a second that Tomcat exposed (for instance, bad classloading
> strategy and class is sitting visible in system classloader) some nifty
> little util class;
>
>    org.apache.tomcat.util.DoWhatINeed
>
> Does that mean all independent implementations must implement/provide that? If
>

No, this is an example of /how/ the specification is being implemented
not /what/ it specifies is to be implemented.  The specification makes
no assumptions on /how/ implementors implement the specification and, in
fact, plainly leaves such details to the implementors.  As well, as is
implied in the preface to the spec, the 'what' of implementation
("behaviors") is intended to be interpreted from the viewpoint of "Java
servlets".  "Java servlets" are written to the specified APIs, not to
any one implementor's APIs.  Implementors APIs, also refered to as
"proprietary extension APIs", are to be avoided by "servlet
programmers", or risk loss of portability.

> not, then I can write a Servlet that won't run in another container but the
> RI.
>

Which is an example of writing to an implementation, and not to the
specification.  Such is, of course, at the discretion of the servlet
writer, but is also recommended against by the specification with
portability in mind.

As J2EE application developers, we are "encouraged" to use the J2EE SDK,
the "reference implementation", as both a platform for developing our
applications and as a benchmark for ensuring specification
compatibility; and, thus, compatibility with "certified"
implementations.  So assuming I do so (use the RI), and my application
works as expected (on the RI), but upon deploying it to a non-RI
implementation it "breaks", with whom do you suggest I raise the issue?
 Or are you suggesting that, in this case, the RI be assumed "faulty"
and I simply start rewriting those aspects of my application which are
broken on the non-RI implementation to "fix" it?

> Where do you draw the line in the sand, between the above absurd example and
> your own interpretation of things that may or may not be implied in the spec
>

With regard to "intention" and "historical perspective" for both
servlets and their "predecessors"; which, interestingly enough, are also
relevant to reading and interpreting the laws of one's society.  I'm
accused of being "lawyer-like" in my reading and interpretation of the
specification, though I rebut that as, rather, simply paying attention
to details.  Yet, the specification is, if I may be indulged the
analogy, the "law" with regard to what it explicitly "intends to clearly
and completely explain".  Conversely, one could say that a societal
"law" -- say, with regard to driving, or paying taxes -- is a
"specification" for how members of its target "community" are to
"behave" with respect to those things which /it/ "intends to clearly and
completely explain".  I don't think someone would accuse me of being too
"technician-like" in reading and interpreting those, though you are
welcome to be the first. :)  Yet, amusingly enough, when trying to point
out "specifics" of behaviour within this "technical community", several
are quick to label me "lawyer-like". :-/


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Niclas Hedhman
On Friday 29 July 2005 03:03, Anthony Cook wrote:
> Niclas Hedhman wrote:

I succumb to sudden-death-by-word-overload ;o)

> Servlet containers, per the specification,
> are extensions of a Web server and ''must support HTTP as a protocol for
> requests and responses''. Per the specification, those requests and
> responses are handled by the servlet, excepting those aspects which are
> not explicitly specified for the container to handle.

Uhhhh.... well, I might be sailing here, but... SRV.1.2. :
"...it may modify requests from the clients before delivering them to the
servlet, may modify responses produced by servlets before sending them to the
clients, or may respond to requests without delivering them to the servlet
under the compliance with RFC2616."

I don't see it fit your description that the container MUST only do what the
servlet specification explicitly tells it to do.

Looking through the archives about the 100-continue issue earlier, I think
Greg's insight is remarkable;
<quote src="Greg" >
Ie if a client send the expectation and does not send the body
until it has a received the 100 response - then 99% of web applications
will fail if run on a jetty that does nothing with this expectation.
</quote>

Although "fail" is a bit strong word, as the RFC2616 says;
<quote src="rfc2616" >
Because of the presence of older implementations, the protocol allows
ambiguous situations in which a client may send "Expect: 100- continue"
without receiving either a 417 (Expectation Failed) status or a 100
(Continue) status. Therefore, when a client sends this header field to an
origin server (possibly via a proxy) from which it has never seen a 100
(Continue) status, the client SHOULD NOT wait for an indefinite period before
sending the request body.
</quote>

It is definately up for interpretation in this case, whether the container
should handle it or pass it on. My guess is also that the RI has not really
investigated the case, and by default it falls through.

> ''A reference implementation (RI) has been made available which provides
> a /behavioral benchmark/ for this specification.  Where the
> specification leaves implementation of a particular feature open to
> interpretation, implementors may use the reference implementation /as a
> model of how to carry out the intention of the specification/.'' --
> Servlet Specification 2.4, SRV.P.1, "Additional Sources" [emphasis mine]

Maybe should have emphasize the "may" word as well.

> > Assuming for a second that Tomcat exposed (for instance, bad classloading
> > strategy and class is sitting visible in system classloader) some nifty
> > little util class;
> >
> >    org.apache.tomcat.util.DoWhatINeed
> >
> > Does that mean all independent implementations must implement/provide
> > that?

> No, this is an example of /how/ the specification is being implemented
> not /what/ it specifies is to be implemented.

You missed the point; "specification leaves implementation of a particular
feature open to interpretation" which is just about everything. Does the
specification mention any casting that can take place? I would assume only
where casting is required/unavoidable, and all other places is "open to
interpretation". I am sure given enough time one can define dozens of "open
to interpretation" where following the RI is not expected or the intent of
the spec.


>Yet, amusingly enough, when trying to point
> out "specifics" of behaviour within this "technical community", several
> are quick to label me "lawyer-like". :-/

Sorry for giving *your reasoning* such a label. Please note I didn't label you
"lawyer-like"...  read the fine print ;o)


I conclude (point of stop thinking) that we are at disagreement, and can live
with that.


Cheers
Niclas


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
Niclas Hedhman wrote:
> On Friday 29 July 2005 03:03, Anthony Cook wrote:
>
>>Niclas Hedhman wrote:
>
> I succumb to sudden-death-by-word-overload ;o)
>

If I bombard, inundate, overwhelm, or otherwise offend with my
expressive verbiage, then feel free to gloss-over, ignore, trash, or
just "give the finger" to my posts, as you wish.  If it is the majority,
or moderator's, wish that I just stop posting all together, then I can
also certainly oblige, and if so then consider this my final adieu...
er, comments.

>>Servlet containers, per the specification,
>>are extensions of a Web server and ''must support HTTP as a protocol for
>>requests and responses''. Per the specification, those requests and
>>responses are handled by the servlet, excepting those aspects which are
>>not explicitly specified for the container to handle.
>
> Uhhhh.... well, I might be sailing here, but... SRV.1.2. :
> "...it may modify requests from the clients before delivering them to the
> servlet, may modify responses produced by servlets before sending them to the
> clients, or may respond to requests without delivering them to the servlet
> under the compliance with RFC2616."
>

I would preface the above by pointing out that this falls under
"Overview", and the rest of the specification provides "details".  I
also point out that the above quotation completely leaves out the
/context/ of what is quoted: "Because the container may have a
/cacheing/ mechanism described in RFC2616(HTTP/1.1),...".

> Looking through the archives about the 100-continue issue earlier, I think
> Greg's insight is remarkable;
> <quote src="Greg" >
> Ie if a client send the expectation and does not send the body
> until it has a received the 100 response - then 99% of web applications
> will fail if run on a jetty that does nothing with this expectation.
> </quote>
>

Ok.  No offense to Greg, or to your apparent admiration of him, but this
seems more like an obvious cause-effect observation to me, than a
"remarkable insight".  In any case, a client that does not send the body
until it has received the 100 response is, as you further pointed out
(just as I believe I at least attempted to do in that previous thread),
is a /client/ that falls out of HTTP spec and has no bearing on the
"server".  Also, as I pointed out previously, the Expect header is
specified (HTTP) as an "extension mechanism", something which I would
expect to be factored in to the application making use of it (i.e.
"application requirements").  I, for one, know of no current, widely
available, /browser/ that makes use of the header for any reason, and
so, based on these last two, it seems pointless for the servlet
container to "support" the header directly... ergo, pass to servlet.

> It is definately up for interpretation in this case, whether the container
> should handle it or pass it on. My guess is also that the RI has not really
> investigated the case, and by default it falls through.
>

OTOH, my expectation is that the RI adheres to what is explicitly
specified.  Though, at least among this crowd, it appears to be just me
who expects as much. :-/

>>''A reference implementation (RI) has been made available which provides
>>a /behavioral benchmark/ for this specification.  Where the
>>specification leaves implementation of a particular feature open to
>>interpretation, implementors may use the reference implementation /as a
>>model of how to carry out the intention of the specification/.'' --
>>Servlet Specification 2.4, SRV.P.1, "Additional Sources" [emphasis mine]
>
> Maybe should have emphasize the "may" word as well.
>

Or, maybe, the spec writers should have used a phrase like "are
recommended to", "are allowed to", or "probably should", all of which
fall under alternative "meaning and usage" of the word "may" (try
dict.org).  They might also have used "must"
(http://dictionary.reference.com/search?q=may), but, no, that would
probably cause the spec. to violate its own "'what', not 'how'"
intention. ~:-/

>>Yet, amusingly enough, when trying to point
>>out "specifics" of behaviour within this "technical community", several
>>are quick to label me "lawyer-like". :-/
>
> Sorry for giving *your reasoning* such a label. Please note I didn't label you
> "lawyer-like"...  read the fine print ;o)
>

Fair enough.

> I conclude (point of stop thinking) that we are at disagreement, and can live
> with that.
>

So, "agree to disagree".  Fair enough.  "Fini."


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Greg Wilkins-5
Anthony Cook wrote:
> If I bombard, inundate, overwhelm, or otherwise offend with my
> expressive verbiage, then feel free to gloss-over, ignore, trash, or
> just "give the finger" to my posts, as you wish.  If it is the majority,
> or moderator's, wish that I just stop posting all together, then I can
> also certainly oblige, and if so then consider this my final adieu...
> er, comments.


Your posts are welcome, but please consider their style as well as their
content etc.  You appear to have got on the wrong side of several other
posters and while it takes two to tango, your dance card does appear very full.


As for the expect 100 discussion, I'm afraid that you simply have not
explained your case well enough.   You advocate that the container does
not handle expectations at all, yet there is NO mechanism for a
servlet to send a 100-continue.   So unless the container sends that
response, you are saying that a servlet container can not work with
a client using that expectation?

I am simply proposing a way that the container can send the 100 continue
response *WHEN* the servlet signals that it wants to continue by reading
the input stream.

If you don't think that is suitable, then there are 3 other choices:

 1) The container always responds with 100 continue for that expectation.
    Works but a waste of that mechanism.

 2) The API is extended to allow a servlet to send 100 continue responses
    (and then another real response).  Many servlets will need to be modified
    to handle this if clients start using the mechanism.

 3) You have to propose an alternate mechanism (other than "do nothing")
    and explain it well enough that others will agree with you.


If Tomcat does nothing with the 100 expectation at all, then I would
consider Tomcat broken in that regards and will not follow them.

cheers





-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any Tutorial about Jetty Sourcecode?

Anthony Cook-2
In reply to this post by Lebing Xie
Greg Wilkins wrote:
>
> As for the expect 100 discussion, I'm afraid that you simply have not
> explained your case well enough.   You advocate that the container
> does not handle expectations at all, yet there is NO mechanism for a
> servlet to send a 100-continue.
>

So, your contention is that when my servlet calls:
...
response.setStatus( HttpServletResponse.SC_CONTINUE );
...

...the call actually does nothing?  That's not what I see in my testing,
but I guess your mileage varies. :)


Regards


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
12