[wildfly-dev] AppClientXml - Post Code Split

[Brian Stansberry]

On 8/5/14, 1:10 PM, Darran Lofthouse wrote:
> On 05/08/14 19:05, 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.
>
> Well it is not as if this isn't already biting us ;-)
>
> I think this class has bitten me a couple of times now.
>

Me too.

>> 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.
>
> Sure already 7pm here so not going to be a task for tonight.
>
>> 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
>>>
>>
>>
> _______________________________________________
> 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