| Re: [ee4j-community] Eclipse Jetty and EE4J |
I realize I don't have any voice in this, but I did want to put some extra context to the need a RI. Over the last year we've held public presentations on 2 JSRs (1 with Rudy de Busscher, and 1 with Dmitry Kornilov). The RI available gives people a way to have a hands on experience with an upcoming spec, and there a) find potential bugs/things that the EG perhaps missed (and feed this back to the EG), and b) raise support&awareness for a JSR. I personally also feel that providing a RI should stay; setting a spec standard without a ready-to-go implementation raises the risk of it remainijg just that: a spec without support & usage for&by developers.Again, I don't have any voice in this but just wanted to share my view.Kind regards,Erwin HoeckxThe absence of an RI is an interesting approach, i.e. if the Spec is complete enough to not have to look into the RI to understand under-specified aspects.
How about interop testing that is now performed against the RI? Should you be able to pick any other opernsource implementation and test against it, to claim compliance?
/Dimitris
Dimitris Andreadis Senior Engineering Manager Red Hat JBoss EAP/WildFlyOn 13/10/2017 03:42, Greg Wilkins wrote:
On 13 October 2017 at 11:31, reza_rahman <reza_rahman@xxxxxxxxx> wrote:
This is interesting indeed. One of the things I will admit I was thinking about is whether Jetty could replace Grizzly as the Servlet RI and the Jetty folks lead Servlet in the future. Indeed I was wondering the same thing in the Servlet 4 time frame. Only a pipe dream perhaps?
While we certainly wish to be part of future the servlet spec into the future, I'm not sure that I would advocate a long term Jetty "leadership" any more than a Glassfish, Tomcat or Undertow one.
Whatever the governance structure of the spec groups are, that should not provide any significant power to set the agenda nor technical direction to an individual or single implementer. The goals and agenda for driving the spec forward should come from the community and the technical solutions should be determined collaboratively between implementers. So perhaps "convener" is a better name than "leader" and as such it could be a rotating role to share the effort around?
As for RI's, I'm not a big fan of them, as they facilitate lazy incomplete specs. Any behaviour that is not explicitly described in specification and/or tests should be deemed undefined rather than follow one specific implementation that may be written to meet effort/commercial/scaling/performance criteria that cannot be applied generally to all implementations.
Jetty has a long history and firm focus on our target market(s), which is often apparent if you look in the gaps between that parts fixed by specification. It is unlikely that our history and/or markets are appropriate to be a reference for other implementations that share neither that history and/or focus. I certainly would not like to be constrained in the development of jetty so that we could not change unspecified behaviour for fear of changing the specification reference for all others!
I would much rather see multiple implementations developed during the specification process (as per the IETF working code mantra) together with a collaborative test suite. Once a specification version is final, no implementation should be more special than any other. Portability issues should be addressed by refinement of the specification and collaborative development of new tests.
regards
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Greg Wilkins <gregw@xxxxxxxxxxx>Date: 10/12/17 7:23 PM (GMT-05:00)Subject: [ee4j-community] Eclipse Jetty and EE4J
The Eclipse Jetty team would like to extend a welcome to the EE4J project and the new contributors it will bring to the eclipse foundation. Eclipse has been a good home for the Jetty project and has struct a good balance between the sometimes competing concerns of guidance, structure, support, autonomy and flexibility.
We are please to see an opening up of the specification processes and TCKs and we very much wish to play a part in the ongoing development/innovation of the Servlet specification and it interplay with the other key components within the EE space.
Our belief is that EE needs to develop into a more component oriented architecture where individual technologies can be more stand alone and/or plug/play rather than be built only as part of monolithic whole. The Jetty project already uses/provides components from/to other contributors to the EE ecosystem and we would like to see a spec and test environment develop that would facilitate further such collaboration, so we can all concentrate of improving and innovating within our core features.
We look forward to see how the governance within and between the EE specifications is developed and hope to play a part in both the formulation of that and the execution.
regards--
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
--
_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/ mailman/listinfo/ee4j- community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community