On 8/3/2016 3:58 PM, James Perkins wrote:


On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat