[wildfly-dev] AppClientXml - Post Code Split

[Brian Stansberry]

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.

If we add an API it needs to be really coarse grained.

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.


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