[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