Replies: 10 comments 11 replies
-
And so you think it's a good idea to criticize months of work by other people without taking a step back? RESTEasy Reactive passes the JAX-RS TCK (except some very weird behaviors) so if things are not in line with the spec, I would say the main culprit is an incomplete TCK. Implementing a spec is extremely hard and that's why TCKs exist. Now even the perfect TCK cannot cover all the corner cases out there, especially since it's implementation agnostic and corner cases are often tied to implementation details. Now, RESTEasy Reactive has been around for a while and is used in production so its infrastructure works and is something we want for Quarkus. Your issues will be fixed and thanks for reporting them. They will be fixed even faster if you provide full Maven reproducers. Or you can also help fix them given it's all Open Source. |
Beta Was this translation helpful? Give feedback.
-
|
You have to consider how users of Quarkus are feeling. We report a bug and it's fixed (quite fast, which I really appreciate). But in order to get the fix, we have to switch to a completely different JAX-RS implementation which introduces new bugs. And so we are stuck. I assume these new bugs will be fixed soonish again but very likely it requires us updating to 2.9 which adds new features which in turn can bring with it new bugs (that's the nature of new features). This can go on and on forever but in the end we have to finish the project at some point in time. And I disagree that the two last bugs we reported are edge-cases. Using resource-id as path parameter (which we do in our code) isn't out of the ordinary at all. Also specifying no content type in the response is even standard I would say, otherwise you are not able to deliver more than one representation of a resource. Given that nobody has come across these issues so far makes me believe (you may have a different opinion and this is absolutely fine) that the reactive version is less used and mature than the classic version. And then declaring it the new standard and even stopping support for the classic version is kind of a strange decision from my perspective. About contributing to an open source project: our company maintains a huge open source project but in the end we have to make some money, too, in order to pay our salaries. I'm totally fine with creating minimal reproducers for bugs but diving into the Quarkus code would require me days into order to get familiar and meanwhile our own project is on hold. |
Beta Was this translation helpful? Give feedback.
-
|
It's totally understandable that you think the issues you ran into are standard issues. But if the TCK doesn't test for them and none of our other users have run into them, then I would argue that they are edge cases. |
Beta Was this translation helpful? Give feedback.
-
Well, we certainly have. We have been listening to users since day 1 and are extremely open about everything. Now, maybe you should consider how Quarkus developers are feeling. I have not worked on RESTEasy Reactive myself so I'm not biased on this and speaking very calmly but you are a Quarkus user, you benefit from our work and well there is not even one positive note in your message, which is your first message to us. I'm not fishing for compliments or whatever but, really, your one day of frustration is probably nothing compared to what Quarkus brought to you and the productivity you gained using it and starting with a positive note would have been better. Maybe? Especially, since we haven't removed RESTEasy Classic and have explicitly stated it wasn't going away so you migrating your app now is a choice of yours.
That's the nature of new features and that's also the nature of fixes. Some fixes will introduce regressions too. My personal opinion is that we have a nice balance and we are innovating while making micro releases that fix bugs and that overall the Quarkus experience is nice - but not perfect, that's for sure.
It's not missing. It's called the Red Hat Build of Quarkus. If you want LTS, that's the way to go. And note that we don't use it as an excuse for issues in Quarkus: we are doing a LOT of micro releases, we fix bugs and we are all working hard on making Quarkus better, stable and as bug free as possible. A lot of fixes are shipped in less than a week.
I was talking about edge cases of the TCK i.e. things present in the spec but not covered by the TCK itself. I agree that the issues you reported are quite common and needs fixing. Now, RESTEasy Reactive has been around for a while, is tested by the TCK, by our test suite and is used by some users. At some point, we have to make it more mainstream and sure people will have issues at first but that's how things are. The exact same way that when we are releasing CRs for testing, a lot of people are not testing it and waiting for the Final to test their app. At some point, we have to take a leap of faith.
You're certainly entitled to have an opinion. We strongly believe RESTEasy Reactive is the way to go and we are committed to making it rock solid. Now my guess is that it will be far easier if people are collaborating with us and contributing to the community - be it by reporting issues with reproducers or contributing code - rather than with this sort of post. |
Beta Was this translation helpful? Give feedback.
-
|
It's not like you're not getting paid for your work |
Beta Was this translation helpful? Give feedback.
-
|
@idc77 so when you go to the bakery, you don't say thank you because the person in front of you is paid? That's one way of doing it. It certainly makes the world a little bit worse. And btw, while I'm paid to work on Quarkus - but I also work on it outside of my working hours -, that's not the case of all the members in the community. So, yeah, treating people and their work with respect should be standard. And that doesn't prevent reporting issues, asking questions, and talk openly about things - critics included. |
Beta Was this translation helpful? Give feedback.
-
|
Yes we are extremely fortunate to be paid by Red Hat for developing Quarkus. But being paid to develop Open Source software doesn't imply what all of us are doing, which is going way above and beyond to develop new features, fix user reported bugs and interact with the community in what is generally regarded as an astounding rate. |
Beta Was this translation helpful? Give feedback.
-
|
In found the next bug in reactive RESTEasy. And this is likely not the last one because we have dozens of failing tests since we switched to reactive RESTEasy. Stay tuned... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for reporting these. The feedback is extremely valuable. |
Beta Was this translation helpful? Give feedback.
-
|
I had a look at the Red Hat Build of Quarkus. The latest version is 2.2.5.Final which looks very similar to 2.2.5.Final from the "community" version. In what way is this an LTS version? Does it contain more bug fixes than the community version? |
Beta Was this translation helpful? Give feedback.
-
|
The next |
Beta Was this translation helpful? Give feedback.
-
|
@sithmein Are you a Red Hat customer ? If yes then please get in touch via the corresponding channels and raise whatever concerns you have. I have to admit, it has been awhile since I saw so much negativity in an open-source project. Resteasy Reactive is an innovation at its best, it might take some time for those users who depend on most of the RestEasy Classic features to migrate. Many of Quarkus users are spending their own time to help out with fixing some of the related issues. And as has already been said here, I'd also encourage you to go ahead and contribute, to Resteasy Reactive, or to some existing Resteasy classic issues if you prefer. Please help but not demand the fixes. |
Beta Was this translation helpful? Give feedback.
-
|
No, we are not Red Hat customers. But it was pointed out that the Red Hat Build of Quarkus is the LTS version of Quarkus but from what I can see from what's publicly available there is no difference to the community version. This is why I was asking about the actual differences. |
Beta Was this translation helpful? Give feedback.
-
|
@sithmein I believe
I agree. Since your team is looking after a large open source project, I think you can agree that with everyone in the team looking after many issues it may not be possible to react immediately to every user issue. This is when an open source contribution mode helps to accelerate things |
Beta Was this translation helpful? Give feedback.
-
I can't thank you enough for these. This is definitely open source collaboration at its finest |
Beta Was this translation helpful? Give feedback.
-
|
I really don't want to rant but this is the fifth broken functionality in reactive RESTEasy that we found. |
Beta Was this translation helpful? Give feedback.
-
|
Your issues have almost all been fixed in almost no time, so I would say things are in pretty good state. |
Beta Was this translation helpful? Give feedback.
-
|
I'm truly sorry to hear you are having issues. However I am going to say categorically that we are not going to be switching back to RESTEasy Classic as our main focus for our REST stack for reasons that have already been stated in multiple blog posts. Also it's very important for everyone here to understand that RESTEasy Reactive has been around for over 10 Quarkus versions, so folks have had ample time to try it out and report issues. |
Beta Was this translation helpful? Give feedback.
-
|
Some of the issues I have reported have been fixed in 2.8.3. However, there are still some open problems remaining. One is about routing requests to the correct resource method. There are no problem with classic RESTEasy but about 20 methods cannot be found with reactive RESTEasy. The method does not get invoked and a 404 is being returned. This makes me believe there is a bug somewhere in the routing code. Where would I need to start looking so that I can find out the reason? I wasn't able to find a pattern by just looking at our code. |
Beta Was this translation helpful? Give feedback.
-
|
There is a class called ClassRoutingHandler (IIRC) that performs the routing. If you put together a sample that works in RESTEasy Classic and not Reactive, I'll gladly take a look |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Quarkus 2.8 suggests that users should switch to RESTEasy reactive in favour of the classic non-reactive version. However, we have already come across two bugs (issues #25258 and #25263) (where the reactive version violates the JAX-RS specification) and one very annoying behaviour (accidentially mixing reactive and non-reactive dependencies) just within one day of trying to switch to reactive RESTEasy. This makes me doubt that the reactive version is actually production ready. But then again bugs in the classic version are not fixed any more, only in the reactive version (issues #24738 and #24736). Maybe you should reconsider this decision and apply some serious testing on the reactive version first, before you declare it the new standard. Just my two cents (and yes I'm a bit angry right now because I lost a whole day finding out why things suddenly don't work any more).
Beta Was this translation helpful? Give feedback.
All reactions