Re: [wildfly-dev] AppClientXml - Post Code Split

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(a)jboss.com&gt; 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(a)jboss.com&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>