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

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