<div dir="ltr">If we have to extract connection information from datasources in either case we don't really get much benefit of using offline jboss cli though?</div><div class="gmail_extra"><br><div class="gmail_quote">On 22 October 2015 at 15:03, Stan Silvert <span dir="ltr"><<a 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/22/2015 2:05 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">It can be JBoss CLI, that's no problem as long as
it works, but if datasources are unavailable in offline mode
then it's not going to help.
<div><br>
</div>
<div>Parsing the standalone.xml ourselves and extracting the
datasource piece seems very brittle, that's why I was hoping
there was some magic way we could get the datasource.
Everything else should be easy enough.</div>
</div>
</blockquote></span>
So if it's WildFly CLI then there is obviously no problem reading
standalone.xml in a standard way.<br>
<br>
The custom commands we create for WildFly CLI can do anything we
want. So by pulling in Hibernate and using its JPA implementation
directly, we could do it.<div><div class="h5"><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at 22:48, Marko
Strukelj <span dir="ltr"><<a 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">
<p dir="ltr">@Stian, so your original question is then:</p>
<p dir="ltr">Can we have a non jboss-cli CLI that will use
hibernate directly, and configure it with datasource info
from keycloak-server.json and standalone.xml?</p>
<p dir="ltr">That would involve identifying Datasource jndi
lookup name, finding datasource definition for it,
identifying the driver used, and jboss-module containing
the driver ...</p>
<p dir="ltr">As long as Hibernate is capable of using
connection url to autodetect dialect (AFAIK it can do
that) it seems to me the answer is yes, that can be done
...<br>
</p>
<div>
<div>
<div class="gmail_quote">On Oct 21, 2015 21:39, "Stian
Thorgersen" <<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><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>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at
21:08, Stan Silvert <span dir="ltr"><<a 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: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><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 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 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 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 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 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 href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a 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 href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a 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>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a 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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>