On 8/3/2016 3:58 PM, James Perkins wrote:
On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
The Keycloak server is currently configured via a keycloak-server.json
file. We are converting this to configuration through
standalone.xml/domain.xml.
To automatically upgrade, I need to read keycloak-server.json and
write
back to standalone.xml. I can easily add the operations to do this at
parse time. The parser has this method:
@Override
public void readElement(final XMLExtendedStreamReader reader, final
List<ModelNode> list) throws XMLStreamException
Reading an external resource from the subsystem parsing doesn't feel
right to me. Is the goal to move away from the keycloak-server.json to
using the management model?
Yes, that's the goal. I'd like it to happen
automatically when the
server is upgraded to a new version of the Keycloak subsystem. So we
need to read keyclaok-server.json and write to standalone.xml/domain.xml.
If that is the goal then a better solution might be to have some sort
of migration operation that would read the file and create the
subsystem model. Then after that the keycloak-server.json is ignored
and the *.xml file will be used.
That's exactly what I am trying to accomplish.
I can create the
subsystem model easily. But a write to standalone.xml doesn't happen
during server startup.
So one way to do this is to parse keycloak-server.json at this
time and
add operations to the list.
That puts everything into the management model. But nothing will be
written to standalone.xml unless someone manually does a write
operation
from CLI.
A write will be triggered if you make a change to the management model.
So my question is, what is the best way to accomplish this? Is
there a
good, safe way to manually trigger a flush to standalone.xml at this
point or at some later point during startup?
Not really an answer, but I hope there is not a way to trigger a write :)
This
could be done without harm as long as it is managed properly.
If there is no way to do it then I'll have to make it a separate
operation that the administrator has to run using offline CLI. That's
far from ideal as I would rather it happen automatically as part of the
upgrade.
Stan
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
James R. Perkins
JBoss by Red Hat