eclipse/microprofile-concurrency

Nathan Rauh

@njr-11

@manovotn @FroMage Now that we have reached July, have you found any issues/feedback with MP Context Propagation in Quarkus that would prevent the 1.0 release of the spec? Let me know if it's okay to proceed with the release.

Stéphane Épardaud

@FroMage

No, nothing so far, so we can proceed with 1.0.

Nathan Rauh

@njr-11

release 1.0 binaries are available on Maven here,

<dependency>
    <groupId>org.eclipse.microprofile.context-propagation</groupId>
    <artifactId>microprofile-context-propagation-api</artifactId>
    <version>1.0</version>
</dependency>

I'm working on getting through the remaining process for announcing the release and so forth

Matej Novotny

@manovotn

Nice! Thanks for handling that

Stéphane Épardaud

@FroMage

Cool, thanks

Michael Musgrove

@mmusgrov

@njr-11 or @FroMage May I ask how you obtained permisions to promote staged artefacts on oss.sonatype.org

Nathan Rauh

@njr-11

@mmusgrov the instructions are on this page, under "If you are a committer and don't have access..."
https://wiki.eclipse.org/MicroProfile/Maven

Michael Musgrove

@mmusgrov

Thanks for that

Nathan Rauh

@njr-11

With the 1.0 version of the spec completed and less attendees at the weekly meetings, what does everyone think about reducing these meeting occurrences, and what would be best? Once per month? Once every 3 weeks? Twice per month?

Matej Novotny

@manovotn

I'd say once a month is reasonable, there doesn't seem to much to discuss anyway. We could always revert to a more frequent schedule.

Stéphane Épardaud

@FroMage

yeah, once a month is more than enough

Nathan Rauh

@njr-11

Thanks, I'll look into updating the calendar to limit to once per month

Nathan Rauh

@njr-11

If I've edited the calendar entry correctly, then the recurring call should now be limited to the second Thursday of every month. The one exception being that I left this week's meeting just in case anyone didn't see this chat, so that I can let them know when they call in.

Stéphane Épardaud

@FroMage

It appears that testng support for Eclipse is dead

it's not been updated in the marketplace for the latest Eclipse release (from early this year)

and the manual install site is 404

@njr-11 IIRC we moved to testng to get in line with other MP specs, right?

frankly that surprised me, because I thought testng died a decade ago, but I didn't really have much to stand on, besides "junit is moving a lot more today"

but this lack of IDE support is really problematic

if you would not mind going back to junit, I can send a mail to the MP mailing list discussing a move to junit

Stéphane Épardaud

@FroMage

ok, my bad, the manual install site is working now, it probably was down when I hit it

it's still pretty annoying to use testng, though :(

Nathan Rauh

@njr-11

@FroMage sorry I was out of the office for a week and wasn't able to keep up on email/chats. If I understand correctly, it sounds like the immediate issue with testng was resolved. As to whether we can switch back to junit, I think that's a question of alignment with the other MicroProfile specifications. If all of the others are using testng, then we need to do the same for consistency, but if the others are varied between testng/junit, then we should be fine switching.

Stéphane Épardaud

@FroMage

Yeah, I wasn't suggesting switching alone, but raising the question for all MP specs, but only if you don't mind, otherwise there's not much point :)

Nathan Rauh

@njr-11

That sounds good - raise the question for MP as a whole. I don't have any objections to switching

Stéphane Épardaud

@FroMage

ok thanks

Nathan Rauh

@njr-11

I've added #174 to update our version number to 1.1 so that it will be clear that new snapshot builds correspond to post-1.0 release. Could someone review it?

Stéphane Épardaud

@FroMage

Done

Matej Novotny

@manovotn

So, while trying to run the TCK with Quarkus I came across this one bit in tests - https://github.com/eclipse/microprofile-context-propagation/blob/master/tck/src/main/java/org/eclipse/microprofile/context/tck/ThreadContextTest.java#L155-L160

This gives me crashes with IllegalAccessException probably because of class loader black magic that quarkus uses to execute Arquillian.
Nonetheless, I find this approach very awkward at best, does anyone happen to remember why it's there?
We could simply call (for instance) CDI.current().select(UserTransaction.class).isResolvable()

@njr-11 @FroMage @mmusgrov ^^

Stéphane Épardaud

@FroMage

well, that would make it depend on CDI, but apparently it already does, though it's not used

it was added in fbe0b27eda0a14d54053352dc053f986272c8917

for config, which was later removed but not the dependency

so the pom depends on cdi but not the code

a bit unfortunate

eclipse/microprofile-context-propagation@fbe0b27

Nathan Rauh

@njr-11

I believe someone raised a requirement at one point for MP Context Propagation to be usable regardless of whether CDI was available. So even back when we had the config annotations (@ManagedExecutorConfig) the TCK tests went out of their way to ensure that an implementation could pass when CDI was not available.

Looking ahead a couple of lines in the test, that test isn't really concerned with CDI at all, and just wants a UserTransaction. It tried two different ways to get one, requiring at least one to succeed, and then using whichever that is. It even traps for errors, although didn't expect an IllegalAccessException as a type of error to trap for. Does Quarkus allow the other mechanism of obtaining UserTransaction? If so, this might be as simple as adding a catch block to the test

Matej Novotny

@manovotn

I think my question was more along the lines of - do we keep the claim that its CDI independent? We even have TCKs taht directly operate on CDI beans anyway, so its not like the dependency isn't there already

and to answer your question, InitialContext.doLookup() wont work as we dont have EJBs there
and this other approach I am not quite sure yet why it fails, but I suppose it's because of class loader shuffling

Matej Novotny

@manovotn

also if you insist in it passing without CDI impl, then we could make a check if CDI is present via just API using CDI.current() (throws IllegalStateException is no provider is found) and if that's ok, then proceed using Instance.select() just without the reflections since we depend in the API anyway?

Nathan Rauh

@njr-11

To clarify, I wasn't the one insisting upon the TCK being able to pass without a CDI implementation, nor did the request come from any of the spec participants who were involved in the OpenLiberty implementation. If I had to guess prior to this conversation, I would have guessed that Stephane had raised the requirement at one point, but it must have been someone else. If we're going to change it, let's get an issue open because that will have broader visibility and hopefully allow for any objections to be surfaced.

Matej Novotny

@manovotn

poor wording from me, didn't mean to "blame it on you", sorry for that :)
Sure, I'd open an issue to at least make it the way I suggested above, to check via API for actual impl and skip the tests if not present, otherwise proceed with CDI in place

Matej Novotny

@manovotn

created eclipse/microprofile-context-propagation#178

Matej Novotny

@manovotn

and here goes PR eclipse/microprofile-context-propagation#179

Stéphane Épardaud

@FroMage

It was totally me asking to not depend on CDI

At the time we wanted to use this in RESTEasy which does not depend on CDI

Now that the next version of JAX-RS is going to require CDI, and Quarkus requires CDI, it's become moot

And besides, the unused build dep slipped through

Now, I mostly wanted the spec to not require CDI, and I guess for the TCK to not require that implementations of the spec depend on CDI. As for the TCK itself depending on CDI I don't think it would have mattered

Where communities thrive

People

Repo info

Activity