[wildfly-dev] AppClientXml - Post Code Split

[Darran Lofthouse]

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