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

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