Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RestEasy extension no longer picks up Resource implementations with a corresponding interface #3871

Closed
garyttierney opened this issue Sep 5, 2019 · 4 comments
Closed

RestEasy extension no longer picks up Resource implementations with a corresponding interface #3871

garyttierney opened this issue Sep 5, 2019 · 4 comments
Labels
kind/bug Something isn't working triage/invalid This doesn't seem right

Comments

@garyttierney
Copy link
Contributor

Describe the bug

Previously it was possible to create an interface specification of a JAX-RS resource, and implement it separately:

common-project/MyResource.java

@Path("/")
interface MyResource {
    @GET 
    String value()
}

quarkus-project/ServerMyResource.java

class ServerMyResource implements MyResource {

    @Override 
    public String value() {
        return "value";
    }
}

Expected behavior

Accessing / in my Quarkus application should return "value".

Actual behavior

I see a 404 instead.

To Reproduce
Steps to reproduce the behavior:

  1. Create a new JAX-RS resource with the JAX-RS annotations on an interface
  2. Attempt to access the resource paths via. a Quarkus app

Configuration

N/A

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

Additional context

This only became a problem as of 21.0, in 20.0 it still works fine. I've put together a test case to verify this behaviour:

public class RestEasyAbstractResourceTestCase {
    @RegisterExtension
    static QuarkusUnitTest runner = new QuarkusUnitTest()
            .setArchiveProducer(() -> ShrinkWrap.create(JavaArchive.class)
                    .addClasses(ConcreteRootResource.class));

    @Test
    public void testRootResource() {
        RestAssured.when().get("/").then().body(Matchers.is("root"));
    }
}

public class ConcreteRootResource implements AbstractRootResource {

    @Override
    public String root() {
        return "root";
    }
}

@Path("/")
public interface AbstractRootResource {

    @GET
    String root();
}

Which fails with the following (not sure why it's manifesting as unauthorized):

[ERROR]   RestEasyAbstractResourceTestCase.testRootResource:20 1 expectation failed.
Response body doesn't match expectation.
Expected: is "root"
  Actual: <html><head><title>Error</title></head><body>Forbidden</body></html>
@garyttierney garyttierney added the kind/bug Something isn't working label Sep 5, 2019
@garyttierney
Copy link
Contributor Author

Update: this stemmed from the fact that my project is a multi-module project. In 0.20.0, one of my modules was included in the Jandex index even though it had no beans.xml or application.properties listing.

I'm not sure if this a regression, but I do wonder if we can handle the multi-module case in a better way (is sticking all our user modules in the Jandex index a reasonable thing to do?)

Happy to close this unless the behaviour is viewed as a regression.

@mkouba
Copy link
Contributor

mkouba commented Sep 6, 2019

In 0.20.0, one of my modules was included in the Jandex index even though it had no beans.xml or application.properties listing.

This is how bean discovery currently works in Quarkus, ie. a module must contain beans.xml, META-INF/jandex.idx or be referenced by quarkus.index-dependency in application.properties. See https://quarkus.io/guides/cdi-reference#bean_discovery for more details.

So I'd say it's not a regression but a fixed bug in the gradle integration.

but I do wonder if we can handle the multi-module case in a better way

Hm, something like "add all modules from the project automatically" similarly as we do with the root? I'm not sure it's a good idea. @stuartwdouglas @gsmet @aloubyansky @geoand WDYT?

For now just add an empty beans.xml descriptor and you're done.

@geoand
Copy link
Contributor

geoand commented Sep 6, 2019

Hm, something like "add all modules from the project automatically" similarly as we do with the root? I'm not sure it's a good idea. @stuartwdouglas @gsmet @aloubyansky @geoand WDYT?

Maybe this would create more problems that it solved? Not sure either, so just asking

@stale
Copy link

stale bot commented Nov 13, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you!
We are doing this automatically to ensure out-of-date issues does not stay around indefinitely.
If you believe this issue is still relevant please put a comment on it on why and if it truly needs to stay request or add 'pinned' label.

@stale stale bot added the stale label Nov 13, 2019
@gsmet gsmet added the triage/invalid This doesn't seem right label Nov 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Something isn't working triage/invalid This doesn't seem right
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@mkouba @garyttierney @gsmet @geoand