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

Hi, https://issues.jboss.org/browse/KEYCLOAK-7858 https://github.com/keycloak/keycloak/pull/5383 As for documentation, I'm experienced in technical writing, however I'll still need supervisor/reviewer since I'll be contributing to Keycloak docs for the first time. Idea: we could have (one day) something kind of "OSGi extras" for servlet filter adapter, containing bundle activator to install a filter + config resolver that would integrate with OSGi Config Admin Service. WDYT? Dmitry On Fri, 2018-07-13 at 15:36 +0200, Hynek Mlnarik wrote: Excellent. JIRA + PR for OSGi bundling would be welcome. Re the documentation, yes please, it will be necessary. It looks like the way you would describe would be applicable to any OSGi-compliant container, correct? Which OSGi release? Thanks, --Hynek On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: 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