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.

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

Value injector for RESTEasy #31

Merged
merged 4 commits into from
Nov 21, 2017
Merged

Value injector for RESTEasy #31

merged 4 commits into from
Nov 21, 2017

Conversation

yegorius
Copy link

What do you think?

@victornoel
Copy link
Member

Oh great! I'm going to review this soon!

@victornoel victornoel self-requested a review November 16, 2017 07:40
@victornoel victornoel self-assigned this Nov 16, 2017
@victornoel
Copy link
Member

You should already try to enable the tests that involve the annotations, it's easy, there is just some empty overriding test method to remove normally.

Copy link
Member

@victornoel victornoel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank, there are some points that should be improved but it's great already :)
Could you:

  1. enable the tests (remove the empty overriding tests in RestEasyUndertowServletTest and enable the feature in RestEasyUndertowServletRule)
  2. find out why some tests do not pass (actually, if you run all the tests of RestEasyUndertowServletTest some tests do not pass, but if you execute them one by one, they do... there is something fishy with state that is not cleaned as expected or maybe it is resteasy...
  3. Add some very basic documentation (in the same way as the jersey feature)

);
} else {
return new Pac4JValueInjector(
(req, resp) -> new ProfileManager(new J2EContext(req, resp)).get(profile.readFromSession()).orElse(null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the jersey implementation, I preferred to throw an new WebApplicationException(401) instead of returning null.
The rational is that if you want to retrieve a profile that can be potentially not there (i.e. you are not authenticated), then you use the Optional.
If not (i.e., you are expecting to be authenticated, then the profile shouldn't be null, then we should't allow for such situation, especially because it introduces a security risks.

Actually one of the test relies on this behaviour ;)

See https://github.com/pac4j/jax-rs-pac4j/blob/master/src/main/java/org/pac4j/jax/rs/jersey/features/Pac4JValueFactoryProvider.java#L246

this.provider = provider;
}

public Object inject(HttpRequest request, HttpResponse response) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add an @Override annotation here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return inject();
}

public Object inject() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add an @Override annotation here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -131,6 +131,10 @@ public PrincipalImpl(LinkedHashMap<String, CommonProfile> profiles) {
this.roles = Collections.unmodifiableSet(rs);
}

public CommonProfile getProfile() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not related to this PR, right? I would prefer you remove it then :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,79 @@
package org.pac4j.jax.rs.resteasy;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this class into org.pac4j.jax.rs.resteasy.features, it would make more sense with the organization of the rest of this library :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@victornoel
Copy link
Member

There are also some formatting problems... some tabs crept up :)

@yegorius
Copy link
Author

I am investigating issues with tests right now.

@yegorius
Copy link
Author

The only test which fails for me is testInject(). And it only fails when it is being run with other tests. If I launch this single test, then it passes.
I get a weird error message from Undertow: UT005014: Failed to parse HTTP request.
Which happens because this is exactly(!) what it receives on the wire (I have copied the complete byte buffer from the Undertow request parser):

User-Agent: Java/1.8.0_152-release
Host: localhost:24257
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: close
Cookie: JSESSIONID=5icpg-Zdu3SOLgo2QXDn_s2X_zzO00y5auNK9hqu

At this moment, I have no clue.
I have added a delay in the very beginning of testInject() for 5000ms and all tests pass now, but this is obviously not a solution, it's more of a hint for us.

@victornoel
Copy link
Member

Thanks for the exploration.
I suppose it is undertow's closing that is not properly synchronized with the execution of tests or something like that… I say that because I've noticed harmless (until now...) undertow errors in the logs at the end of the tests before.
I will try to find the time to fix this next week-end, but if you feel like it, don't hesitate to continue exploring and maybe finding the solution ;)

@yegorius
Copy link
Author

I have ignored the failing test so that the build is successful now. I have also updated the documentation.
Would you mind merging this PR in this state and moving the test problem to a separate GitHub issue?

@victornoel
Copy link
Member

yes, ok, let's do that

@victornoel victornoel merged commit 7eb19c5 into pac4j:master Nov 21, 2017
@victornoel
Copy link
Member

Thanks again @yegorius :)

We should do a release soon then! Maybe 2.1.0 @leleuj, what do you think?

@leleuj
Copy link
Member

leleuj commented Nov 21, 2017

Yes, it makes sense. It'a noticeable update. Starting...

@leleuj
Copy link
Member

leleuj commented Nov 21, 2017

@victornoel The version is still 2.0.3, I think it should be 2.1.0 as it's a backward compatible change (not a bug fix), isn't it?

@victornoel
Copy link
Member

yes, 2.1.0 is a good number! (that's what I was saying in my comment above ; )

@leleuj
Copy link
Member

leleuj commented Nov 21, 2017

Yes, right. I just performed the release, it will show up in the Maven central repository in a few hours...

@victornoel victornoel added this to the 2.1.0 milestone Nov 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants