Skip to first unread message
John D. Ament
Nov 29, 2017, 10:56:35 AM11/29/17
to Eclipse MicroProfile
We've had a few cases now where specs will rely on each other for certain operations. Rather than a tight coupling (as is the case with most MP Config use cases), it's more of a loose coupling where if something is available then we'll use it.
We have a new case, in the situation of MP Rest Client and MP Open Tracing, where I want to propagate the span from my current request into the next request on the client. In this case, MP Rest Client should be able to be aware of the trace, and use in the request its making to the next service.
Relevant issues:
In my opinion, this is an integration test that verifies when the two together are available the behavior is observed. However, I don't believe the TCK test for this belongs in either project. I'm wondering if we have a way to classify this type of test, and perhaps need to introduce a platform level TCK that checks this type of behavior.
Ken Finnigan
Nov 29, 2017, 11:56:39 AM11/29/17
to MicroProfile
I agree we need something like this, and I think we need to take it a step further and say that we need some MP platform type spec to cover how various specs operate when they're working together.
I'd prefer to include such integration into an over arching spec as opposed to being sprinkled through various individual specifications making it harder to grasp how everything works together. Even more so as the number of specifications grows.
Ken
--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/c9920fd5-e098-49bb-861e-0cc09f9ea198%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Emily Jiang
Nov 29, 2017, 5:40:37 PM11/29/17
to Eclipse MicroProfile
+1 Ken. I suggest to put the integration tcks on MP x (e.g. MP 1.3) to cover the spec integration (e.g. open-tracing and rest-client, FT and metrics). MP umbrella spec will not just repeat the individual specs but include the integration part and the tck tests.
Emily
Emily
On Wednesday, November 29, 2017 at 4:56:39 PM UTC, Ken Finnigan wrote:
I agree we need something like this, and I think we need to take it a step further and say that we need some MP platform type spec to cover how various specs operate when they're working together.I'd prefer to include such integration into an over arching spec as opposed to being sprinkled through various individual specifications making it harder to grasp how everything works together. Even more so as the number of specifications grows.Ken
On Wed, Nov 29, 2017 at 10:56 AM, John D. Ament <john.d...@gmail.com> wrote:
We've had a few cases now where specs will rely on each other for certain operations. Rather than a tight coupling (as is the case with most MP Config use cases), it's more of a loose coupling where if something is available then we'll use it.We have a new case, in the situation of MP Rest Client and MP Open Tracing, where I want to propagate the span from my current request into the next request on the client. In this case, MP Rest Client should be able to be aware of the trace, and use in the request its making to the next service.Relevant issues:In my opinion, this is an integration test that verifies when the two together are available the behavior is observed. However, I don't believe the TCK test for this belongs in either project. I'm wondering if we have a way to classify this type of test, and perhaps need to introduce a platform level TCK that checks this type of behavior.
--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
Heiko Rupp
Nov 30, 2017, 10:43:11 AM11/30/17
to Eclipse MicroProfile
I agree. Also things like "namespaces" or universal constants across all specs should go into this new umbrella. Individual specs will then just say "<namespace> as defined in umbrella"
Am Mittwoch, 29. November 2017 17:56:39 UTC+1 schrieb Ken Finnigan:
I agree we need something like this, and I think we need to take it a step further and say that we need some MP platform type spec to cover how various specs operate when they're working together.I'd prefer to include such integration into an over arching spec as opposed to being sprinkled through various individual specifications making it harder to grasp how everything works together. Even more so as the number of specifications grows.Ken
On Wed, Nov 29, 2017 at 10:56 AM, John D. Ament <john.d...@gmail.com> wrote:
We've had a few cases now where specs will rely on each other for certain operations. Rather than a tight coupling (as is the case with most MP Config use cases), it's more of a loose coupling where if something is available then we'll use it.We have a new case, in the situation of MP Rest Client and MP Open Tracing, where I want to propagate the span from my current request into the next request on the client. In this case, MP Rest Client should be able to be aware of the trace, and use in the request its making to the next service.Relevant issues:In my opinion, this is an integration test that verifies when the two together are available the behavior is observed. However, I don't believe the TCK test for this belongs in either project. I'm wondering if we have a way to classify this type of test, and perhaps need to introduce a platform level TCK that checks this type of behavior.
--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
Ondro Mihályi
Dec 3, 2017, 4:07:13 AM12/3/17
to Eclipse MicroProfile
In my opinion it's not a good pattern to put all integration tests in a single umbrella test suite. I agree that in some cases there's no other place to add such tests but in most cases, one of the specs is dominant in such a test case and then the test case should be included within its TCK in an optional test suite that should be executed only when an implementation fulfills the other specs.
As an example, the issues linked by John make sense only when REST clients are used within an OpenTracing-enabled environment. Therefore JAX-RS and MP REST client are the dominant specs and they should define how the client behaves. So MP REST client should define a set of tests relevant only when opentracing is provided. With JAX-RS it's not that simple as we can't modify the spec, but since JAX-RS is a part of MicroProfile APIs, we could create an additional TCK for JAX-RS to cover this and other future integration cases.
Another acceptable option is to create the integration tests in the umbrella MP but separate the test cases int suites that have have clearly specified requirements. E.g., the opentracing+REST tests would go into a suite that depends only on Opentracing, JAX-RS and MP REST client. All in all, I just want to avoid what happened with the EJB spec that defined lots of cross-concern functionality in a single spec and I'm afraid that the umbrella MP spec could become the same ball of mud. I rather like the CDI approach where most of the cross-concern functionality tends to go to other specs like JTA with @Transactional. And the same applies to the TCK which is still part of the spec, just written in code.
Technically, it's very easy to separate tests into different test suites that have fine-grained dependencies. Both JUnit and TestNG support grouping of tests and maven profiles can specify which tests to run. By default, only the basic set of tests would be executed, additional tests would be enabled if the implementation supports the dependencies. I still think there's a need for an umbrella TCK to run all the individual TCKs with all enabled profiles. It doesn't matter much if the integration test suites exist in the individual TCKs or in the umbrella TCK as a collection of fine-grained test suites.
--Ondro
As an example, the issues linked by John make sense only when REST clients are used within an OpenTracing-enabled environment. Therefore JAX-RS and MP REST client are the dominant specs and they should define how the client behaves. So MP REST client should define a set of tests relevant only when opentracing is provided. With JAX-RS it's not that simple as we can't modify the spec, but since JAX-RS is a part of MicroProfile APIs, we could create an additional TCK for JAX-RS to cover this and other future integration cases.
Another acceptable option is to create the integration tests in the umbrella MP but separate the test cases int suites that have have clearly specified requirements. E.g., the opentracing+REST tests would go into a suite that depends only on Opentracing, JAX-RS and MP REST client. All in all, I just want to avoid what happened with the EJB spec that defined lots of cross-concern functionality in a single spec and I'm afraid that the umbrella MP spec could become the same ball of mud. I rather like the CDI approach where most of the cross-concern functionality tends to go to other specs like JTA with @Transactional. And the same applies to the TCK which is still part of the spec, just written in code.
Technically, it's very easy to separate tests into different test suites that have fine-grained dependencies. Both JUnit and TestNG support grouping of tests and maven profiles can specify which tests to run. By default, only the basic set of tests would be executed, additional tests would be enabled if the implementation supports the dependencies. I still think there's a need for an umbrella TCK to run all the individual TCKs with all enabled profiles. It doesn't matter much if the integration test suites exist in the individual TCKs or in the umbrella TCK as a collection of fine-grained test suites.
--Ondro
Ken Finnigan
Dec 4, 2017, 10:31:50 AM12/4/17
to MicroProfile
Ondro,
I would disagree that the presence of OpenTracing means that MP REST then dominates. If anything I would see it as the other way as OpenTracing wants MP REST to do something because of its presence.
My concern with optional testsuites for MP specs is what it then means to pass the TCK. Is an implementation compliant with the TCK if it doesn't cater to interactions with other specs and therefore never runs the TCKs associated with those interactions?
Ken
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/31f63d41-d7c6-4996-b55a-e1ab869b3339%40googlegroups.com.
Ondro Mihályi
Dec 6, 2017, 5:47:49 AM12/6/17
to Eclipse MicroProfile
Hi Ken, it's OK to disagree :)
I came to my conclusion based on what I've seen in Java EE. The reference for me is CDI vs. JTA relationship and I think that OpenTracing vs. REST relationship is similar. The first one is general purpose and can touch many other specs/technologies and the second one leverages the first one in some way. Implementation-wise, it's clear that the REST components needs to provide information for OpenTracing therefore the work to integrate them needs to be done in the REST components. Similar work would need to be done in other communication components (messaging, other protocols) if they were included in MicroProfile.
In terms of certification, your understanding is in line with my vision - for an implementation to pass individual spec TCK it would only be required to pass non-integration tests. Integration tests would optionally certify that the implementation correctly integrates other MP specs if they are supported by the implementation. Integration tests would be disabled by default on individual spec TCK level and enabled only in the umbrella MP TCK.
But it's not so important how we implement it. I only wanted to to bring an alternative opinion to think about options before a decision is made. What's important to me is clearly separate integration tests into groups/modules according to their dependencies and avoid creating a monolithic umbrella TCK. The tests can be included in the umbrella repository as long as they are separated into modules.
--Ondro
I came to my conclusion based on what I've seen in Java EE. The reference for me is CDI vs. JTA relationship and I think that OpenTracing vs. REST relationship is similar. The first one is general purpose and can touch many other specs/technologies and the second one leverages the first one in some way. Implementation-wise, it's clear that the REST components needs to provide information for OpenTracing therefore the work to integrate them needs to be done in the REST components. Similar work would need to be done in other communication components (messaging, other protocols) if they were included in MicroProfile.
In terms of certification, your understanding is in line with my vision - for an implementation to pass individual spec TCK it would only be required to pass non-integration tests. Integration tests would optionally certify that the implementation correctly integrates other MP specs if they are supported by the implementation. Integration tests would be disabled by default on individual spec TCK level and enabled only in the umbrella MP TCK.
But it's not so important how we implement it. I only wanted to to bring an alternative opinion to think about options before a decision is made. What's important to me is clearly separate integration tests into groups/modules according to their dependencies and avoid creating a monolithic umbrella TCK. The tests can be included in the umbrella repository as long as they are separated into modules.
--Ondro
Emily Jiang
Dec 6, 2017, 6:32:59 AM12/6/17
to Eclipse MicroProfile
In my view, it is not a good practice to include some tcks in one spec but allowed to be disabled. The better suggestion is to create a dedicate tck suite just for a different category, which is self explanatory. It is why I suggest to put on MP 1.3 umbrella release. By the way, we should not follow everything JavaEE had done as not everything done there was the best solution. We should think how to better cater our purpose and cause less confusion.
Emily
Emily
Matthieu Brouillard
Dec 7, 2017, 3:12:42 AM12/7/17
to Eclipse MicroProfile
Can'it be that the TCKs use some categorization of tests (Junit4 category, Junit5 tags, TestNG ???).
Then in each TCK the tests relevant only to the current spec project will be marked only with the marker project, but the cross-tests would be located in the more suitable TCK project (see Ondro/Ken discussion on test location ) and marked with all the relevant markers.
Thus tests could be written like that (pseudo code, pseudo annotations):
@Test@Marker(MP.REST)public void can_do_a_rest_call() {...}@Test@Marker(MP.REST, MP.OPEN_TRACING)public void do_a_rest_call_with_tracing() {...}
In above example the second test would be run ONLY IF the tck containing it was run with the 2 spec profile REST & OPEN_TRACING active.
It is just an idea that is perhaps not directly available in the unit testing framework used by TCKs (testng for all I guess) but there should be means to achieve that.
Matthieu
Reply all
Reply to author
Forward
0 new messages