Re: [keycloak-dev] Keycloak servlet filter adapter on OSGi, first impressions

Hi Hynek, Thanks for the OSGi fragment tip, it worked perfectly. Also glad to hear the HTTP Components dependency issue has been resolved. So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by the way, should we document how to use this adapter on OSGi? Installing a bundle is not sufficient, the filter should be registered with OSGi HTTP Service, and there are at least two ways of doing it (via BundleContext::registerService or via a @Component that extends the filter class). What do you think? Dmitry On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote: Hi Dmitri, thank you for the updates. The 1. (dependencies on Apache HTTP Components) has been resolved in the latest master already and the -thirdparty module has been removed. Hopefully this addresses your concerns completely. Ad 2. we have taken approach with OSGi fragment when resolving similar situation with server-specific implementation, see e.g. [1]. This is preferrable to moving classes to different packages. Could you take this approach? [1] https://github.com/keycloak/keycloak/blob/master/adapters/spi/undertow-ad... On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: Hi, We are working on integrating Apache Sling with Keycloak (see my posting from June 12). It was suggested that we'd stick to servlet filter adapter as the most generic one (unlike Keycloak OSGi adapter which is more of a JBoss Fuse adapter). The first step was to convert keycloak-servlet-filter-adapter and required keycloak-servlet-adapter-spi to OSGi bundles. This went OK, I've just added OSGi bundling to the respective POMs. However there were two major issues when deploying and running the code: 1. Bogus dependency on org.apache.http.* Several Keycloak modules the adapter depends on, namely keycloak-authz-client and keycloak-adapter-core, declare bogus "Import-Package: org.apache.http.*;version=4.5.2" dependency. This comes from the following lines in the POM: <keycloak.osgi.import> org.keycloak.*;version="${project.version}", org.apache.http.*;version=${apache.httpcomponents.version}, ... </keycloak.osgi.import> org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi, which uses its own versioning scheme (4.4.9 is the latest version ATM). Thus, deploying the bundle to OSGi runtime fails due to unsatisfied dependency. Later, I've discovered there's keycloak-osgi-thirdparty bundle that provides required dependencies (however, they don't become less bogus because of that). I'm OK with this workaround, but generally speaking, is keycloak-osgi-thirdparty still needed? I've got an impression it was created at a time when not every dependency was available as OSGi bundle. Current version of keycloak-osgi-thirdparty contains merged httpclient and httpcore, which are available as org.apache.httpcomponents:httpclient-osgi and org.apache.httpcomponents:httpcore-osgi, respectively. So to me it seems like a candidate for deprecation and removal. If so, the bogus dependency issue, obviously, should be tackled with first. 2. Split package org.keycloak.adapters.servlet > In standard Java programming, packages are generally treated as > split; the Java class path approach merges all packages from > different JAR files on the class path into one big soup. This is > anathema to OSGi’s modularization model, where packages are treated > as atomic (that is, they can’t be split). http://web.ist.utl.pt/ist162500/?p=65 In Keycloak, the package org.keycloak.adapters.servlet is split between keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This leads to seemingly inexplicable NoClassDefFoundError's, when e.g. KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The recipe provided by the above article (create dummy bundle, prohibit direct imports etc.) is rather cumbersome, so I've just created org.keycloak.adapters.servlet.spi package and moved there the two classes from keycloak-servlet-adapter-spi. After that, I was finally able to wire Keycloak filter to a test servlet, and it worked pretty well. There was a redirect to Keycloak's login screen, then redirect back, and the servlet was able to obtain valid KeycloakPrincipal with JWT token. To sum up, I'm eager to contribute changes required to make Keycloak servlet filter adapter a valid and working OSGi bundle. That would include OSGi bundling for two modules and split package refactoring. The first issue (bogus deps) IMO should require further discussion. Let me know what you think, Dmitry Telegin CTO, Acutus s.r.o. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev