We Keep Coding

Keycloak custom provider with Quarkus extension - where to put quarkiverse jars as dependencies?

I'm writing custom Keycloak provider which needs quarkus-cxf extension as a dependency to integrate with a SOAP service. Everything works well in the development mode (I use maven, so I needed to add quarkus-cxf as a dependency and run Keycloak on Quarkus from IDE using IDELauncher).
The problem starts when I'm trying to deploy my custom provider to the production environment. I know that my provider's jar need to be placed in providers directory within Keycloak distribution. Somewhere on Keycloak webpage I saw that every third-party dependencies jars I use, need to be placed in providers directory as well, so I did that and (thanks to maven-dependency-plugin) I generated all quarkus-cxf dependencies and put them all into providers directory. Then I tried to build keycloak by running ./kc.bat build and it failed with the message: ERROR: io.smallrye.config.SmallRyeConfigFactory: io.quarkus.runtime.configuration.QuarkusConfigFactory not a subtype.
How it should be done to work properly? I need CXF dependencies in the build phase because I generate code from WSDL file and it's necessary for Quarkus augmentation. Maybe not all dependencies from quarkus-cxf dependency hierarchy are needed here, but I cannot imagine developing and then adding one by one jar and check if it's enough for build or maybe not and I will get NoClassDefFound error :) I've got the same problem with my previous extension where I used resteasy dependencies but then only few jars were missing so I put them into providers directory and it worked. It's not the best solution for each and every one extension with extra dependencies like cxf (with huge hierarchy of transient dependencies).
Does anyone help me in this case? Maybe some of you have the same problem and you know how it should be done.

Gradle: Add dependency of subproject as dependency of the root project

We are running our Java EE applications in WAS 8.5 and Gradle 5.* to build them.
In the past we packaged our .war application in an .ear archive, which we then deployed on our server. We had to separate our libraries from our applications and include them as shared libraries, because in our experience it made deploying much slower and in some cases used up all system memory, crashing the server.
After some experimentation, we realized that we don't need to extract the dependencies into shared libraries, because we can include them in the lib folder of our .ear archive.
Currently, we get this done by defining the dependencies of our .war application as compileOnly and redefining them as earlib in the root project (which generates the .ear archive). I'm looking for a way to automate this procedure.
The script I used looks something like this:
project.configurations.named('deploy').getAllDependencies().withType(ProjectDependency.class).forEach({dependency ->
project.configurations.named('earlib').getAllDependencies()
.addAll(dependency.dependentProject.configurations.named('earlib').getAllDependencies())
})
// This loosely resembles the actual code I used. The thought process is right, it just might have a couple syntax errors.
// Obviously, I defined an `earlib` configuration in the subproject
I tried running this code in the configuration phase, as well as in the doFirst{} section of the ear task. They all had different problems.
The former didn't work, because it seems like in the configuration phase when this code ran, the dependencies weren't configured yet.
The latter didn't work, because I can't just add dependencies during runtime (thinking back, it sounds ridiculous that I even tried it).
My question is: Can I find a phase in the build lifecycle, where I can find and modify the dependencies? Is there another workaround to solve my problem?

The technical answer to your questions is that you can use either:
A configuration.incoming.beforeResolve hook to do it last minute, only when the configuration really needs to be resolved.
Use an afterEvaluate block, assuming all the other dependencies are not defined in an afterEvaluate themselves.
However, the right solution would be to leverage the dependency management engine of Gradle and effectively declare that your root project, the one building the EAR, has dependencies on the specific configurations of the subprojects.
Not knowing your full setup and details, I believe the above would still be the more correct solution, though you may have to filter the subproject artifacts from the resulting graph.
Ideas on how this works in recent Gradle version: https://docs.gradle.org/6.2/userguide/cross_project_publications.html Most of the things explained there should work with the latest 5.x versions.

Drools OSGi integration - Apache Felix

i'm trying to integrate drools engine inside an Apache Felix container.
I can't find ANY official resource regarding the installation process. The official documentation of drools 6.4.0.Final only state that drools is OSGi ready
Can someone give me useful informations ?
What I did so far:
I've tried integrating the OSGi bundle that is contained in the Drools zip distribution that can be downloaded from the official site. I couldn't find documentations out there neither technical release notes in the .zip file, so I started adding to my target platform (based on Apache felix) the kie-ci-osgi-6.4.0.Final.jar contained in the osgi-binaries folder.
I saw that there were lots of unresolved dependencies, so i tryed to manually add every jar, before giving up because I couldn't find nor understand what's was happening.
After that I tryed the same flow with this jar. I also dowloaded with maven cli every dependencies without success

SRVE9967W: The manifest class path xercesImpl.jar can not be found in jar file

I've been going in circles on this one. We're using WebSphere Liberty, Eclipse, and Maven. I'm getting several warnings like
[WARNING ] SRVE9967W: The manifest class path xercesImpl.jar can not be found in jar file file:/C:/Users/.m2/repository/xalan/xalan/2.7.1/xalan-2.7.1.jar or its parent.
when I start up the server. For all the "class path something.jar"s, they are there in the Maven Dependencies folder in my project, and in my repo though they have a version number attached (e.g. xercesImpl-2.11.0.jar). It claims that the application is available, but if I try to go to the address, I get all kinds of nasty errors, mostly class not found.
When I try to package my project through Maven, I'm getting
[WARNING] Could not transfer metadata org.apache.maven.plugins/maven-metadata.xml from/to all-external-repositories-mirror (http://mirror/m2-repo/content/groups/adc-standard-repositories): null to http://mirror/m2-repo/content/groups/adc-standard-repositories/org/apache/maven/plugins/maven-metadata.xml
I'm about 70% sure this problem comes down to the fact that our project's Maven uses a mirror that I can't access from here, and I'm about 90% sure there is a work around to use my local repo, but I haven't been able to figure out where to look to make that change. I tried searching the entire workspace for any mention of xerces or xalan, but came up with nothing.
I swear it was using my local repo before as long as I had the jars. I also find it strange that it compiles and lets me run tests without complaining about this.
Any ideas, even just on where to look would be greatly appreciated. A good number of the things I found talking about a similar error mention WebSphere (and more specifically Liberty) so I'm also wondering if it has something to do with the way WebSphere deploys.

It has actually nothing with WebSphere. In your xalan-2.7.1.jar which is added to the project, there is META-INF/MANIFEST.MF file. And in it, you will find classpath like this:
Manifest-Version: 1.0
Created-By: 1.3.1
Main-Class: org.apache.xalan.xslt.Process
Class-Path: xercesImpl.jar xml-apis.jar serializer.jar
as you can see classpath refers to xercesImpl.jar, unfortunately your build is creating xercesImpl-2.11.0.jar, so it just cannot be resolved. However this is only a warning and application should run fine if the xercesImpl classes are available in the classpath.

Java classloader with same jar

I know that many subject speak about classpath loader and transitive dependancy but i m little confused.
I m working on a legacy application that use spring 2.0.5 and spring-ws and all work fine from the beginning of the project to now.
And recently we are faced to a runtime problem with a an exception like methodnotfoundexception.
In fact we see that spring-ws depend on spring-2.5. So maven transitive dependancy add spring 2.5 in my webinf/lib directory near spring 2.0.5
But i dont understand why all working fine during many years and now why weblogic decide to load spring2.5 before spring2.0.5 and cause this error?
We have correct the problem and now i m looking for same jar with different version and do build failure when i have a conflit to avoid dependancy problem in the future.
But i just want to understand why weblogic decide to load one or another jar ? Because if its alphabetical order, same jar will be loaded all the time, but in my exemple the order change...
So i don t understand clearly whats happened.
Thanks by advance;)

While it is documented that WEB-INF/classes is loaded before WEB-INF/lib, the documentation is not clear in cases like yours - where there are sibling copies of Spring in the WEB-INF/lib.
In Tomcat it is alphabetical, but looks like Websphere, Jboss and Weblogic are random. See https://stackoverflow.com/a/5817890/327426
From some threads on the Oracle forums, the recommendation is to run the Classloader Analysis Tool available at http://docs.oracle.com/cd/E23943_01/web.1111/e13706/classloading.htm#BABHJGJJ for your app and see the results. This tool will identify classloading conflicts.
See similar issue at https://community.oracle.com/thread/2387921?tstart=0
This post from 2009 http://www.coderanch.com/t/472496/BEA-Weblogic/Loading-order-jar-WEB-INF on Weblogic v9.2 states "Checking the logs I see the .jars in WEB-INF/lib are being loaded in reverse alphabetical order". This may or may not be true for your version
Another option is to use Maven to bypass the transitive import being packaged in the WAR