Re: [ee4j-community] Eclipse Jetty and EE4J

["Kevin Sutter" <sutter@xxxxxxxxxx>]

The Eclipse MicroProfile project is not
producing RIs.  We are producing Specs, APIs, and TCKs.  No RIs.
 We want each vendor to produce their own implementation of the spec
and then verify it's "correctness" by running the TCK.  So,
in essence, we have multiple "reference implementations".  

Of course, this makes writing a TCK
a bit more difficult.  Without a specific RI to test against, writing
a runnable TCK is tricky.  In many cases, the various vendors are
implementing the feature while the spec is being developed.  Or, maybe
there are some "sample implementations" being developed to prove
out the spec and the TCK.  So far, it's been working out for us.  

Just a data point that RIs are not an
absolute requirement.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

ee4j-community-bounces@xxxxxxxxxxx wrote on 10/13/2017
07:38:12 AM:

> From: Dimitris Andreadis <dandread@xxxxxxxxxx>
> To: ee4j-community@xxxxxxxxxxx
> Date: 10/13/2017 07:38 AM
> Subject: Re: [ee4j-community] Eclipse Jetty and
EE4J
> Sent by: ee4j-community-bounces@xxxxxxxxxxx
> 
> Sure. But that should mean that the spec needs to be revised to be
> more accurate. While implementing the specs there can/has been cases
> where either the TCK or even the RI is challenged for not adhering
> to the spec.
> BTW, I do find RIs useful.
> On 13/10/2017 14:21, Guillermo González de Agüero
wrote:
> In case of ambiguous wording on specs, usually
RIs have been 
> referenced as "the truth", like if they were part of the
spec 
> itself. I guess Ben refers to that.
> 
> Regards,
> 
> Guillermo González de Agüero.
> 
> El vie., 13 oct. 2017 a las 13:44, Dimitris Andreadis (<dandread@xxxxxxxxxx
> >) escribió:
> How you define "significantly elevated"?
I'm obviously biased, but the
> only objective differentiator is having to implement the spec first.
> 
> /Dimitris
> 
> Dimitris Andreadis
> Senior Engineering Manager
> Red Hat JBoss EAP/WildFly
> 
> On 13/10/2017 13:31, Ben Evans wrote:
> > I see it more as a question of whether the RI is significantly
> > elevated among a number of open source implementations or regarded
> > more as "first among equals".
> >
> > Personally, I would tend towards the point of view that having
an RI
> > is good in most circumstances, but that it should be thought
of more
> > as the latter than the former.
> >
> > Thanks,
> >
> > Ben
> >
> > On Fri, Oct 13, 2017 at 3:14 PM, Dimitris Andreadis <dandread@xxxxxxxxxx
> > wrote:
> >> The 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/WildFly
> >>
> >> On 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 bea 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)
> >>> To: ee4j-community@xxxxxxxxxxx
> >>> 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 keycomponents
> >>> 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
> >>>
> >>> --
> >>> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
> >>>
> >>> _______________________________________________
> >>> 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
> >>>
> >>
> >>
> >> --
> >> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
> >>
> >>
> >> _______________________________________________
> >> 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
> 

> _______________________________________________
> 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://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=2glpCratNhIH_D2ZXjVXIJcwzVaAOhEm1LxRzuWltgk&s=6nlMBhP8D8OxDwMmQqznwV3r5CCPflqHSXAkHiz3lXI&e=