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&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

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

> > > It looks like the way you would describe would be applicable to > > > any OSGi-compliant container, correct? Which OSGi release?

Thanks for the PR. Ad the documentation - the best suitable place would be [1]. Since this would currently be for community only, please enclose it into similar if-endif like here [2]. The PR would be submitted under the same KEYCLOAK issue as implementation, i.e. KEYCLOAK-7858. And no worries, we will be happy to help shaping up the documentation in the PR, just send what you would have and we'll help out. Thank you --Hynek [1] https://github.com/keycloak/keycloak-documentation/blob/master/se curing_apps/topics/oidc/java/servlet-filter-adapter.adoc [2] https://github.com/keycloak/keycloak-documentation/blame/master/s ecuring_apps/topics/oidc/java/application-clustering.adoc#L4 On Mon, Jul 16, 2018 at 2:54 AM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: > Hi, > https://issues.jboss.org/browse/KEYCLOAK-7858https://github.com/key > cloak/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-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