Repository navigation
Migrating to Quarkus Provider Issues #20092
Closed
jhelsethbushel
started this conversation in
Archive
Replies: 3 comments 1 reply
|
@jhelsethbushel Hello, would you be able to share a reproducer as you mention it here?
|
1 reply
|
In my attempt at recreating the issue, I found that our gradle shadowJar task is what was causing the SPI issues with quarkus. When I took the direct jar from our custom provider it loaded into quarkus just fine. |
0 replies
|
Since I am able to make progress after removing the shadowJar task, I am going to close this discussion. @vmuzikar thanks for looking into my discussion. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello,
We are trying to migrate from Keycloak 18.0.2 wildfly to Keycloak quarkus. We had attempted the migration before, but other priorities came up. We have custom provider code that has extended themes, user-federation, and backend code for our authentication flows. The custom provider we built works well with 18.0.2 wildfly and worked with 17.0.1 quarkus (a few modifications). We can't seem to deploy our custom provider without subtype errors to 19.0.0 wildfly, 18.02 quarkus, or 19.03 quarkus. In each of the situations we have a different SPI library complaining about a subtype error.
Here is the error I get when Keycloak 18.0.2 quarkus is trying to build the custom provider jar:
If I compile the jar without code and only have one dependency in my build.gradle file (not actually used)
implementation "org.keycloak:keycloak-server-spi:18.0.2" I get this build error:
Does anyone know why the SPI error changes, but an SPI error always occurs when I include org.keycloak:keycloak-server-spi:18.0.2? Any insight would be helpful.
Here is the 19.03 quarkus error when Keycloak tries to build the custom provider:
What is the cause of the subtype error when using a custom provider (any situation) and what can we do to fix it? I know that we are using older versions of keycloak and haven't caught up to the newest yet, but this issues are preventing us from getting closer to the newer versions.
We have tried doing things like using gradle to only bundle certain libraries, but one thing that we are doing that could be getting in our way is using a shadowJar to package many subprojects. Would it make sense for us to break things into smaller jars, or does that not really matter in this case?
Any help would be greatly appreciated. I can't share my repository, but I could post snippets in a discussion or do a screen sharing session to walk through pieces of the code that could be problematic.
Thanks,
Jayson Helseth
All reactions