-
Notifications
You must be signed in to change notification settings - Fork 86
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
UnsupportedOperationException for request scoped bean with parameter #362
Comments
@TobiasBerndt Apologies for the delay. The holidays were difficult. If you are still struggling with this, could you please provide a sample project with minimal dependencies, so I can try to reproduce the issue? |
@lincolnthree
|
Ok, that makes some sense. If the WebApplicationContext is yet not available in a request (for instance, if Spring hasn't started yet), it's possible that the ServletFilter ordering needs to be adjusted so that Spring initializes first, then Rewrite does. You could try re-ordering the servlet filters in your application - let me know if that resolves the exception? I've got this issue on my tasks list for next day or so, today if I can finish up the Monday tasks. I'll take a closer look soon. Sorry for the delay. |
I saw in |
Hi Tobias, apologies for the delay. I've got some crazy stuff happening here right now. I still need to dig more, but... I'm looking at your first (original) exception where On first glance I do see one issue, but I'm not sure if it would cause this problem. First, you have You should have something like this instead:
Otherwise you are specifying a parameter which is unbound. I'm honestly not sure we even have a test for this scenario so it's definitely something I'm going to take a closer look at. |
As for the startup error. I'm worried that this might be some circular initialization loop where SpringBoot is trying to start the WebApplicationContext, then Rewrite tries to start up and request bean names to create the configuration, then SpringBoot says, "Hey, I'm not ready yet and don't have a WebApplicationContext", and returns null back to Rewrite. Digging deeper. |
First of all thank you for taking care about this issue.
I use the parameter as a GET parameter e.g. http://localhost:8080/mypath?someParam=something and I thought the only difference to having it not in the path is that it's not mandatory to set. At least in the example here the parameter is also not part of join path.
To understand wants going on there I have set a breakpoint in
|
Okay, so I think I know why this is happening. First, the startup error is caused because you need to extend This resolves the startup error:
Next, regarding the PrettyFaces error when loading the |
I thought
Nevertheless I tried it with |
[Edit. You are correct -- This doesn't fix the issue. I think it just changed the order of classloading and a different issue came up first.] Please ignore. |
Ok, so from what I can tell, it appears that Spring Boot is misconfigured or incompatible somehow. The Spring Generally, when configuring Spring Manually, you'd ensure this happens by ordering Spring's
I've tried all the solutions proposed here: https://stackoverflow.com/questions/33486219/spring-boot-no-webapplicationcontext-found, but I suspect something is interfering with or overriding the boot order. I might suggest checking with the JoinFaces folks and see what they are doing in this regard, and if there is any way to override their defined start order (if they've set one, which I presume they have.) |
The "problem" is that See also Instead it relies on |
Hey @larsgrefer! Thanks for the info and for pointing me toward I think the better solution here would be to make the Rewrite Here's what I propose, regardless of where the fix goes:
I am working on a new release/snapshot that should resolve this, regardless :) Let's see if we can get it taken care of! |
The interesting SPI is |
That might work if we switch to using |
|
Right, that's why I think it should be used if possible. Once we have access to the |
BAM. It works. This is MUCH cleaner. Thanks @larsgrefer.
|
Additionally. I have improved the expression language bean name resolution so that it tries providers until either it finds one that works, or they all fail. |
@larsgrefer I believe I have resolved this. Please review the pull request if you have some time :) I'll release a new version soon if you approve - #368 @TobiasBerndt You should be able to try the changes if you clone my fork and run |
I tested the changes successfully with |
Thanks for confirming, @TobiasBerndt - Apologies for the delay in moving forward with this. The past few weeks went off the rails. I am working on getting this PR merged with @larsgrefer's changes, and pulled into the other release tracks/branches as well. |
Hi @lincolnthree, now I lost also track on this 😊 |
Hey @TobiasBerndt - Yeah, there are a number of pending updates that I need to get merged into the three primary branches. This is one of them. Sorry for the delay. Trying to make some time in the next week. Are you blocked by this currently, or can you use the local build temporarily? |
I'm not blocked right now as I have a workaround by not using 3.5.1.Final and staying on 3.4.4.Final |
@TobiasBerndt Joinfaces 5.x currently includes Rewrite 6.0.0.Alpha1: https://docs.joinfaces.org/5.1.x/reference/#versions |
Note. This issue may still require more work, and I am still planning on merging the Spring Boot improvements in PR #375 |
Versions:
On initializing RewriteFilter for request scoped bean 'MyController' (see below) during spring boot application start-up the following exception occurs.
The text was updated successfully, but these errors were encountered: