[wildfly-dev] AppClientXml - Post Code Split

[Darran Lofthouse]

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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>