[wildfly-dev] AppClientXml - Post Code Split

[Stuart Douglas]

Brian Stansberry wrote:
> 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.

I am happy to change it to have the 'client' root element, although we 
need to maintain compatibility. It looks like current issues are mostly 
because I did this in a hurry and did not think it through.

I think we should also just move this into core. It does feel a bit 
wrong because this is an EE thing, but I think it is the simplest solution.

Stuart


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