5:03 p.m.
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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>