[wildfly-dev] AppClientXml - Post Code Split

Darran Lofthouse darran.lofthouse at jboss.com
Tue Aug 5 13:38:09 EDT 2014


LOL, yeah I am not saying your interests are invalid - just not the 
topic I am trying to cover on this thread ;-)

On 05/08/14 18:27, Eduardo Martins wrote:
> And I’m more interested in having app client to follow the other configs, since I’m working on that for the new wildfly build tools to assemble feature packs and servers :-)
>
> All the code works with a config template plus a set of subsystem config files, I don’t really see a reason to not fix it all now.
>
> —E
>
> On 05 Aug 2014, at 17:31, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>
>> At this point I am more interested in the schemas and parsers, assembly of the default configs is a new issue on it's own ;-)
>>
>> On 05/08/14 17:26, Eduardo Martins wrote:
>>> IMHO app client xml should use a config template like standalone and domain, and be filled with specific subsystem supplements.
>>>
>>> —E
>>>
>>> On 05 Aug 2014, at 17:07, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>>>
>>>> After forward porting some schema changes from EAP to WildFly it has
>>>> become apparent that it is a little cumbersome to work with AppClientXml
>>>> as it's implementation is dependent on the schema definitions in
>>>> wildfly-core and yet it lives in wildfly.
>>>>
>>>> The first point I realise is that the root element parsed by
>>>> AppClientXml is 'server' however it only accepts a subset of the
>>>> elements defined as supported by the 'server' element.  Could it make
>>>> sense for version 3 of the schema and onward to have a new root element
>>>> 'client'?
>>>>
>>>> Secondly this could open up the option to have the client element
>>>> defined in a schema in wildfly and just reference the types that are in
>>>> wildfly-core.  wildfly would then contain the parsing code for client
>>>> and the parsing code for the referenced types would be in wildfly-core
>>>> and accessed through an agreed API that we maintain for compatibility.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>


More information about the wildfly-dev mailing list