7:59 a.m.
It would be nice to have an "offline" cli that can be used to configure
Keycloak. If we roll our own CLI for that and it uses jboss-modules do you
reckon we can get access to the datasources somehow? This is for things
like setting the admin password, import/export from cli, etc..
9:05 a.m.
On 10/21/2015 8:59 AM, Stian Thorgersen wrote:
It would be nice to have an "offline" cli that can be used
to
configure Keycloak. If we roll our own CLI for that and it uses
jboss-modules do you reckon we can get access to the datasources
somehow? This is for things like setting the admin password,
import/export from cli, etc..
That's what WildFly's "offline CLI"
feature was built for:
http://wildfly.org/news/2015/03/13/Offline-CLI/
Of course, anything is possible, but doing this ourselves involves more
than just using jboss-modules. You have to start up the environment
that lets you use whatever technology you are choosing to connect to the
data. If we want to reuse our current code for that then it means
starting container environments such as CDI, JPA, and other
dependencies, then wiring them together and starting our own
stripped-down version of the overall server.
Probably, we would end up doing exactly what WildFly CLI does and just
embed the server into our CLI process.
Then we are back to the problem of actually getting access to the
datasource. That's really a problem whether we roll our own or not. In
embedded mode, you can't use the REST API because no inbound connections
are allowed.
Any CLI will run outside the container. So you are always faced with
accessing the container context from outside the container, which is
next to impossible. This is the land of the java.lang.LinkageError. So
you need some way to call into the container using a serialized data
format. If there is a way to do in-process, port-less REST calls then
that's probably the easiest solution. But I'm really grasping at straws
here. I'd have to do some research to find out what our options are.
9:43 a.m.
Since Wildfly's config is persisted into a single standalone.xml file, the
offline mode can be achieved simply by editing that file. It would bypass
all MDR model checks as defined by services, so it's up to our console to
not generate a corrupt config, which may mean it would have to contain
subsystem version specific information. But that would only be necessary
for subsystems that we would touch.
We might try with Wildfly Swarm to boot a programatically configured bare
minimum to get datasources / mongo / ldap connectors and use them directly.
But any such approach would not build on jboss-cli, and would have to start
with some other console as a base, maybe something like CraSH (
http://www.crashub.org/).
On Wed, Oct 21, 2015 at 4:05 PM, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/21/2015 8:59 AM, Stian Thorgersen wrote:
> It would be nice to have an "offline" cli that can be used to
> configure Keycloak. If we roll our own CLI for that and it uses
> jboss-modules do you reckon we can get access to the datasources
> somehow? This is for things like setting the admin password,
> import/export from cli, etc..
That's what WildFly's "offline CLI" feature was built for:
http://wildfly.org/news/2015/03/13/Offline-CLI/
Of course, anything is possible, but doing this ourselves involves more
than just using jboss-modules. You have to start up the environment
that lets you use whatever technology you are choosing to connect to the
data. If we want to reuse our current code for that then it means
starting container environments such as CDI, JPA, and other
dependencies, then wiring them together and starting our own
stripped-down version of the overall server.
Probably, we would end up doing exactly what WildFly CLI does and just
embed the server into our CLI process.
Then we are back to the problem of actually getting access to the
datasource. That's really a problem whether we roll our own or not. In
embedded mode, you can't use the REST API because no inbound connections
are allowed.
Any CLI will run outside the container. So you are always faced with
accessing the container context from outside the container, which is
next to impossible. This is the land of the java.lang.LinkageError. So
you need some way to call into the container using a serialized data
format. If there is a way to do in-process, port-less REST calls then
that's probably the easiest solution. But I'm really grasping at straws
here. I'd have to do some research to find out what our options are.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:02 a.m.
On 10/21/2015 10:43 AM, Marko Strukelj wrote:
Since Wildfly's config is persisted into a single standalone.xml
file,
the offline mode can be achieved simply by editing that file. It would
bypass all MDR model checks as defined by services, so it's up to our
console to not generate a corrupt config, which may mean it would have
to contain subsystem version specific information. But that would only
be necessary for subsystems that we would touch.
We might try with Wildfly Swarm to boot a programatically configured
bare minimum to get datasources / mongo / ldap connectors and use them
directly.
I don't see how that helps you use datasources directly. From what I
understand of Swarm, it's just a different way to start the same
containers. But you still have the problem of accessing from outside
the container.
Or, you need something akin to Bill's SSH solution where the WAR
actually kicks off the CLI. (At one point Bill was proposing that our
WAR expose a port that someone could SSH into and issue commands. But
that was eventually rejected.)
But any such approach would not build on jboss-cli, and would have to
start with some other console as a base, maybe something like CraSH
(http://www.crashub.org/).
On Wed, Oct 21, 2015 at 4:05 PM, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 8:59 AM, Stian Thorgersen wrote:
> It would be nice to have an "offline" cli that can be used to
> configure Keycloak. If we roll our own CLI for that and it uses
> jboss-modules do you reckon we can get access to the datasources
> somehow? This is for things like setting the admin password,
> import/export from cli, etc..
That's what WildFly's "offline CLI" feature was built for:
http://wildfly.org/news/2015/03/13/Offline-CLI/
Of course, anything is possible, but doing this ourselves involves
more
than just using jboss-modules. You have to start up the environment
that lets you use whatever technology you are choosing to connect
to the
data. If we want to reuse our current code for that then it means
starting container environments such as CDI, JPA, and other
dependencies, then wiring them together and starting our own
stripped-down version of the overall server.
Probably, we would end up doing exactly what WildFly CLI does and just
embed the server into our CLI process.
Then we are back to the problem of actually getting access to the
datasource. That's really a problem whether we roll our own or
not. In
embedded mode, you can't use the REST API because no inbound
connections
are allowed.
Any CLI will run outside the container. So you are always faced with
accessing the container context from outside the container, which is
next to impossible. This is the land of the
java.lang.LinkageError. So
you need some way to call into the container using a serialized data
format. If there is a way to do in-process, port-less REST calls then
that's probably the easiest solution. But I'm really grasping at
straws
here. I'd have to do some research to find out what our options are.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:14 a.m.
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 ...
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.
I'm throwing out ideas here, not really knowing what are the hard
constraints that we don't want to violate ...
10:57 a.m.
On 10/21/2015 11:14 AM, Marko Strukelj wrote:
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 ...
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.
Here is an explanation of the problem based on an old version of JBoss:
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
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.
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.
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.
Or, as I mentioned, you need the CLI to actually live inside the container.
I'm throwing out ideas here, not really knowing what are the hard
constraints that we don't want to violate ...
11:22 a.m.
On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/21/2015 11:14 AM, Marko Strukelj wrote:
> 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 ...
>
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.
Here is an explanation of the problem based on an old version of JBoss:
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
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.
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.
> 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.
>
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.
Or, as I mentioned, you need the CLI to actually live inside the container.
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.
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.
12:23 p.m.
Guys - all we need is the datasource. I want to create a "db tool" for
Keycloak, this is not for the Admin CLI
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.
If offline mode can do this then that'd be good, but I seem to remember
datasources weren't available?
On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com> wrote:
On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
<ssilvert(a)redhat.com> wrote:
> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>
>> 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 ...
>>
> 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.
>
> Here is an explanation of the problem based on an old version of JBoss:
>
>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>
> 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.
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.
>> 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.
>>
> 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.
>
> Or, as I mentioned, you need the CLI to actually live inside the
> container.
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.
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.
12:53 p.m.
On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
Guys - all we need is the datasource. I want to create a "db
tool" for
Keycloak, this is not for the Admin CLI
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.
If offline mode can do this then that'd be good, but I seem to
remember datasources weren't available?
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.
Hey, let's just use JDBC! :-)
On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com
<mailto:mstrukel@redhat.com>> wrote:
On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 11:14 AM, Marko Strukelj wrote:
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 ...
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.
Here is an explanation of the problem based on an old version
of JBoss:
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
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.
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.
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.
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.
Or, as I mentioned, you need the CLI to actually live inside
the container.
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.
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.
12:57 p.m.
We manage our own EntityManagerFactory and EntityManager as well as our own
transactions. So that's not true.
On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
Guys - all we need is the datasource. I want to create a "db tool" for
Keycloak, this is not for the Admin CLI
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.
If offline mode can do this then that'd be good, but I seem to remember
datasources weren't available?
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.
Hey, let's just use JDBC! :-)
On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com> wrote:
> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert(a)redhat.com>
> wrote:
>
>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>
>>> 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 ...
>>>
>> 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.
>>
>> Here is an explanation of the problem based on an old version of JBoss:
>>
>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>
>> 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.
>
>
> 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.
>
>
>
>>> 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.
>>>
>> 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.
>>
>> Or, as I mentioned, you need the CLI to actually live inside the
>> container.
>
>
> 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.
>
> 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.
>
>
1:08 p.m.
On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
We manage our own EntityManagerFactory and EntityManager as well as
our own transactions. So that's not true.
If all you need is the datasource
info that lives in standalone.xml then
yes, we can get that.
On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
> Guys - all we need is the datasource. I want to create a "db
> tool" for Keycloak, this is not for the Admin CLI
>
> 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.
>
> If offline mode can do this then that'd be good, but I seem to
> remember datasources weren't available?
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.
Hey, let's just use JDBC! :-)
>
> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com
> <mailto:mstrukel@redhat.com>> wrote:
>
> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>
> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>
> 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 ...
>
> 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.
>
> Here is an explanation of the problem based on an old
> version of JBoss:
>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>
> 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.
>
> 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.
>
>
>
> 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.
>
> 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.
>
> Or, as I mentioned, you need the CLI to actually live
> inside the container.
>
>
> 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.
>
> 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.
>
>
1:16 p.m.
On 10/21/2015 2:08 PM, Stan Silvert wrote:
On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
> We manage our own EntityManagerFactory and EntityManager as well as
> our own transactions. So that's not true.
If all you need is the datasource info that lives in standalone.xml
then yes, we can get that.
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.
>
> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com
> <mailto:ssilvert@redhat.com>> wrote:
>
> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>> Guys - all we need is the datasource. I want to create a "db
>> tool" for Keycloak, this is not for the Admin CLI
>>
>> 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.
>>
>> If offline mode can do this then that'd be good, but I seem to
>> remember datasources weren't available?
> 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.
>
> Hey, let's just use JDBC! :-)
>
>>
>> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com
>> <mailto:mstrukel@redhat.com>> wrote:
>>
>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>>
>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>
>> 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 ...
>>
>> 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.
>>
>> Here is an explanation of the problem based on an old
>> version of JBoss:
>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> Or, as I mentioned, you need the CLI to actually live
>> inside the container.
>>
>>
>> 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.
>>
>> 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.
>>
>>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:43 p.m.
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.
We just need the classes which we can get with jboss-modules.
On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/21/2015 2:08 PM, Stan Silvert wrote:
On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
We manage our own EntityManagerFactory and EntityManager as well as our
own transactions. So that's not true.
If all you need is the datasource info that lives in standalone.xml then
yes, we can get that.
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.
On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>
> Guys - all we need is the datasource. I want to create a "db tool" for
> Keycloak, this is not for the Admin CLI
>
> 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.
>
> If offline mode can do this then that'd be good, but I seem to remember
> datasources weren't available?
>
> 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.
>
> Hey, let's just use JDBC! :-)
>
>
> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com> wrote:
>
>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert(a)redhat.com>
>> wrote:
>>
>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>
>>>> 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 ...
>>>>
>>> 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.
>>>
>>> Here is an explanation of the problem based on an old version of JBoss:
>>>
>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>
>>> 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.
>>
>>
>> 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.
>>
>>
>>
>>>> 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.
>>>>
>>> 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.
>>>
>>> Or, as I mentioned, you need the CLI to actually live inside the
>>> container.
>>
>>
>> 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.
>>
>> 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.
>>
>>
>
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:08 p.m.
On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
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.
Somebody has to process the annotations in
org.keycloak.models.jpa.entities, do injection, interception, etc.
That's the job of the EE containers.
We just need the classes which we can get with jboss-modules.
On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 2:08 PM, Stan Silvert wrote:
> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>> We manage our own EntityManagerFactory and EntityManager as well
>> as our own transactions. So that's not true.
> If all you need is the datasource info that lives in
> standalone.xml then yes, we can get that.
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.
>
>>
>> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com
>> <mailto:ssilvert@redhat.com>> wrote:
>>
>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>> Guys - all we need is the datasource. I want to create a
>>> "db tool" for Keycloak, this is not for the Admin CLI
>>>
>>> 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.
>>>
>>> If offline mode can do this then that'd be good, but I seem
>>> to remember datasources weren't available?
>> 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.
>>
>> Hey, let's just use JDBC! :-)
>>
>>>
>>> On 21 October 2015 at 18:22, Marko Strukelj
>>> <mstrukel(a)redhat.com <mailto:mstrukel@redhat.com>>
wrote:
>>>
>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
>>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
wrote:
>>>
>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>
>>> 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 ...
>>>
>>> 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.
>>>
>>> Here is an explanation of the problem based on an
>>> old version of JBoss:
>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Or, as I mentioned, you need the CLI to actually
>>> live inside the container.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:39 p.m.
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.
Have you looked at KeycloakServer inside the testsuite? You can spin up a
perfectly functional KC server with nothing but an embedded Undertow server.
On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
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.
Somebody has to process the annotations in
org.keycloak.models.jpa.entities, do injection, interception, etc. That's
the job of the EE containers.
We just need the classes which we can get with jboss-modules.
On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>
> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>
> We manage our own EntityManagerFactory and EntityManager as well as our
> own transactions. So that's not true.
>
> If all you need is the datasource info that lives in standalone.xml then
> yes, we can get that.
>
> 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.
>
>
>
> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>
>> Guys - all we need is the datasource. I want to create a "db tool" for
>> Keycloak, this is not for the Admin CLI
>>
>> 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.
>>
>> If offline mode can do this then that'd be good, but I seem to remember
>> datasources weren't available?
>>
>> 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.
>>
>> Hey, let's just use JDBC! :-)
>>
>>
>> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com> wrote:
>>
>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert <ssilvert(a)redhat.com>
>>> wrote:
>>>
>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>
>>>>> 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
...
>>>>>
>>>> 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.
>>>>
>>>> Here is an explanation of the problem based on an old version of JBoss:
>>>>
>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>
>>>> 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.
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>>> 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.
>>>>>
>>>> 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.
>>>>
>>>> Or, as I mentioned, you need the CLI to actually live inside the
>>>> container.
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3:48 p.m.
@Stian, so your original question is then:
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?
That would involve identifying Datasource jndi lookup name, finding
datasource definition for it, identifying the driver used, and jboss-module
containing the driver ...
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 ...
On Oct 21, 2015 21:39, "Stian Thorgersen" <sthorger(a)redhat.com> wrote:
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.
Have you looked at KeycloakServer inside the testsuite? You can spin up a
perfectly functional KC server with nothing but an embedded Undertow server.
On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>
> 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.
>
> Somebody has to process the annotations in
> org.keycloak.models.jpa.entities, do injection, interception, etc. That's
> the job of the EE containers.
>
>
>
> We just need the classes which we can get with jboss-modules.
>
> On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
>> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>>
>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>
>> We manage our own EntityManagerFactory and EntityManager as well as our
>> own transactions. So that's not true.
>>
>> If all you need is the datasource info that lives in standalone.xml then
>> yes, we can get that.
>>
>> 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.
>>
>>
>>
>> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>
>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>
>>> Guys - all we need is the datasource. I want to create a "db tool"
for
>>> Keycloak, this is not for the Admin CLI
>>>
>>> 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.
>>>
>>> If offline mode can do this then that'd be good, but I seem to remember
>>> datasources weren't available?
>>>
>>> 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.
>>>
>>> Hey, let's just use JDBC! :-)
>>>
>>>
>>> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com>
>>> wrote:
>>>
>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
<ssilvert(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>>
>>>>>> 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
...
>>>>>>
>>>>> 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.
>>>>>
>>>>> Here is an explanation of the problem based on an old version of
>>>>> JBoss:
>>>>>
>>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>>> 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.
>>>>>>
>>>>> 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.
>>>>>
>>>>> Or, as I mentioned, you need the CLI to actually live inside the
>>>>> container.
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:05 a.m.
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.
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.
On 21 October 2015 at 22:48, Marko Strukelj <mstrukel(a)redhat.com> wrote:
@Stian, so your original question is then:
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?
That would involve identifying Datasource jndi lookup name, finding
datasource definition for it, identifying the driver used, and jboss-module
containing the driver ...
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 ...
On Oct 21, 2015 21:39, "Stian Thorgersen" <sthorger(a)redhat.com> wrote:
> 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.
>
> Have you looked at KeycloakServer inside the testsuite? You can spin up a
> perfectly functional KC server with nothing but an embedded Undertow server.
>
> On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>>
>> 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.
>>
>> Somebody has to process the annotations in
>> org.keycloak.models.jpa.entities, do injection, interception, etc. That's
>> the job of the EE containers.
>>
>>
>>
>> We just need the classes which we can get with jboss-modules.
>>
>> On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>
>>> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>>>
>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>>
>>> We manage our own EntityManagerFactory and EntityManager as well as our
>>> own transactions. So that's not true.
>>>
>>> If all you need is the datasource info that lives in standalone.xml
>>> then yes, we can get that.
>>>
>>> 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.
>>>
>>>
>>>
>>> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>>
>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>>
>>>> Guys - all we need is the datasource. I want to create a "db
tool" for
>>>> Keycloak, this is not for the Admin CLI
>>>>
>>>> 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.
>>>>
>>>> If offline mode can do this then that'd be good, but I seem to
>>>> remember datasources weren't available?
>>>>
>>>> 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.
>>>>
>>>> Hey, let's just use JDBC! :-)
>>>>
>>>>
>>>> On 21 October 2015 at 18:22, Marko Strukelj <mstrukel(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
<ssilvert(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>>>
>>>>>>> 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 ...
>>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Here is an explanation of the problem based on an old version of
>>>>>> JBoss:
>>>>>>
>>>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Or, as I mentioned, you need the CLI to actually live inside the
>>>>>> container.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
8:03 a.m.
On 10/22/2015 2:05 AM, Stian Thorgersen wrote:
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.
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.
So if
it's WildFly CLI then there is obviously no problem reading
standalone.xml in a standard way.
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.
On 21 October 2015 at 22:48, Marko Strukelj <mstrukel(a)redhat.com
<mailto:mstrukel@redhat.com>> wrote:
@Stian, so your original question is then:
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?
That would involve identifying Datasource jndi lookup name,
finding datasource definition for it, identifying the driver used,
and jboss-module containing the driver ...
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 ...
On Oct 21, 2015 21:39, "Stian Thorgersen" <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
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.
Have you looked at KeycloakServer inside the testsuite? You
can spin up a perfectly functional KC server with nothing but
an embedded Undertow server.
On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
> 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.
Somebody has to process the annotations in
org.keycloak.models.jpa.entities, do injection,
interception, etc. That's the job of the EE containers.
>
> We just need the classes which we can get with jboss-modules.
>
> On 21 October 2015 at 20:16, Stan Silvert
> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>
> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>> We manage our own EntityManagerFactory and
>>> EntityManager as well as our own transactions. So
>>> that's not true.
>> If all you need is the datasource info that lives in
>> standalone.xml then yes, we can get that.
> 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.
>>
>>>
>>> On 21 October 2015 at 19:53, Stan Silvert
>>> <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>>
>>> wrote:
>>>
>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>> Guys - all we need is the datasource. I want
>>>> to create a "db tool" for Keycloak, this
is
>>>> not for the Admin CLI
>>>>
>>>> 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.
>>>>
>>>> If offline mode can do this then that'd be
>>>> good, but I seem to remember datasources
>>>> weren't available?
>>> 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.
>>>
>>> Hey, let's just use JDBC! :-)
>>>
>>>>
>>>> On 21 October 2015 at 18:22, Marko Strukelj
>>>> <mstrukel(a)redhat.com
>>>> <mailto:mstrukel@redhat.com>> wrote:
>>>>
>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan
>>>> Silvert <ssilvert(a)redhat.com
>>>> <mailto:ssilvert@redhat.com>> wrote:
>>>>
>>>> On 10/21/2015 11:14 AM, Marko Strukelj
>>>> wrote:
>>>>
>>>> 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 ...
>>>>
>>>> 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.
>>>>
>>>> Here is an explanation of the problem
>>>> based on an old version of JBoss:
>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Or, as I mentioned, you need the CLI
>>>> to actually live inside the container.
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:11 a.m.
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?
On 22 October 2015 at 15:03, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/22/2015 2:05 AM, Stian Thorgersen wrote:
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.
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.
So if it's WildFly CLI then there is obviously no problem reading
standalone.xml in a standard way.
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.
On 21 October 2015 at 22:48, Marko Strukelj <mstrukel(a)redhat.com> wrote:
> @Stian, so your original question is then:
>
> 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?
>
> That would involve identifying Datasource jndi lookup name, finding
> datasource definition for it, identifying the driver used, and jboss-module
> containing the driver ...
>
> 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 ...
> On Oct 21, 2015 21:39, "Stian Thorgersen" <sthorger(a)redhat.com>
wrote:
>
>> 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.
>>
>> Have you looked at KeycloakServer inside the testsuite? You can spin up
>> a perfectly functional KC server with nothing but an embedded Undertow
>> server.
>>
>> On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>
>>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>>>
>>> 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.
>>>
>>> Somebody has to process the annotations in
>>> org.keycloak.models.jpa.entities, do injection, interception, etc.
That's
>>> the job of the EE containers.
>>>
>>>
>>>
>>> We just need the classes which we can get with jboss-modules.
>>>
>>> On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>>
>>>> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>>>>
>>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>>>
>>>> We manage our own EntityManagerFactory and EntityManager as well as
>>>> our own transactions. So that's not true.
>>>>
>>>> If all you need is the datasource info that lives in standalone.xml
>>>> then yes, we can get that.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> On 21 October 2015 at 19:53, Stan Silvert <ssilvert(a)redhat.com>
wrote:
>>>>
>>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>>>
>>>>> Guys - all we need is the datasource. I want to create a "db
tool"
>>>>> for Keycloak, this is not for the Admin CLI
>>>>>
>>>>> 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.
>>>>>
>>>>> If offline mode can do this then that'd be good, but I seem to
>>>>> remember datasources weren't available?
>>>>>
>>>>> 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.
>>>>>
>>>>> Hey, let's just use JDBC! :-)
>>>>>
>>>>>
>>>>> On 21 October 2015 at 18:22, Marko Strukelj
<mstrukel(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
<ssilvert(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>>>>
>>>>>>>> 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 ...
>>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Here is an explanation of the problem based on an old version
of
>>>>>>> JBoss:
>>>>>>>
>>>>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Or, as I mentioned, you need the CLI to actually live inside
the
>>>>>>> container.
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
8:31 a.m.
On 10/22/2015 9:11 AM, Stian Thorgersen wrote:
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?
You are reading standalone.xml in a standard way, which is better than
parsing it ourselves.
Beyond that, I'd have to try it out to see what other benefits there
would be. It could be that it is indeed very easy to get the
datasource itself. Now that my brain is fixed concerning using
Hibernate directly, I'm thinking this might be possible.
Of course, there are lots of benefits beyond the offline CLI use case,
which I've talked about at great length.
On 22 October 2015 at 15:03, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/22/2015 2:05 AM, Stian Thorgersen wrote:
> 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.
>
> 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.
So if it's WildFly CLI then there is obviously no problem reading
standalone.xml in a standard way.
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.
>
> On 21 October 2015 at 22:48, Marko Strukelj <mstrukel(a)redhat.com
> <mailto:mstrukel@redhat.com>> wrote:
>
> @Stian, so your original question is then:
>
> 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?
>
> That would involve identifying Datasource jndi lookup name,
> finding datasource definition for it, identifying the driver
> used, and jboss-module containing the driver ...
>
> 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 ...
>
> On Oct 21, 2015 21:39, "Stian Thorgersen"
> <sthorger(a)redhat.com <mailto:sthorger@redhat.com>> wrote:
>
> 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.
>
> Have you looked at KeycloakServer inside the testsuite?
> You can spin up a perfectly functional KC server with
> nothing but an embedded Undertow server.
>
> On 21 October 2015 at 21:08, Stan Silvert
> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote:
>
> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>> 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.
> Somebody has to process the annotations in
> org.keycloak.models.jpa.entities, do injection,
> interception, etc. That's the job of the EE containers.
>
>
>>
>> We just need the classes which we can get with
>> jboss-modules.
>>
>> On 21 October 2015 at 20:16, Stan Silvert
>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
>> wrote:
>>
>> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>>> We manage our own EntityManagerFactory and
>>>> EntityManager as well as our own transactions.
>>>> So that's not true.
>>> If all you need is the datasource info that
>>> lives in standalone.xml then yes, we can get that.
>> 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.
>>>
>>>>
>>>> On 21 October 2015 at 19:53, Stan Silvert
>>>> <ssilvert(a)redhat.com
>>>> <mailto:ssilvert@redhat.com>> wrote:
>>>>
>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>>> Guys - all we need is the datasource. I
>>>>> want to create a "db tool" for
Keycloak,
>>>>> this is not for the Admin CLI
>>>>>
>>>>> 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.
>>>>>
>>>>> If offline mode can do this then that'd
>>>>> be good, but I seem to remember
>>>>> datasources weren't available?
>>>> 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.
>>>>
>>>> Hey, let's just use JDBC! :-)
>>>>
>>>>>
>>>>> On 21 October 2015 at 18:22, Marko
>>>>> Strukelj <mstrukel(a)redhat.com
>>>>> <mailto:mstrukel@redhat.com>>
wrote:
>>>>>
>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan
>>>>> Silvert <ssilvert(a)redhat.com
>>>>> <mailto:ssilvert@redhat.com>>
wrote:
>>>>>
>>>>> On 10/21/2015 11:14 AM, Marko
>>>>> Strukelj wrote:
>>>>>
>>>>> 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 ...
>>>>>
>>>>> 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.
>>>>>
>>>>> Here is an explanation of the
>>>>> problem based on an old version
>>>>> of JBoss:
>>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Or, as I mentioned, you need the
>>>>> CLI to actually live inside the
>>>>> container.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
12:29 p.m.
If you can manage to get the datasource in offline mode that'd be great,
because then we don't have to do any hacks to get the connection.
On 22 October 2015 at 15:31, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 10/22/2015 9:11 AM, Stian Thorgersen wrote:
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?
You are reading standalone.xml in a standard way, which is better than
parsing it ourselves.
Beyond that, I'd have to try it out to see what other benefits there would
be. It could be that it is indeed very easy to get the datasource
itself. Now that my brain is fixed concerning using Hibernate directly,
I'm thinking this might be possible.
Of course, there are lots of benefits beyond the offline CLI use case,
which I've talked about at great length.
On 22 October 2015 at 15:03, Stan Silvert <ssilvert(a)redhat.com> wrote:
> On 10/22/2015 2:05 AM, Stian Thorgersen wrote:
>
> 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.
>
> 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.
>
> So if it's WildFly CLI then there is obviously no problem reading
> standalone.xml in a standard way.
>
> 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.
>
>
> On 21 October 2015 at 22:48, Marko Strukelj <mstrukel(a)redhat.com> wrote:
>
>> @Stian, so your original question is then:
>>
>> 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?
>>
>> That would involve identifying Datasource jndi lookup name, finding
>> datasource definition for it, identifying the driver used, and jboss-module
>> containing the driver ...
>>
>> 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 ...
>> On Oct 21, 2015 21:39, "Stian Thorgersen" <sthorger(a)redhat.com>
wrote:
>>
>>> 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.
>>>
>>> Have you looked at KeycloakServer inside the testsuite? You can spin up
>>> a perfectly functional KC server with nothing but an embedded Undertow
>>> server.
>>>
>>> On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com> wrote:
>>>
>>>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
>>>>
>>>> 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.
>>>>
>>>> Somebody has to process the annotations in
>>>> org.keycloak.models.jpa.entities, do injection, interception, etc.
That's
>>>> the job of the EE containers.
>>>>
>>>>
>>>>
>>>> We just need the classes which we can get with jboss-modules.
>>>>
>>>> On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com>
wrote:
>>>>
>>>>> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>>>>>
>>>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>>>>
>>>>> We manage our own EntityManagerFactory and EntityManager as well as
>>>>> our own transactions. So that's not true.
>>>>>
>>>>> If all you need is the datasource info that lives in standalone.xml
>>>>> then yes, we can get that.
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>> On 21 October 2015 at 19:53, Stan Silvert
<ssilvert(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>>>>
>>>>>> Guys - all we need is the datasource. I want to create a "db
tool"
>>>>>> for Keycloak, this is not for the Admin CLI
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> If offline mode can do this then that'd be good, but I seem
to
>>>>>> remember datasources weren't available?
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Hey, let's just use JDBC! :-)
>>>>>>
>>>>>>
>>>>>> On 21 October 2015 at 18:22, Marko Strukelj
<mstrukel(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
<ssilvert(a)redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>>>>>
>>>>>>>>> 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 ...
>>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Here is an explanation of the problem based on an old
version of
>>>>>>>> JBoss:
>>>>>>>>
>>>>>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Or, as I mentioned, you need the CLI to actually live
inside the
>>>>>>>> container.
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
>
7:55 a.m.
On 10/21/2015 3:39 PM, Stian Thorgersen wrote:
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.
You're right.
I've been working strictly with the app server too many
years.
It's still a JEE container. JPA is part of the JEE spec. In this case
you are just getting it directly from Hibernate.
Have you looked at KeycloakServer inside the testsuite? You can spin
up a perfectly functional KC server with nothing but an embedded
Undertow server.
On 21 October 2015 at 21:08, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
On 10/21/2015 2:43 PM, Stian Thorgersen wrote:
> 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.
Somebody has to process the annotations in
org.keycloak.models.jpa.entities, do injection, interception,
etc. That's the job of the EE containers.
>
> We just need the classes which we can get with jboss-modules.
>
> On 21 October 2015 at 20:16, Stan Silvert <ssilvert(a)redhat.com
> <mailto:ssilvert@redhat.com>> wrote:
>
> On 10/21/2015 2:08 PM, Stan Silvert wrote:
>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote:
>>> We manage our own EntityManagerFactory and EntityManager as
>>> well as our own transactions. So that's not true.
>> If all you need is the datasource info that lives in
>> standalone.xml then yes, we can get that.
> 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.
>>
>>>
>>> On 21 October 2015 at 19:53, Stan Silvert
>>> <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>>
wrote:
>>>
>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote:
>>>> Guys - all we need is the datasource. I want to create
>>>> a "db tool" for Keycloak, this is not for the Admin
CLI
>>>>
>>>> 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.
>>>>
>>>> If offline mode can do this then that'd be good, but I
>>>> seem to remember datasources weren't available?
>>> 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.
>>>
>>> Hey, let's just use JDBC! :-)
>>>
>>>>
>>>> On 21 October 2015 at 18:22, Marko Strukelj
>>>> <mstrukel(a)redhat.com
<mailto:mstrukel@redhat.com>> wrote:
>>>>
>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert
>>>> <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>>
>>>> wrote:
>>>>
>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote:
>>>>
>>>> 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 ...
>>>>
>>>> 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.
>>>>
>>>> Here is an explanation of the problem based on
>>>> an old version of JBoss:
>>>>
https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBo...
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Or, as I mentioned, you need the CLI to
>>>> actually live inside the container.
>>>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
3139
days inactive
3140
days old
21 comments
3 participants
participants (3)
-
Marko Strukelj -
Stan Silvert -
Stian Thorgersen