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

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