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

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-adapter-spi/pom.xml#L119 > >   > > 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