<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/21/2015 3:39 PM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcJnHvmxueQ-vdD6g6H2Z45bOcxApmJXLWyqadtQ06oFw@mail.gmail.com"
type="cite">
<div dir="ltr">Nopes, that's not the job of EE containers, that's
what Hibernate does. Hibernate does that perfectly well in
standalone Java apps as well. As I said we manage our own
EntityManagerFactory.</div>
</blockquote>
You're right. I've been working strictly with the app server too
many years.<br>
<br>
It's still a JEE container. JPA is part of the JEE spec. In this
case you are just getting it directly from Hibernate.
<blockquote
cite="mid:CAJgngAcJnHvmxueQ-vdD6g6H2Z45bOcxApmJXLWyqadtQ06oFw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Have you looked at KeycloakServer inside the testsuite? You
can spin up a perfectly functional KC server with nothing but
an embedded Undertow server.</div>
</div>
</blockquote>
<br>
<br>
<blockquote
cite="mid:CAJgngAcJnHvmxueQ-vdD6g6H2Z45bOcxApmJXLWyqadtQ06oFw@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at 21:08, Stan
Silvert <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 10/21/2015 2:43 PM, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I have no idea what you mean about
containers. As I said we manage our own
EntityManagerFactory, etc.. inside Keycloak. It
doesn't rely on JEE for that part.</div>
</blockquote>
</span> Somebody has to process the annotations in
org.keycloak.models.jpa.entities, do injection,
interception, etc. That's the job of the EE containers.
<div>
<div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>We just need the classes which we can get
with jboss-modules.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at
20:16, Stan Silvert <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ssilvert@redhat.com"
target="_blank">ssilvert@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div>On 10/21/2015 2:08 PM, Stan Silvert
wrote:<br>
</div>
<blockquote type="cite">
<div>On 10/21/2015 1:57 PM, Stian
Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">We manage our own
EntityManagerFactory and
EntityManager as well as our own
transactions. So that's not true.</div>
</blockquote>
If all you need is the datasource info
that lives in standalone.xml then yes,
we can get that.<br>
</blockquote>
</span> But I'm a little confused as to how
this would work. Are you saying that you
wouldn't use any of the classes in
org.keycloak.models.jpa.entities? Those
need containers.<br>
<blockquote type="cite"><span> <br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21
October 2015 at 19:53, Stan
Silvert <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ssilvert@redhat.com"
target="_blank">ssilvert@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div text="#000000"
bgcolor="#FFFFFF"><span>
<div>On 10/21/2015 1:23 PM,
Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Guys - all
we need is the
datasource. I want to
create a "db tool" for
Keycloak, this is not
for the Admin CLI
<div><br>
</div>
<div>We don't need CDI,
EJB, etc.. All we need
is the datasource, or
at least the
connection information
for the datasource +
we also need JBoss
modules so we can get
the required classes.</div>
<div><br>
</div>
<div>If offline mode can
do this then that'd be
good, but I seem to
remember datasources
weren't available?</div>
</div>
</blockquote>
</span> If you want to use our
existing JPA infrastructure
then you need a JPA
container. That's where this
other stuff all gets pulled
in.<br>
<br>
Hey, let's just use JDBC! :-)<span><br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On
21 October 2015 at
18:22, Marko Strukelj
<span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div dir="ltr">
<div
class="gmail_extra">
<div
class="gmail_quote"><span>On
Wed, Oct 21,
2015 at 5:57
PM, Stan
Silvert <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.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"><span>On
10/21/2015
11:14 AM,
Marko Strukelj
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">I
haven't taken
a very close
look at Swarm
yet, but I
assumed you
start Wildfly
embedded in
the same JVM
as your Main
class. If that
is the case,
then there
should be no
problem
communicating
with any kind
of deployed
component via
heap directly
- just lookup
some singleton
...<br>
</blockquote>
</span>
Classloading
constraints
are what you
usually run up
against. You
can't use your
own version of
a class that
was loaded
from a
different
classloader.
I don't think
Swarm helps
you get around
that, but just
assumes you
will access
the WAR in the
usual way
through an
HTTP port.
But I could be
wrong as I
haven't worked
with Swarm
either.<br>
<br>
Here is an
explanation of
the problem
based on an
old version of
JBoss:<br>
<a
moz-do-not-send="true"
href="https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html"
rel="noreferrer" target="_blank">https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html</a><br>
<br>
With
jboss-modules,
it's easier to
get around
these
problems, but
you still run
into the
isolation
built into the
container
itself,
especially in
the case of a
WAR.</blockquote>
<div> </div>
</span>
<div>CLI
running in the
same JVM as
Wildfly would
get
bootstrapped
through
jboss-modules,
and would
package it's
classes as a
jboss module.
It can then
deploy
additional
'in-container'
logic that
needs actual
access to
datasources
via many
different
mechanisms. It
can be a .jar
containing a
SLSB, a .war,
a .sar, a POJO
(via pojo
subsystem), it
can be a
custom
subsystem that
gets installed
... In every
of these cases
it can then
have access to
resource
objects bound
to java:jboss
JNDI space ...
And in every
of these cases
it uses shared
types loaded
via
dependencies
on
jboss-modules.</div>
<span>
<div><br>
</div>
<div><br>
</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"><span>
<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>
If that is not
the case, then
we would need
some kind of
interprocess
communication
going. With
shell the
roles of who
connects where
could also be
reversed, and
a started up
Wildfly
instance could
have a service
connecting out
to local port
bound by our
CLI rather
than the other
way around.<br>
</blockquote>
</span> I
don't think
the direction
of the
connection
matters so
much as the
fact that you
need a
serialized
format to
issue commands
to a foreign
container.<br>
<br>
Or, as I
mentioned, you
need the CLI
to actually
live inside
the container.</blockquote>
<div><br>
</div>
</span>
<div>CLI needs
to be able to
execute its
logic inside
the container
in order to
harness the
datasources,
but the UI
part that
takes care of
getting the
inputs and
displaying the
outputs - e.g.
CraSH, does
not have to be
inside the
container. </div>
<div><br>
</div>
<div>I don't
know what you
mean by
'serialized
format to
issue commands
to a foreign
container',
but if it
means taking
care of UI
interaction,
CraSH looks
pretty decent
CLI, easy to
extend with
custom
commands. </div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
</span><span>
<pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</span></blockquote>
<br>
</div>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org"
target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>