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/und
ertow-adapter-spi/pom.xml#L119
On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt(a)acutus.pro> 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