[wildfly-dev] Need write to standalone.xml after parsing
James Perkins
jperkins at redhat.com
Thu Aug 4 13:49:23 EDT 2016
On Thu, Aug 4, 2016 at 4:22 AM, Stan Silvert <ssilvert at redhat.com> wrote:
> On 8/3/2016 3:58 PM, James Perkins wrote:
>
>
>
> On Wed, Aug 3, 2016 at 6:53 AM, Stan Silvert <ssilvert at 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.
>
It's designed to never write at startup because during boot the the
configuration is read and we shouldn't modify without the user
acknowledging there is going to be a change. That's why a migration
operation would be preferred as it's explicit.
>
>
>
>>
>> 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.
>
The only time this would ever be needed is during a boot. I really think
it's a bad idea to modify persistent configuration during a boot. The user
has no idea this is being done.
>
>
> 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.
>
IMO an upgrade or patch is an explicit action. It requires some kind of
interaction and expecting a user to execute an operation after a component
upgrade doesn't seem unreasonable to me.
An option for the future will be to use the new provisioning [1].
[1]:
https://github.com/stuartwdouglas/wildfly-provisioning/blob/master/docs/src/main/asciidoc/design-doc.asciidoc
>
>
>
>>
>> Stan
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
>
--
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160804/fd254592/attachment-0001.html
More information about the wildfly-dev
mailing list