[wildfly-dev] AppClientXml - Post Code Split

[Brian Stansberry]

Just compatibility. Changing the "standard" element name means updating 
docs, examples etc.

We are going to have to parse legacy documents with 'server' no matter what.

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
>


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