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

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