You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Eduardo Pelegri-Llopart <Ed...@eng.sun.com> on 2000/01/25 07:21:30 UTC
announcement: JSR 052 and JSR 053
Two Java Specification Requests have been posted today.
JSR-000053 Java Servlet 2.3 and JavaServer Pages 1.2 Specifications
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_053_jspservlet.html
and
JSR-000052 A Standard Tag Library for JavaServer Pages
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html
See http://java.sun.com/jcp for details on the JCP process.
- eduard/o, danny & anil
Re: JSR 053
Posted by Jon Zeppieri <jo...@employease.com>.
Eduardo,
First of all, thank you for clarifying those issues I asked about in my last
message. That was rather helpful.
I hope you didn't take my comments as a desire to "nail down the proposal" in
the JSR. That, I wholly agree, would be counter-productive. There would then
be no possibility of constructive criticism, of making things better. What I
actually said in my message was that a *rough draft*, something of a starting
point, ought to be included in the JSR.
But let me qualify this. While I personally think that a statement of goals is
a bit skimpy of a starting point, it would probably be sufficient, *provided
that the goals were discussed in some detail*. JSR 53 seemed to say little more
than, "We want to change the specification, and here are a few things to
improve" -- without saying much of anything about the nature of the
improvements.
And, with all due respect, you are wrong about JSR 41 (Assertions). In section
3, the JSR links to a detailed proposal
(http://java.sun.com/aboutJava/communityprocess/jsr/asrt_prop.html). Now, the
JSR clearly states that this proposal is to be used as a "starting point" for
the specification. In other words, the submitters are not trying to preclude
discussion; they are trying to give people *something to discuss*. This, I
would argue, is the best kind of JSR.
You may have had in mind something more like JSR 51 (new IO package). And even
that JSR claims that there is a proposal, internal to Sun, but that it is not
yet ready for public eyes. (Not that this helps someone trying to comment on
it, at all.)
-Jon
Eduardo Pelegri-Llopart wrote:
>
> Hi Jon.
>
> Let me try to address the general issues first and then move to some
> more specific ones.
>
> I believe that JSR-53 follows the guidelines for a JSR in the JCP.
> JSR-50 is much more detailed and sketches a direction, but there are
> others, like JSR-41 (Assertions) that indicate goals, like ours.
>
> Based on my experience with previous JCP processes, I think that stating
> goals is exactly the right thing to do. It is conter-productive (again,
> in my experience) to nail down the proposal too early: it limits the
> range of solutions and it creates a "for/against" instead of a "us"
> approach.
>
> I think that a JSR should concentrate in establishing the goals and
> general parameters for design. JSR-50 has chosen otherwise, that is
> their prerogative. In the case of JSR-53, I think very important not to
> limit the solutions so we can choose the best solution without
> preconceptions and with as much a level-playing field for the solutions
> as possible.
>
> That said, the JSR may be lacking on goals.
>
> I think (hope) I can address some of your specific questions.
>
> * Do you mean to introduce JSP dependencies into the servlet APIs?"
>
> No. The Servlet specification should *NOT* depend on the JSP
> specification. The JSR says so at the very beginning and repeatedly.
> Actually we want to make it even more clear how to use Servlets without
> JSPs (the 2.2 spec has some unwanted presentational dependencies).
>
> * In what manner can `debugging and other tool support' be *specified*
> at all?
>
> Debugging of JSPs has been top in the list of requirements for a while.
> Relating back to the original JSP source is not possible without some
> sort of bytecode-to-JSP source map. We hope JSR-45 will produce
> something we can use without significant intrusion.
>
> We may look briefly at whether there is anything that could be done to
> help Servlet debugging but, given that there are good Servlet debuggers
> out there, there does not seem to be immediate need.
>
> The "other tool support" statement was not very clear, my mistake; we
> had in mind JSP authoring tools.
>
> * Will these changes force even more parts of the spec to require an XML
> parser?
>
> If you mean the Servlet spec, I doubt it. We have received repeated
> requests for the ability to apply filters on responses. Wiring-in XSLT
> (or your favorite tool) seems short-sighted and needless to me; I'd
> expect a general mechanism (maybe as part of something even more
> general) that can be used by interested parties for specialized tasks.
> But I believe this is a call for the expert group.
>
> In the case of the JSP spec, I do not know.
>
> * [As a personal aside, I found the introduction of an XML deployment
> descriptor in 2.2 to entail an extremely annoying and utterly
> unnecessary increase in configuration complexity.]
>
> The feedback on web.xml I have seen has been quite positive.
>
> * Without more details (without *any* details), how can one possibly
> determine whether or not the proposal is sane and should be adopted?
>
> A JSR is not a specification proposal; it is a specification request. I
> think you should judge its stated goals and aks for clarifications,
> provide additional goals should you feel the JSR is lacking, or suggest
> the removal of goals, and then judge the JSR based on that.
>
> If the JCP office approves the JSR, there will be specification drafts
> that will be distributed to different communities for feedback. At some
> point there will be a specific specification proposal to approve or not,
> but there is still a lot of work until when we get there.
>
> Hope this helps some,
>
> - eduard/o
>
> Jon Zeppieri wrote:
> >
> > As much as I am loathe to play the role of the party-pooper, this is not a very
> > helpful document. Maybe the problem is with the "community process" itself, but
> > it seems to me that if one is going to propose the development of a new
> > specification (or a major revision to a specification), one ought to put a rough
> > draft *of that specification* in the proposal. Otherwise, what is really being
> > proposed? The reader is given vague indications:
> >
> > o Better support for localization of applications
> > o Proper support for inclusion of JSP pages without
> > forcing flushing of buffers
> > o Support for application events
> > o Improved debugging and other tool support, taking
> > advantage of JSR-45
> > o Improved XML support
> > o Improved tag library support
> > o Improved JSP authoring support
> > o Better support for composition of components
> > o Enabling of WebDAV and WAP requests
> >
> > For each one of these items, I want to ask: "Yes, but *how* will this 'improved
> > support' affect the API?" or "Do you mean to introduce JSP dependencies into the
> > servlet APIs?" or "In what manner can `debugging and other tool support' be
> > *specified* at all?" or "Will these changes force even more parts of the spec.
> > to require an XML parser?" [As a personal aside, I found the introduction of an
> > XML deployment descriptor in 2.2 to entail an extremely annoying and utterly
> > unnecessary increase in configuration complexity.] Without more details
> > (without *any* details), how can one possibly determine whether or not the
> > proposal is sane and should be adopted?
> >
> > Read JSR 053 side-by-side with JSR 050 (which is concerned with distributed
> > real-time extensions). Now, I have absolutely no need to write real-time
> > applications in Java, much less distributed real-time applications. And I *do*
> > have a need to write servlets. But JSR 050 is considerably more compelling as a
> > proposal than JSR 053; whoever wrote it clearly took it seriously.
> >
> > Similarly, JSR 014, which is concerned with generic types, goes into a fair bit
> > of detail and, at least cites the work done by GJC and PolyJ. JSR 053 cites the
> > current specification -- which, of course, is almost certainly already familiar
> > to anyone seriously evaluating at the JSR.
> >
> > The fact is, I have an interest in the future of the servlet specification; at
> > least ninety percent of the code I write at my job sits on top of the servlet
> > APIs. And don't get me wrong: I'm very pleased that Sun has opened up the
> > specification process. Otherwise, I would simply have to cross my fingers and
> > hope for the best. But I do hope that JSR submitters take the process seriously
> > and do not submit proposals that defy evaluation.
> >
> > Ultimately, I suggest that this JSR, in its present form, not be accepted.
> >
> > -Jon Zeppieri
> >
> > Eduardo Pelegri-Llopart wrote:
> > >
> > > Two Java Specification Requests have been posted today.
> > >
> > > JSR-000053 Java Servlet 2.3 and JavaServer Pages 1.2 Specifications
> > >
> > > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_053_jspservlet.html
> > >
> > > and
> > >
> > > JSR-000052 A Standard Tag Library for JavaServer Pages
> > >
> > > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html
> > >
> > > See http://java.sun.com/jcp for details on the JCP process.
> > >
> > > - eduard/o, danny & anil
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
--
Dopeler effect: The tendency of stupid ideas to seem
smarter when they come at you rapidly.
Re: JSR 053
Posted by Eduardo Pelegri-Llopart <Ed...@eng.sun.com>.
Hi Jon.
Let me try to address the general issues first and then move to some
more specific ones.
I believe that JSR-53 follows the guidelines for a JSR in the JCP.
JSR-50 is much more detailed and sketches a direction, but there are
others, like JSR-41 (Assertions) that indicate goals, like ours.
Based on my experience with previous JCP processes, I think that stating
goals is exactly the right thing to do. It is conter-productive (again,
in my experience) to nail down the proposal too early: it limits the
range of solutions and it creates a "for/against" instead of a "us"
approach.
I think that a JSR should concentrate in establishing the goals and
general parameters for design. JSR-50 has chosen otherwise, that is
their prerogative. In the case of JSR-53, I think very important not to
limit the solutions so we can choose the best solution without
preconceptions and with as much a level-playing field for the solutions
as possible.
That said, the JSR may be lacking on goals.
I think (hope) I can address some of your specific questions.
* Do you mean to introduce JSP dependencies into the servlet APIs?"
No. The Servlet specification should *NOT* depend on the JSP
specification. The JSR says so at the very beginning and repeatedly.
Actually we want to make it even more clear how to use Servlets without
JSPs (the 2.2 spec has some unwanted presentational dependencies).
* In what manner can `debugging and other tool support' be *specified*
at all?
Debugging of JSPs has been top in the list of requirements for a while.
Relating back to the original JSP source is not possible without some
sort of bytecode-to-JSP source map. We hope JSR-45 will produce
something we can use without significant intrusion.
We may look briefly at whether there is anything that could be done to
help Servlet debugging but, given that there are good Servlet debuggers
out there, there does not seem to be immediate need.
The "other tool support" statement was not very clear, my mistake; we
had in mind JSP authoring tools.
* Will these changes force even more parts of the spec to require an XML
parser?
If you mean the Servlet spec, I doubt it. We have received repeated
requests for the ability to apply filters on responses. Wiring-in XSLT
(or your favorite tool) seems short-sighted and needless to me; I'd
expect a general mechanism (maybe as part of something even more
general) that can be used by interested parties for specialized tasks.
But I believe this is a call for the expert group.
In the case of the JSP spec, I do not know.
* [As a personal aside, I found the introduction of an XML deployment
descriptor in 2.2 to entail an extremely annoying and utterly
unnecessary increase in configuration complexity.]
The feedback on web.xml I have seen has been quite positive.
* Without more details (without *any* details), how can one possibly
determine whether or not the proposal is sane and should be adopted?
A JSR is not a specification proposal; it is a specification request. I
think you should judge its stated goals and aks for clarifications,
provide additional goals should you feel the JSR is lacking, or suggest
the removal of goals, and then judge the JSR based on that.
If the JCP office approves the JSR, there will be specification drafts
that will be distributed to different communities for feedback. At some
point there will be a specific specification proposal to approve or not,
but there is still a lot of work until when we get there.
Hope this helps some,
- eduard/o
Jon Zeppieri wrote:
>
> As much as I am loathe to play the role of the party-pooper, this is not a very
> helpful document. Maybe the problem is with the "community process" itself, but
> it seems to me that if one is going to propose the development of a new
> specification (or a major revision to a specification), one ought to put a rough
> draft *of that specification* in the proposal. Otherwise, what is really being
> proposed? The reader is given vague indications:
>
> o Better support for localization of applications
> o Proper support for inclusion of JSP pages without
> forcing flushing of buffers
> o Support for application events
> o Improved debugging and other tool support, taking
> advantage of JSR-45
> o Improved XML support
> o Improved tag library support
> o Improved JSP authoring support
> o Better support for composition of components
> o Enabling of WebDAV and WAP requests
>
> For each one of these items, I want to ask: "Yes, but *how* will this 'improved
> support' affect the API?" or "Do you mean to introduce JSP dependencies into the
> servlet APIs?" or "In what manner can `debugging and other tool support' be
> *specified* at all?" or "Will these changes force even more parts of the spec.
> to require an XML parser?" [As a personal aside, I found the introduction of an
> XML deployment descriptor in 2.2 to entail an extremely annoying and utterly
> unnecessary increase in configuration complexity.] Without more details
> (without *any* details), how can one possibly determine whether or not the
> proposal is sane and should be adopted?
>
> Read JSR 053 side-by-side with JSR 050 (which is concerned with distributed
> real-time extensions). Now, I have absolutely no need to write real-time
> applications in Java, much less distributed real-time applications. And I *do*
> have a need to write servlets. But JSR 050 is considerably more compelling as a
> proposal than JSR 053; whoever wrote it clearly took it seriously.
>
> Similarly, JSR 014, which is concerned with generic types, goes into a fair bit
> of detail and, at least cites the work done by GJC and PolyJ. JSR 053 cites the
> current specification -- which, of course, is almost certainly already familiar
> to anyone seriously evaluating at the JSR.
>
> The fact is, I have an interest in the future of the servlet specification; at
> least ninety percent of the code I write at my job sits on top of the servlet
> APIs. And don't get me wrong: I'm very pleased that Sun has opened up the
> specification process. Otherwise, I would simply have to cross my fingers and
> hope for the best. But I do hope that JSR submitters take the process seriously
> and do not submit proposals that defy evaluation.
>
> Ultimately, I suggest that this JSR, in its present form, not be accepted.
>
> -Jon Zeppieri
>
> Eduardo Pelegri-Llopart wrote:
> >
> > Two Java Specification Requests have been posted today.
> >
> > JSR-000053 Java Servlet 2.3 and JavaServer Pages 1.2 Specifications
> >
> > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_053_jspservlet.html
> >
> > and
> >
> > JSR-000052 A Standard Tag Library for JavaServer Pages
> >
> > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html
> >
> > See http://java.sun.com/jcp for details on the JCP process.
> >
> > - eduard/o, danny & anil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: JSR 053
Posted by Jon Zeppieri <jo...@employease.com>.
As much as I am loathe to play the role of the party-pooper, this is not a very
helpful document. Maybe the problem is with the "community process" itself, but
it seems to me that if one is going to propose the development of a new
specification (or a major revision to a specification), one ought to put a rough
draft *of that specification* in the proposal. Otherwise, what is really being
proposed? The reader is given vague indications:
o Better support for localization of applications
o Proper support for inclusion of JSP pages without
forcing flushing of buffers
o Support for application events
o Improved debugging and other tool support, taking
advantage of JSR-45
o Improved XML support
o Improved tag library support
o Improved JSP authoring support
o Better support for composition of components
o Enabling of WebDAV and WAP requests
For each one of these items, I want to ask: "Yes, but *how* will this 'improved
support' affect the API?" or "Do you mean to introduce JSP dependencies into the
servlet APIs?" or "In what manner can `debugging and other tool support' be
*specified* at all?" or "Will these changes force even more parts of the spec.
to require an XML parser?" [As a personal aside, I found the introduction of an
XML deployment descriptor in 2.2 to entail an extremely annoying and utterly
unnecessary increase in configuration complexity.] Without more details
(without *any* details), how can one possibly determine whether or not the
proposal is sane and should be adopted?
Read JSR 053 side-by-side with JSR 050 (which is concerned with distributed
real-time extensions). Now, I have absolutely no need to write real-time
applications in Java, much less distributed real-time applications. And I *do*
have a need to write servlets. But JSR 050 is considerably more compelling as a
proposal than JSR 053; whoever wrote it clearly took it seriously.
Similarly, JSR 014, which is concerned with generic types, goes into a fair bit
of detail and, at least cites the work done by GJC and PolyJ. JSR 053 cites the
current specification -- which, of course, is almost certainly already familiar
to anyone seriously evaluating at the JSR.
The fact is, I have an interest in the future of the servlet specification; at
least ninety percent of the code I write at my job sits on top of the servlet
APIs. And don't get me wrong: I'm very pleased that Sun has opened up the
specification process. Otherwise, I would simply have to cross my fingers and
hope for the best. But I do hope that JSR submitters take the process seriously
and do not submit proposals that defy evaluation.
Ultimately, I suggest that this JSR, in its present form, not be accepted.
-Jon Zeppieri
Eduardo Pelegri-Llopart wrote:
>
> Two Java Specification Requests have been posted today.
>
> JSR-000053 Java Servlet 2.3 and JavaServer Pages 1.2 Specifications
>
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_053_jspservlet.html
>
> and
>
> JSR-000052 A Standard Tag Library for JavaServer Pages
>
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html
>
> See http://java.sun.com/jcp for details on the JCP process.
>
> - eduard/o, danny & anil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org