Re: [wildfly-dev] AppClientXml - Post Code Split
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.