[wildfly-dev] AppClientXml - Post Code Split

[Brian Stansberry]

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.

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.

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


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat