On 8/5/14, 11:07 AM, Darran Lofthouse 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. > Perhaps. I know it's wrong but I'm tempted to pull the whole thing into core. I don't much like having core parsing stuff as part of the API exposed by core.

If we add an API it needs to be really coarse grained.

The only tie this class has to anything outside of core is one logger message that at a glance looks like something that probably already exists in core.

Just to split this into two decisions: - Is there any reason the root element needs to be 'server' even though the server definition differs depending on what is parsing it or should we add a new root element 'client'? On 05/08/14 17:26, Darran Lofthouse wrote: > > > On 05/08/14 17:20, Brian Stansberry wrote: >> On 8/5/14, 11:07 AM, Darran Lofthouse 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. >>> >> >> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >> core. I don't much like having core parsing stuff as part of the API >> exposed by core. > > Yeah feel the same on that one, trying to find a solution that isn't wrong. > >> If we add an API it needs to be really coarse grained. > > Yes I was thinking something corse grained to the level of: - > parseProfile() > parseSocketBindings() > > Each of these methods would then need to be responsible for their own > version check. > >> The only tie this class has to anything outside of core is one logger >> message that at a glance looks like something that probably already >> exists in core. >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 05/08/14 18:44, Brian Stansberry wrote: > Just compatibility. Changing the "standard" element name means updating > docs, examples etc. Personally I think that is just something we have to accept we will have to do - at the moment we have a parser that follows a schema 'a bit' and I don't think docs and examples are a strong enough justification to keep it that way for WF9 and beyond. > We are going to have to parse legacy documents with 'server' no matter what. +1 which is why I am suggesting we fix it from version 3. > On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >> Just to split this into two decisions: - >> >> Is there any reason the root element needs to be 'server' even though >> the server definition differs depending on what is parsing it or should >> we add a new root element 'client'? >> >> On 05/08/14 17:26, Darran Lofthouse wrote: >>> >>> >>> On 05/08/14 17:20, Brian Stansberry wrote: >>>> On 8/5/14, 11:07 AM, Darran Lofthouse 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. >>>>> >>>> >>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>> core. I don't much like having core parsing stuff as part of the API >>>> exposed by core. >>> >>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>> >>>> If we add an API it needs to be really coarse grained. >>> >>> Yes I was thinking something corse grained to the level of: - >>> parseProfile() >>> parseSocketBindings() >>> >>> Each of these methods would then need to be responsible for their own >>> version check. >>> >>>> The only tie this class has to anything outside of core is one logger >>>> message that at a glance looks like something that probably already >>>> exists in core. >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 05/08/14 19:05, Brian Stansberry wrote: > TBH, I don't care much one way or the other. :) Using 'server' sucks; > changing names invariable comes back and bites you with tedious work > when you're least in the mood. So, choose your poison. If you prefer the > 'client' poison, that's ok with me. Well it is not as if this isn't already biting us ;-) I think this class has bitten me a couple of times now.

> Wait for Stuart to have a chance to read this though as he's the poor > soul who's had to do the most work in this area. Sure already 7pm here so not going to be a task for tonight. > On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >> On 05/08/14 18:44, Brian Stansberry wrote: >>> Just compatibility. Changing the "standard" element name means updating >>> docs, examples etc. >> >> Personally I think that is just something we have to accept we will have >> to do - at the moment we have a parser that follows a schema 'a bit' and >> I don't think docs and examples are a strong enough justification to >> keep it that way for WF9 and beyond. >> >>> We are going to have to parse legacy documents with 'server' no matter what. >> >> +1 which is why I am suggesting we fix it from version 3. >> >> >>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>> Just to split this into two decisions: - >>>> >>>> Is there any reason the root element needs to be 'server' even though >>>> the server definition differs depending on what is parsing it or should >>>> we add a new root element 'client'? >>>> >>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>> >>>>> >>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse 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. >>>>>>> >>>>>> >>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>> exposed by core. >>>>> >>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>> >>>>>> If we add an API it needs to be really coarse grained. >>>>> >>>>> Yes I was thinking something corse grained to the level of: - >>>>> parseProfile() >>>>> parseSocketBindings() >>>>> >>>>> Each of these methods would then need to be responsible for their own >>>>> version check. >>>>> >>>>>> The only tie this class has to anything outside of core is one logger >>>>>> message that at a glance looks like something that probably already >>>>>> exists in core. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Brian Stansberry wrote: > TBH, I don't care much one way or the other. :) Using 'server' sucks; > changing names invariable comes back and bites you with tedious work > when you're least in the mood. So, choose your poison. If you prefer the > 'client' poison, that's ok with me. > > Wait for Stuart to have a chance to read this though as he's the poor > soul who's had to do the most work in this area. I am happy to change it to have the 'client' root element, although we need to maintain compatibility. It looks like current issues are mostly because I did this in a hurry and did not think it through. I think we should also just move this into core. It does feel a bit wrong because this is an EE thing, but I think it is the simplest solution. Stuart > > On 8/5/14, 1:00 PM, Darran Lofthouse wrote: >> On 05/08/14 18:44, Brian Stansberry wrote: >>> Just compatibility. Changing the "standard" element name means updating >>> docs, examples etc. >> Personally I think that is just something we have to accept we will have >> to do - at the moment we have a parser that follows a schema 'a bit' and >> I don't think docs and examples are a strong enough justification to >> keep it that way for WF9 and beyond. >> >>> We are going to have to parse legacy documents with 'server' no matter what. >> +1 which is why I am suggesting we fix it from version 3. >> >> >>> On 8/5/14, 12:16 PM, Darran Lofthouse wrote: >>>> Just to split this into two decisions: - >>>> >>>> Is there any reason the root element needs to be 'server' even though >>>> the server definition differs depending on what is parsing it or should >>>> we add a new root element 'client'? >>>> >>>> On 05/08/14 17:26, Darran Lofthouse wrote: >>>>> >>>>> On 05/08/14 17:20, Brian Stansberry wrote: >>>>>> On 8/5/14, 11:07 AM, Darran Lofthouse 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. >>>>>>> >>>>>> Perhaps. I know it's wrong but I'm tempted to pull the whole thing into >>>>>> core. I don't much like having core parsing stuff as part of the API >>>>>> exposed by core. >>>>> Yeah feel the same on that one, trying to find a solution that isn't wrong. >>>>> >>>>>> If we add an API it needs to be really coarse grained. >>>>> Yes I was thinking something corse grained to the level of: - >>>>> parseProfile() >>>>> parseSocketBindings() >>>>> >>>>> Each of these methods would then need to be responsible for their own >>>>> version check. >>>>> >>>>>> The only tie this class has to anything outside of core is one logger >>>>>> message that at a glance looks like something that probably already >>>>>> exists in core. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

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 >>