[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] [ejb-dev] Removal of tests for pruned technologies versus making tests optional and not run by default...
|
On 10/8/20 11:10 AM, Mark Thomas wrote:
On 07/10/2020 18:18, Scott Marlow wrote:
I started to document the Jakarta TCK rules [1] for removing TCK tests
for removed technologies (like tests that specifically use Corba or the
Corba IIOP protocol) and also for tests that use DTDs/Schemas older than
EE 8.
I think it will help for EE 9 to have consistent rules that we follow
for $subject. Feedback on [1] is welcome before it is merged into the
Platform TCK documentation (perhaps via github pages or wiki).
Those rules are at odds with the views of the individual projects.
Mostly, I'm trying to document the EE 9 Platform TCK rules that we have
been following this year.
First, let me say that I greatly appreciate all of the work that you and
others have contributed to Jakarta EE 9! :-) Your thoughtful and honest
feedback here and in the pull request, is very helpful as I know have a
better understanding of your perspective.
Speaking of perspectives, I would like to mention some of my
perspectives to this conversation:
1. My perspective on GlassFish and Jakarta Platform EE 9 Optional
technologies:
Since GlassFish has to test every required + optional platform
technology, I think that it has been discussed elsewhere that it is
unfair to GlassFish to be required to test optional technologies when
other Jakarta EE 9 implementations do not have to. Still, the GlassFish
has been tirelessly testing all of the optional technologies. I should
also mention that it wasn't the GlassFish team that pointed out the
unfairness of having to test optional technologies.
Anyway, the reason why I am bringing this up here, is we have considered
changing the Jakarta EE 9 Platform TCK to treat pruned/removed
technologies as optional. However, as discussed on the September 29
Platform TCK call doing so for Corba (TCK) tests may not be consistent
with how we handled removing tests for other pruned/removed
technologies. I took the point as being that we should as a goal, try
to be consistent about how/why we do things. I'm trying hard to align
this desire to be consistent to also do what makes sense, on a
day-to-day basis for individual tasks.
Toward this sub-goal, I'm thinking that we can be open to change as we
plan the next/future releases, but changing rules in the middle of a
release could create confusion to the wider team.
2. My perspective on the Jakarta EE 9 DTDs/Schemas is that it is a good
thing that SPEC APIs that can benefit from including the pre-EE-8
DTDs/Schemas in their EE 9 SPEC API jars or repositories, do have the
ability to do what makes sense for their SPEC API project. From the
latest Jakarta EE Platform 9 Spec
(https://jakarta.ee/specifications/platform/9/platform-spec-9-SNAPSHOT.html),
the earlier legacy DTDs/XSDs are considered optional for implementations
of the Platform Spec (that will use the various Jakarta EE 9 Spec
API/Impl artifacts).
3. After Jakarta EE 9 is final, I would like to have an open
post-mortem discussion about what went really well during this
development cycle on the Platform TCK project and what could/should be
improved (and ideas for improvement). This will be open to all to
participate in.
4. For Jakarta EE 10, we should have an discussion on this mailing list
about the Platform TCK and how things like optional/required
technologies are handled. As well as the other large subjects, like
what the options are for restructuring aspects of the Platform TCK
tests, without losing any Platform level tests (expected for removed
technologies in EE 10). Lets discuss #4 in a separate email thread but
I did want to mention that we need to have such a discussion.
More inline below...
Servlet, for example, took explicit steps to ensure that all historic
schemas were shipped in the Servlet API JAR.
+100, I personally contribute to WildFly and other projects that will
likely benefit from your efforts, as WildFly does still support pre-EE-8
DTDs/XSDs. Thank you for doing that! :-)
JSP, for example, has retained language in the specification document
referring to backwards compatibility including that which requires
different behaviour for TLDs using 2.0 and earlier schemas vs TLDs using
2.1 and later schemas.
I don't personally see a problem with this. Does any one else?
I followed the reference to chain to where this was decided and found
VOTE thread on the platform-dev list.
Yeah, I think that is mostly directed at Platform implementations (e.g.
Full Platform or Web Profile), not really the individual SPEC APIs, but
I think we should clarify that my understanding is shared with others
and agreed on.
I suspect I missed it at the time as I had my hands full dealing with
CVE-2020-1938.
I note from the minutes of the Jakarta EE Platform call on 2020-01-28
that followed that vote that:
"Option #3 is the desired direction. *Need to widely communicate to the
community*." (my emphasis)
I don't see any communication of this decision to any of the individual
projects (Servlet, Pages, EL, WebSocket) I am most heavily involved in.
The only advantage I saw expressed for not supporting these schemas was
to make it easier for new implementations.
Yes, I did read those comments also.
Speaking from experience of
providing support for multiple versions of schemas, it is my view that
the benefit here is negligible as the schemas are - by design -
backwards compatible excluding a very small number of edge cases.
The disadvantage is that automatic migration of web applications from
Java EE 8 and earlier to Jakarta EE 9 (or later) is a lot more complex.
I completely agree! For example, if a Jakarta EE 9 implementation wants
to still include pruned/removed technologies, they may do that as long
as the pruned/removed technologies are tested (e.g. via Jakarta EE 8
TCKs). We also talked about the possibility that tests for removed
technologies might be moved to a separate Standalone TCK but I'm not
sure yet of how that can be possible currently.
The Jakarta EE Platform discussions that I recall also were supportive
of EE implementations continuing to support older applications migrating
to the latest EE server implementations, however as you said, new
implementations are not required to provide compatibility with older EE
versions.
Automatic migration that implements the package rename is relatively
simple. As soon as support is dropped for old schemas, migration has the
potential to become a lot more complex - particularly, for example, in
the area of TLDs around how "#{" is interpreted.
In addition to tag library descriptors, those using bytecode
transformers to convert their EE 8 server to EE 9, also need to deal
with handling the EE 9 JSP XSDs (as well as other XSDs as well), so
there is some extra work/challenges for everyone.
Scott
Mark
Scott
[1]
https://docs.google.com/document/d/1rdQCftJHexDouNtrvvUfjknZHhG8sWt1lerwcWpbQrY/edit#heading=h.sygoumfn3qd0
On 9/29/20 12:38 PM, Jean-Louis Monteiro wrote:
As discussed today, I think consistency would be my choice.
I'll look at the impact in terms of TCK.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com <http://www.tomitribe.com/>
On Tue, Sep 29, 2020 at 6:36 PM Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
Hi,
During the Platform call [1] today it was pointed out that TCKs
should
consistently handle all pruned/removed technologies the same (e.g.
either remove related tests or allow related tests to be run
optionally).
We removed the Jakarta Platform EE TCK tests for Jakarta XML
Registries,
Jakarta XML RPC, Jakarta Deployment, Jakarta Management but recently
updated the Platform TCK to treat the com/sun/ts/tests/ejb30 that use
Corba as optional [2]. By default the EJB tests that use Corba
are not
run (default is !rmi_iiop&!corba ).
I added David Belevins + the EJB ml to ask what the impact would
be if
we adjusted the changes made in [2] to instead remove the ejb30 tests
that use Corba?
We also updated the com/sun/ts/tests/rmiiiop tests to be optional as
well [2]. By default these tests are not run (default is
!rmi_iiop&!corba ).
Feedback on removing the RMI-IIOP tests instead of marking them
optional
by default would also be appreciated.
Thank you Guru for all of your hard work and patience on [2].
Scott
[1]
https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit?pli=1
[2] https://github.com/eclipse-ee4j/jakartaee-tck/pull/521
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx <mailto:ejb-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ejb-dev
_______________________________________________
ejb-dev mailing list
ejb-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ejb-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
