Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Michael Musgrove
    @mmusgrov
    Well my first attempt to create a CQ for javax.ws.rs-api:2.0.1 produced the error The website encountered an unexpected error. Please try again later.
    I'll try that again ..
    Michael Musgrove
    @mmusgrov
    Yey, I have my CQ, it's easy when one knows how ;) thanks
    Nathan Rauh
    @njr-11
    Now that we've both misinterpreted the process and then figured out how to do it right, it seems like it would be a good idea to update the wiki page for others with some additional clarifying instructions
    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
    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
    Matej Novotny
    @manovotn
    Stéphane Épardaud
    @FroMage
    It was totally me asking to not depend on CDI