Repository navigation
Replies: 8 comments 14 replies
|
When building a fat jar and adding that as a custom provider, I get the following error: |
|
Please check the server developer guide. In essence just copy additional dependencies to the providers directory |
|
This is what the dependency tree looks like for the Kinesis library: are people really expected to find the relevant dependencies for their usage of the library and then upload the jars for each of those manually? Doesn't seem like a practical solution at all. |
|
If using maven, use the maven assembly plugin to build a zip / tar archive that includes the built jar and all its runtime dependencies. Use dependencySets in assembly descriptor. see https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html. If using gradle, use gradle Java Library Distribution Plugin. see https://docs.gradle.org/current/userguide/java_library_distribution_plugin.html |
|
@stianst I found this similar issue to mine with the fat jar from older versions: https://issues.redhat.com/browse/KEYCLOAK-4428?workflowName=GIT+Pull+Request+workflow+&stepId=6. Here the solution was to include keycloak-services in the |
|
@mimozell Thanks. After adding the hibernate validator extension to the distribution the errors are gone and it seems to work fine (even though not yet integrating with Kinesis). Of course, I've also added all jars from Would you be able to build the distribution from this branch [1] and then check how it works for you? This should not be the final solution though and the proper solution involves solving a more general issue when deploying providers with 3rd party dependencies. But I would like to see at least how it works for you to make sure we have something to think/build on top. [1] https://github.com/pedroigor/keycloak/tree/tmp-add-hhh-validator |
|
I'm going to try to slim down too the dependencies that you actually need to include into providers directory so that we can also think how to make easier the step of figuring out which dependencies you need to include. |
|
How are you building the docker image out of the source? I didn't find any documentation around it or a relevant Dockerfile. I tried: |
|
I'm not building an image but running locally. Here is the branch https://github.com/pedroigor/keycloak/tree/tmp-add-hhh-validator. |
|
Since I am deploying a container it would be great if there could be a guide on how to build the Docker image out of your branch and then I just keep things exactly as they are on my side. If not, then pointing to some guide on how to start the service locally and how to easily extend it with my jar would be great. |
|
@DGuhr @stianst I think we have a pretty good use case to start thinking about how to deal with providers using 3rd party dependencies. IMO, if we can think/build something on top of it we should be able to solve most of the issues we are facing now when migrating providers from Wildfly:
|
|
hi @pedroigor, do you know if any work was done on the points from your list above? I have a related question: is it possible to package providers as JPMS/Jigsaw modules? I assume not at the moment because of the single classpath, but did you consider this/is it something that may appear in the nearest future? Thanks |
|
It looks like in theory, it is possible to use both module path and classpath in the same app [1]. So, again, in theory, it should be possible to create a provider JAR as a JPMS module and add it explicitly to the Keycloak classpath using the Related article on java service loaders with JPMS: |
|
TBH, I did not try it yet but as you said, it should be possible in theory. However, whatever JAR you put into |
|
In which copies the jars of the libraries that I am referencing and their dependencies into the jars directory excluding everything by keycloak which should already be present ( |
|
If there's still someone facing the same Keycloak dependency issue and doesn't know how to go forward, I’ve put together a guide that's related to the helpful advice discussed here. Mainly because I didn't find such a guide myself. It covers the steps required to make 3rd party dependencies available inside Keycloak from scratch. At least it can be a starting point to build an even better solution on top. https://medium.com/@jesevis/using-3rd-party-dependencies-in-keycloak-a63208d43cba |
|
Right now, it is quite hard to provide an external dependency within your extension without the shaded JARs. In the meantime, there is this Keycloak Quarkus extension community project, which will build your own Keycloak distribution based on the upstream build mechanism with the required dependencies or Quarkus extensions. You can check the examples on how to achieve this. For instance, you should be able to add the dependency via the tool as follows: # add the required dependency
./kc-extension.sh add com.amazonaws:amazon-kinesis-producer:0.14.10
# build the custom distribution
./kc-extension.sh build
# start the custom Keycloak instance and try it out
./kc-extension.sh start-dev
# (optional) create a builder container image
./kc-extension.sh image |
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I'm new to Keycloak and we just switched to version 17, but we had the same issue in the previous version. I am working on emitting user change events to AWS Kinesis, but I notice the following errors when running the code:
java.lang.NoClassDefFoundError: com/amazonaws/auth/AWSCredentialsProvider. This happens with other classes as well. I am importing the Kinesis dependency using Gradle in the following way:AWSCredentialsProvideris a dependency under theimplementation 'com.amazonaws:amazon-kinesis-producer:0.14.10'library so I would expect not to have to import anything else in order to support that. I wouldn't have to if this was a Spring Boot application.In a similar way, I am struggling getting Kotlin support. Ideally I would want it to be covered by
build.gradleand not to have to set up providers specifically for all the different dependencies I might need or the dependencies those dependencies need. Is there something I am missing during the packaging of the jar that is causing this issue or are we fundamentally expected to provide the jars for each dependency and third-party dependencies manually?For Wildfly I had to set up a script like this:
and then Kotlin was supported, but not the Kinesis library and its dependencies. Once I added the Kinesis jar, still the dependency that
AWSCredentialsProvidercame from wasn't supported. If we have to add all the jars for all the dependencies separately, that would bring in a lot of work as the third party dependencies can be "endless".All reactions