"Just" dropping in jax-rs-pac4j-2.0.0-RC1.jar breaks webapp #18
Comments
|
You are right, nothing was ever done to make it work correctly with autoscanning and we should fix that :) The problem is that all the features in jax-rs-pac4j need a pac4j I'm not so familiar with autoscanning, maybe there is ways for you to declare the pac4j Config in a way that can be exploited by autoloaded jax-rs features. The first step I will take is remove the problematic For the second step, I will need some time (or help) to find an elegant way to make it work with autoscanning. |
|
I committed the first step. |
I had no expectations at all. However, is it possible to do it in a way that is similar to what you are already doing (and the way that JAX-RS does it in general): i.e., by allowing the user to define a |
That would make sense yes! As I said, I'm not familiar with these aspects of JAX-RS so your input is helpful :) What bother me (only as a perfectionist :) with Still, we can use it anyway, but I wonder if there is not a better way of injecting something into a feature like we want to… And actually, I'm not even sure that during @rwalkerands do you know of other means to do this kind of things? I did a quick search but couldn't find anything applicable… thanks for your hep :) |
|
I am no expert on JAX-RS, just a "happy customer" of some of the most basic features. In particular, I was not suggesting using |
|
@rwalkerands it was a good suggestion :) I'm just looking for the idiomatic way to do what we are trying to do and was wondering if you knew. I will continue looking a bit and then implement it during the week-end I think. |
|
Yep, no other way than using |
|
@rwalkerands It's not exactly what you wanted, but as a starter, could you try to see if the following work with you:
@Provider
public class Pac4JFeature implements Feature {
@Override
public boolean configure(FeatureContext context) {
context
//.register(new JaxRsConfigProvider(config))
.register(new Pac4JSecurityFeature())
.register(new Pac4JValueFactoryProvider.Binder())
.register(new ServletJaxRsContextFactoryProvider());
return true;
}
}@Provider
public class Pac4JConfig implements ContextResolver<Config> {
@Override
public Config getContext(Class<?> type) {
JaxRsConfig config = new JaxRsConfig();
// setup the pc4j configuration
return config;
}
}Note that you can either setup the My current problem is that for now, jax-rs-pac4j contains multiple implementations of mutually exclusive Provider (depending on the container), so if we annotate all of them, I think it will break stuffs, and if we annotate none, you will need the above Thanks for your help! |
|
I was able to get it to work, though it wasn't as straightforward as you suggest ... I needed to use the snapshot of pac4j-core as well, because you are relying on it (e.g., the change from Also, it is important to implement the Pac4JConfig.getContext() method as a singleton method. (E.g., define a private static field which is initialized only once, and which is returned on all subsequent method calls.) Otherwise, that initialization code is repeated for every request. (I am using AnonymousClient. Before making the getContext() method into a singleton, I was seeing the warning message |
|
Ha yes, good points! You are right, it's not correct to build the Anyway, except for the bother of porting your application to latest pac4j snapshot and the need to ensure the |
You are right. The field does not have to be static. I don't (yet) see any other problems. 👍 |
|
Thanks for the feedback! So for now, you can either:
I would recommend going with the 1.2.2 since it is more stable anyway :) |
|
|
ok, great, thanks for the extra information :) By the way, I wanted to ask you @leleuj, our problem here is that JAX-RS has a mechanism to autoload some modules (those annotated with What do you think of this situation and which solution seems to be better? I would go for the second one (with good documentation) because it is less hassle :) |
|
You wrote:
Actually, I am a bit confused. Did you mean to write "jax-rs-pac4j 1.2.2", or "pac4j 1.9.7", or ...? As I mentioned, I started using pac4j only last week, with v2.0.0-RC1. Whether this was a good idea ... anyway, what I have, is working. So I don't think I need/want to go "back" to pac4j 1.9.x. |
|
pac4j 1.2.2 must have been abandoned for years, it was about using jax-rs-pac4j 1.2.2. In all cases, we focus our efforts on the incoming version 2.0.0; so it's better to start using it. @victornoel : having multiple modules seems a huge burden to me, I would choose to not annotate the modules and document the |
|
Ok, I will document that, cleanup things and then close this issue which should integrate 2.0.0-RC2 :) |
|
@rwalkerands FYI, jax-rs-pac4j 2.0.0-RC2 was released today, I will soon document what I explained here in the README, but you can already start using it (and report any problem that you have with it ;). Thanks again (I will close this issue when the documenting is done!) |
I'm just (today) getting started with pac4j, and I'm adding it to an existing webapp built on Jersey. (I use Tomcat as my Servlet container.)
I have happily been using Jersey's (JAX-RS's) auto-scanning to find resources and providers, i.e., I have no Application or ResourceConfig subclass.
My setup is as described at https://jersey.java.net/documentation/latest/deployment.html#deployment.servlet.3.pluggability.noapp (4.7.2.3.1. JAX-RS application without an Application subclass).
I started by dropping in the pac4j-core-2.0.0-RC1.jar and a few others (for http, jwt, ldap). No problem with the webapp starting up after that.
But then if I add jax-rs-pac4j-2.0.0-RC1.jar, I now get an error on startup:
And then every request generates an exception (
javax.servlet.ServletException: Servlet.init() for servlet javax.ws.rs.core.Application threw exception...).So is it the case that I can't keep using Jersey's auto-scanning if I want to use jax-rs-pac4j?
Do I have to create an Application/ResourceConfig subclass?
The
README.mdseems to assume I have already done that.I think it would be "nice" for users (not just me) if you could support configuring the providers and features when using the other "modes" of defining resources, i.e., so that you don't have to define an Application/ResourceConfig subclass "just" to configure jax-rs-pac4j.
I should say: I have been able to create a ResourceConfig subclass that "works": webapp startup no longer fails, and resources seem to respond correctly. But now I "worry" if I'm missing something by bypassing Jersey's auto-scanning.
The text was updated successfully, but these errors were encountered: