<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><i>@Christian:</i> Actually in
Hibernate 5 the Integrator does not offer the add entity feature
anymore. It seems this 'feature' was actually an unintended side
effect of the Integrator in Hibernate 4
(<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/32918808/how-to-use-integrator-service-in-hibernate-5-for-adding-annotated-classes">http://stackoverflow.com/questions/32918808/how-to-use-integrator-service-in-hibernate-5-for-adding-annotated-classes</a>
- <i>"but the docs clearly point towards that not being
intentional as this should be done at the time of
initialization"</i>). This complies with my finding that adding
the entity classes at this 'late' stage skips some validation. So
I guess I'll 'revert' my solution to the one I found previously,
which adds the entity classes to the JPA persistence unit
configuration. I'll investigate if that is Hibernate 4 and 5
compatible.<br>
<br>
<i>@Stian: </i>It seems like almost all questions have been
answered and we can start to build the feature and contribute it
to KeyCloak. Maybe you can provide some extra information /
requirements / guidelines to us. (we did read the 'Hacking on
Keycloak' page)<br>
- Is there a KeyCloak checkstyle configuration?<br>
- Do we have to create one entry in the KeyCloak JIRA for this or
several under one epic?<br>
- Is there some peer review process? How does it work?<br>
- What are the requirements for the documentation?<br>
<br>
<br>
<br>
On 12/11/15 17:20, Christian Beikov wrote:<br>
</div>
<blockquote cite="mid:5644BC26.60602@gmail.com" type="cite">
You need different code for Hibernate 4 and 5 because the
integrator interfaces are not compatible.<br>
The integrator is a service that is loaded through a
java.util.ServiceLoader so I am not sure why you would need the
property.<br>
<div class="moz-signature"><br>
Mit freundlichen Grüßen,<br>
<hr>
<b>Christian Beikov</b><br>
</div>
<div class="moz-cite-prefix">Am 12.11.2015 um 17:14 schrieb Erik
Mulder:<br>
</div>
<blockquote cite="mid:9A5619B792BBA041AE094585791BB71C0137B668B07A@DDPEX01.DDP.dcloud.local" type="cite">
<div class="moz-cite-prefix"><i>@Christian Beikov</i>: Thanks
for the hint on integrators!<br>
<br>
I was afraid I could not use integrators when working with the
JPA 'route', but I found a way. There is a property
<tt>EntityManagerFactoryBuilderImpl.INTEGRATOR_PROVIDER </tt>that
you can use to supply custom integrators. This even works with
the original 'pure' JPA call:
<tt>Persistence.createEntityManagerFactory</tt>. In the
integrator you can add annotated classes to the Hibernate
Configuration. So the solution is still Hibernate only of
course.<br>
<br>
The only downside is that there is less validation on the
supplied classes, they are just added to the config directly.
For instance I tested with adding Object.class as annotated
class. This doesn't raise an exception and seems to be
silently ignored by Hibernate. Not sure if it might result in
problems during runtime though. Either way, normally this
should be fine and with a little extra documentation on how
these extra classes are handled I think using an integrator is
the least intrusive thus best way to go. Agreed?<br>
<br>
Ok, List as collection type is fine too, indeed easier to use.
Conceptually I like Set, because List seems to imply there is
some kind of ordering involved which in this case there isn't.
But that's just a minor matter of taste.<br>
<br>
By exotic <tt>ProviderLoader(Factory)</tt> I meant the <tt>org.keycloak.provider.ProviderLoader(Factory)</tt>
that you can use to load
<tt>Provider(Factory)</tt>'s from other locations than a file
system based classpath. If that were to be a 'read once'
kindof location (like some stream) there could be a problem.
But with the integrator solution that shouldn't matter
anymore, since it's just the Class object that we need.<br>
<br>
As for Hibernate 4/5, I'll try to make a solution that works
for both Hibernate 4 and 5 in the same way. If that's not
possible, I guess we could have separate code paths for 4 and
5, depending on the runtime version. I hope there is an easy
way of figuring this out, maybe some static Hibernate class
holding a version or so. A quick Google returns some useful
results, so I'm sure we'll get that sorted if needed.<br>
<br>
End of the month is probably too soon indeed, so let's aim for
1.8. Should I (or someone else) create one (or several) JIRA
tickets for this?<br>
<br>
<br>
On 12/11/15 14:32, Stian Thorgersen wrote:<br>
</div>
<blockquote cite="mid:CAJgngAedJ80KUqg3qh5grWBw1MLANwy52ctXmfM0N2-5HO5tnA@mail.gmail.com" type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 12 November 2015 at 13:58,
Erik Mulder <span dir="ltr">
<<a moz-do-not-send="true" href="mailto:erik.mulder@docdatapayments.com" target="_blank">erik.mulder@docdatapayments.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 11/11/15 13:54, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Would you be interested in
contributing this feature? ATM we don't have
anyone available that could work on it. A
contribution would also need to include
functional tests and documentation.</div>
</blockquote>
<br>
</span>Yes, I'd like to contribute this feature. I'm
not sure about the timeline though. I hope to be
able to do it as part of our current project, but I
might have to use my spare time as well. Is there
some kind of deadline to be included in a certain
release version?</div>
</blockquote>
<div><br>
</div>
<div>We do a release every ~6 weeks. It's already a bit
late for 1.7 (it's due end of the month) so would have
to aim for 1.8 in either case (early January).</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>If so I'm happy with going down the route
of using the Hibernate specific classes. The
remaining issue is figuring out how to deal
with classloading.</div>
<div><br>
</div>
<div>Looks like the following should work:</div>
<div><br>
</div>
<div>* Add JpaEntitySPI,
JpaEntityProviderFactory and
JpaEntityProvider</div>
</div>
</blockquote>
<br>
</span>I've done this and it works fine,
successfully providing the extra classes to the
<tt>EntityManagerFactory</tt> build process in <tt>DefaultJpaConnectionProviderFactory</tt>.
<br>
<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>* JpaEntityProvider should have a single
method "Class<?> getEntities"</div>
</div>
</blockquote>
<br>
</span>Yes, only we need some kind of collection
type, so you can provide multiple entity classes per
provider. I guess you were intending this,
considering the plural name 'getEntities'. I suggest
either
<tt>Collection<Class<?>></tt> or <tt>Set<Class<?>></tt>
depending on what is most consistent with the rest
of the system. Do you have a preference?</div>
</blockquote>
<div><br>
</div>
<div>Yup - List would be fine, that's what we tend to
use as it's nicer to use than collection or set.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>* Implement <span>org.hibernate.boot.registry.classloading.spi.</span>ClassLoaderService
- looks like this can just return null for
everything except classForName where it
would return the classes returned by the
JpaEntityProvider implementations</div>
</div>
</blockquote>
<br>
</span>I see no way to interfere in the creation of
the <tt>ClassLoaderService</tt>. The official way
is using the
<tt>BootstrapServiceRegistryBuilder</tt>, but with
the JPA / <tt>EntityManagerFactoryBuilderImpl</tt>
route this happens 'out of reach'. I did find
another way that works just as well: you can provide
a 'custom' classloader to the
<tt>Bootstrap.getEntityManagerFactoryBuilder</tt>.
We can define a classloader that will return the
extra JpaEntityProvider classes if requested. Only
tricky part here is that Hibernate not only calls
<tt>loadClass</tt> on a classloader, but before that
also <tt>getResource</tt> to get a
<tt>URL</tt> with an <tt>InputStream</tt> to the
class bytes. It uses that to scan for annotations
with Jandex. I fixed this by forwarding that request
to the
<tt>ClassLoader</tt> of the <tt>JpaEntityProvider</tt>
provided class (through <tt>
Class.getClassLoader()</tt>). This works fine and
shouldn't be problem for any drop in jars. I can
imagine though that if you use some exotic
<tt>ProviderLoader(Factory)</tt>, you might somehow
get in trouble if the class byte[] is not available
anymore after class loading. But this is a problem
with the way Hibernate works, not with the way we
extend Hibernate in this case. So I think it's fine
to have a warning about this in the documentation,
since it will probably never be a real problem. If
you consider this as a no-go, please let me know.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Sounds OK, but not sure what you mean about
exotic ProviderLoader(Factory) is that a Hibernate
thing?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
Last question I have considers the Hibernate version
of KeyCloak. Currently it's 4.3.10, are there any
plans to upgrade to 5? The code related to
classloading etc is refactored considerably in
Hibernate 5. So it would be a shame to fully get it
working for 4.3.10, only to have to upgrade soon
after that. I didn't look into the details of
Hibernate 5 and I think the solution we came up with
should remain more or less intact, but you never
know, so that's why I ask.</div>
</blockquote>
<div><br>
</div>
<div>We are soon moving to WildFly 10 which includes
Hibernate 5, but we still need to support EAP 6.4
which includes Hibernate 4. At some point next year we
will drop support for EAP 6.4 and move on to EAP 7.</div>
<div><br>
</div>
<div>We either have to support both Hibernate 4 and 5
for a while, or we make it use the old approach on
Hibernate 4 (so now custom entity class support on EAP
6.4) and the new approach on Hibernate 5. That would
probably require some magic reflection code though.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div class="gmail_extra">
<div class="gmail_quote">On 7 November
2015 at 23:39, Erik Mulder <span dir="ltr">
<<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erik.mulder@docdatapayments.com">erik.mulder@docdatapayments.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div dir="ltr"><i>On 06/11/15
14:46, Stian Thorgersen wrote:</i><i><br>
</i><i>> We could use
Hibernate directly to boostrap
as long as it can return an
EntityManager. Do you know if
that's possible?</i><i><br>
</i><br>
I was a little quick to state
that with Hibernate you can add
extra entity class names besides
the one in persistence.xml,
since I spotted a few answers on
StackOverflow that said it could
be done. But they resolve around
classpath scanning or using a
Spring managed Hibernate. Then I
thought: 'if Spring can do it, I
can do it too' so I investigated
the Hibernate source code
'behind'<tt>
Persistence.createEntityManagerFactory(unitName,
properties)</tt>. After some
digging it turns out it's pretty
simple to get extra class names
in the configuration. See code
sample below.<br>
<br>
The only problem is that
Hibernate will only find classes
that are part of the 'main'
KeyCloak application, because of
the way the Wildfly module
system and ClassLoader strategy
work. The debugger showed me
Hibernate has these 3 class
loaders available to look for
classes:<br>
1. ModuleClassLoader for Module
"deployment.keycloak-server.war:main"
from Service Module Loader<br>
2. ModuleClassLoader for Module
"org.hibernate:main" from local
module loader<br>
3.
sun.misc.Launcher$AppClassLoader<br>
<br>
Number 1 has all other KeyCloak
modules in it, so the entity
classes from model-jpa will be
found, but the
wildfly-extensions module is
missing, so entities in classes
in a jar in the providers folder
cannot be found. Now you guys
obviously know a lot more about
these internals, but as
currently configured, it seems
to me there is no way to let
Hibernate 'see' these extra
classes, since only the KeyCloak
services module has a dependency
on wildfly-extensions.<br>
<br>
So I think it boils down to
these decisions:<br>
A. Do you accept a non-pure-JPA
way of building the
EntityManagerFactory that has
some ties to the Hibernate
internals?<br>
B. If A is no, than we're done.
If yes, then you must find some
way to get the extra configured
classes 'into' Hibernate. You
could get the wildfly-extensions
module into scope of the
Hibernate classloading. There
are serveral ways to configure
Hibernate classloading or you
could flip some switches /
dependencies in the module
configuration. Another
alternative is to create a
separate 'dropfolder' besides
themes and providers for JPA
extensions, like 'models' or so
and have that one be on the
Hibernate classpath. But I don't
know the exact design principles
behind KeyCloak or the Wildfly
module system. So maybe you have
a better solution or maybe you
conclude that this is 'not done'
in terms of the architecture.<br>
<br>
Either way, I'd really
appreciate some feedback on this
and some thoughts on whether
this could be a possible
addition to KeyCloak in your
eyes.<br>
<br>
Thanks, Erik<br>
<br>
<br>
Current JPA way. No way to
'interfere':<br>
<tt>emf =
Persistence.createEntityManagerFactory(unitName,
properties);</tt><tt><br>
</tt><br>
Alternative Hibernate only way
with adding extra entity class
names:<br>
<tt>// Let Hibernate find and
parse all 'persistence.xml'
files found on the classpath.<br>
List<ParsedPersistenceXmlDescriptor>
persistenceUnits =
PersistenceXmlParser.locatePersistenceUnits(properties);</tt><tt><br>
</tt><tt>// Assume there is only
one persistence unit found and
that is the one we need. This
can be made more robust by
checking on the persistence
unit name.<br>
ParsedPersistenceXmlDescriptor
persistenceUnitDescriptor =
persistenceUnits.get(0);</tt><tt><br>
</tt><tt>// Add extra class
names. These could come from a
'JPA class name provider' SPI
or something alike.<br>
persistenceUnitDescriptor.addClasses("org.keycloak.models.jpa.entities.UserMerchantEntity",</tt><tt>
"org.keycloak.models.jpa.entities.MerchantEntity");</tt><tt><br>
</tt><tt>// Let Hibernate create
an EntityManagerFactory out of
the (enriched) persistence
unit configuration.<br>
emf =
Bootstrap.getEntityManagerFactoryBuilder(persistenceUnitDescriptor,
properties).build();</tt><tt><br>
</tt><br>
<br>
<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 6
November 2015 at 14:29, Erik
Mulder <span dir="ltr">
<<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erik.mulder@docdatapayments.com"><a class="moz-txt-link-abbreviated" href="mailto:erik.mulder@docdatapayments.com">erik.mulder@docdatapayments.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div>Thanks for
pointing me
explicitly to the
SPI documentation.
Of course that is
exactly what I was
looking for in my
original question. I
don't know how I
overlooked this
earlier! Probably I
was not picking it
up, because of
almost a decade of
developing on Spring
projects, where this
type of thing works
differently. :-)<br>
<br>
I tried a quick test
with a jar with one
extra ProtocolMapper
configured, put it
in the providers
folder and it worked
like a charm!<br>
<br>
As for the JPA:
We'll probably go
with your suggestion
of the separate
EntityManagerFactory.
Indeed there seems
to be no way to
'programmatically
extend' the list of
entity classes in
JPA besides editing
or overwriting the
persistence.xml. As
you probably know it
can be done in
Hibernate, but I
guess KeyCloak wants
to stick to a
generic JPA
solution. That said,
we might consider
the Hibernate
specific solution
for our case, since
being able to switch
the JPA provider is
not a requirement
for us. And keeping
the same
connection/transaction
is a lot easier in
reasoning and
debugging.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>We could use Hibernate
directly to boostrap as
long as it can return an
EntityManager. Do you know
if that's possible?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div>
<div>
<div><br>
<br>
<br>
On 05/11/15
10:52, Stian
Thorgersen
wrote:<br>
</div>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">The
way to extend
Keycloak is by
implementing
your own
custom
providers of
the many SPIs
we provide.
Some SPIs are
more stable
(so marked as
public) and
others are not
(so marked as
private). If
there are
things that
you want to
customize that
can't be done
with an
existing SPI
then let us
know and we
may consider
adding
additional
SPIs.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
4 November
2015 at 17:16,
Erik Mulder <span dir="ltr">
<<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erik.mulder@docdatapayments.com"><a class="moz-txt-link-abbreviated" href="mailto:erik.mulder@docdatapayments.com">erik.mulder@docdatapayments.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Thanks for
your response!<br>
<br>
Indeed we
already did a
proof of
concept where
we added a
custom mapper<br>
the way you
described
(didn't know
it was
'protected'
territory :).
The<br>
question is:
do we have to
override the
file<br>
'org.keycloak.protocol.ProtocolMapper'
for this and
add the new
mapper<br>
in the
original
project or is
there another
way where we
don't need to<br>
touch the
original
sources and
keep all our
changes in a
separate<br>
project? And
how can we do
it such that
it stays easy
to upgrade to<br>
newer KeyCloak
releases?<br>
</blockquote>
<div><br>
</div>
<div>Each jar
has it's own
org.keycloak.protocol.ProtocolMapper.
Take a look at
the docs (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html"><a class="moz-txt-link-freetext" href="http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html">http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html</a></a>)
and examples
for other
provider (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory"><a class="moz-txt-link-freetext" href="https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory">https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory</a></a>)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As for JPA: it
would be
easier to
integrate with
the existing
JPA<br>
project. Again
we are
wondering
whether to
start
modifying
original<br>
sources (like
persistence.xml)
or try to
'externalize'
our changes<br>
somehow and
integrate them
using existing
'hooks' in the
system or
maybe<br>
merge projects
during build.<br>
<br>
Maybe there is
no good answer
to this and
we'll always
be having some<br>
manual merge
pains when
upgrading to
new KeyCloak
versions. We
just<br>
wanted to
check if there
are preferred
ways to add
functionality
with<br>
the least
amount of
impact on the
original
sources.<br>
</blockquote>
<div><br>
</div>
<div>I
initially
wanted the
ability to add
custom
entities to
the
JpaConnectProvider,
but couldn't
find a way to
define
entities
programatically
with JPA. To
add your own
persistence.xml
you would have
to define your
own
implementation
of
JpaConnectionProvider
and change
what is loaded
by default
(connectionsJpa/provider
attribute in
keycloak-server.json).</div>
<div><br>
</div>
<div>Alternative,
which is
cleaner, but
you end up
with separate
connection/transaction,
is to create
your own
EntityManagerFactory.
If it's only
used by one
provider (for
example a
custom
UserFederationProvider)
there's no
need to add a
connect
provider
(that's just a
way to share
one
EntityManagerFactory
between
multiple
providers) and
you can just
create it in
the
MyUserFederationProviderFactory.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><br>
<br>
On 04/11/15
15:30, Bill
Burke wrote:<br>
> Custom
mappers should
be possible.
I didn't
document it as
I wasn't<br>
> sure if
we wanted to
make the SPI
public.
Custom mappers
should just<br>
> follow
the Provider
SPI and they
will be picked
up. If you
see the<br>
>
META-INF/services/...
file in the
resources
directory of
the "services"<br>
> or
"broker"
modules you'll
see how to set
this up.<br>
><br>
> As for
extending the
JPA datamodel,
what you could
do is write a
new JPA<br>
>
Connections
Provider and
plug that in.
See
connections/jpa.
I'm not<br>
> sure how
you would
handle the
liquibase db
migration.<br>
><br>
> On
11/4/2015 6:03
AM, Erik
Mulder wrote:<br>
>> Hi
everybody,<br>
>><br>
>> Quick
intro: I’m
part of a
development
team in The
Netherlands
that is<br>
>>
building a
company-wide
SSO solution.
We’ve chosen
KeyCloak to
realize<br>
>> this
and will use
OpenID Connect
to secure our
REST services.
It’s a<br>
>> great
product and
seems to be
the only one
having both
support for
all<br>
>> kinds
of security
standards and
a model and
GUI for users
and roles.<br>
>>
Thanks for
creating it! J<br>
>><br>
>> (if
this should be
asked instead
on the users
mailing list,
please<br>
>>
correct me and
I’ll post it
there)<br>
>><br>
>> So
far, so good,
but we have
some extra
requirements
that do not
fit<br>
>> into
the base
KeyCloak data
model. See
below for
details if
you’re<br>
>>
interested. My
question is:
what is the
preferred way
/ best
practice to<br>
>>
extend the
functionality
of KeyCloak
while keeping
the impact on
the<br>
>>
original
sources to a
minimum? Of
course we
could just
fork the most<br>
>>
recent version
and start
hacking away,
but we’d like
to be able to<br>
>>
upgrade to
newer versions
of KeyCloak
without too
much hassle.<br>
>>
Possibilities
that we’ve
come up with
so far:<br>
>><br>
>>
1.Create
completely
separate
modules that
will extend
the
functionality<br>
>> the
way we need.<br>
>><br>
>>
2.Fork on
Github, apply
custom
changes, and
try to merge
in updates
from<br>
>> the
master /
release
branches /
tags<br>
>><br>
>>
3.Apply custom
changes on
KeyCloak
artifacts
using a Maven
plugin, such<br>
>> as
Truezip<br>
>> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html"><a class="moz-txt-link-freetext" href="http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html">http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html</a></a>)
-<br>
>>
manipulate zip
files by
adding/removing/replacing
or Shade<br>
>> (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://maven.apache.org/plugins/maven-shade-plugin/"><a class="moz-txt-link-freetext" href="http://maven.apache.org/plugins/maven-shade-plugin/">http://maven.apache.org/plugins/maven-shade-plugin/</a></a>)
- combine
multiple<br>
>> jars
to 1
'uber-jar'
containing the
contents of
both and when<br>
>>
overlapping
decide on
conflicts
through
configuration.<br>
>><br>
>> Of
course number
1 is
preferred, but
I do not see
how to add
custom<br>
>>
mappers or JPA
entities
without making
changes in the
original
module<br>
>>
files. The
other options
seem like
valid
alternatives,
but maybe
there<br>
>> is
better /
standard way
to do this. So
any help /
insight /
shared<br>
>>
experience on
this is much
appreciated,
thanks!<br>
>><br>
>> Kind
regards,<br>
>><br>
>> Erik
Mulder<br>
>><br>
>>
Senior
Software
Engineer<br>
>><br>
>>
Docdata
Payments – NL<br>
>><br>
>> P.S.
Details on why
we want to
extend the
KeyCloak data
model: (any<br>
>>
feedback on
the contents
of this P.S.
is also
welcome!)<br>
>><br>
>> Our
clients are
merchants that
have several
webshops. We
manage their<br>
>>
online
payments
(shopping cart
checkout). We
want to be
able to let a<br>
>>
merchant
manage their
own users and
let a user
have different
roles for<br>
>>
different
webshops
within the
same merchant.
The overall
possible roles<br>
>> are
fixed though,
no specific
roles per
merchant. We
could create a<br>
>>
separate realm
for every
merchant, but
then we need
to duplicate
all<br>
>> roles
every time.
Furthermore,
in KeyCloak
there is no
concept of a
role<br>
>>
within a
certain
context. This
is very
understandable,
since every<br>
>>
situation has
it’s own
requirements.
We did a proof
of concept by
adding<br>
>>
tables and
entities for
Merchant,
UserMerchant,
UserMerchantRole
etc.<br>
>> and
adding a
custom mapper
that can put
this
information on
the Access<br>
>>
token. Worked
like a charm!
But it does
need some
changes in the<br>
>>
KeyCloak
modules and
sources to
work, hence
the question
above.<br>
>><br>
>><br>
>><br>
>>
_______________________________________________<br>
>>
keycloak-dev
mailing list<br>
>> <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">
</a><a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></a><br>
>> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">
</a><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></a><br>
>><br>
<br>
<br>
_______________________________________________<br>
keycloak-dev
mailing list<br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org"><a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></a><br>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"><a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>