[wildfly-dev] AppClientXml - Post Code Split

[Darran Lofthouse]

For previous versions of the schema we are just going to have to stick 
with supporting parsing of 'server', for version 3 I think it will be 
easier to add a clean parser that starts parsing at 'client'.

We probably don't need to move the whole of app client to core but as a 
bare minimum if we moved all the parsing to core it will mean that is 
the only place we need to worry about updates to the as schema.

Although this is where the option to split out the 'client' root element 
definition into it's own schema although complexity wise it is probably 
not worth it.  The concept of a client configuration is probably generic 
enough to be in core even though our motivations for using it are on the 
back of EE.

Regards,
Darran Lofthouse.


On 05/08/14 23:03, Stuart Douglas wrote:
>
>
> 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
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>