[wildfly-dev] About client-side configuration

[Stan Silvert]

It sounds good to me.  I can't think of a strong reason to make the 
dependency optional.

On 11/21/2014 1:42 PM, David M. Lloyd wrote:
> I'm currently working on reorganizing most of our client-side components
> to support URI-based connection and invocation for the following services:
>
> • JBoss Remoting
> • EJB Client
> • Remote Naming (JNDI)
> • Remote Transactions
> • Elytron (remote authentication)
>
> Each of these components will require a separate chunk of configuration.
>    The works in progress presently will rely on separated XML files for
> each of these things (which in many/most cases will be reusable
> in-container as deployment descriptors).
>
> I think you see where I'm going with this.
>
> I'm kicking around the idea of doing something kind of similar to the
> unified configuration idea we tried out in WildFly, where there's one
> namespaced configuration file with each component picking up its piece
> via some registration process.
>
> The upside is, (optionally?) one client-side configuration file for
> everything, even things we haven't written yet.
>
> The downside is having another common dependency for everything that
> consumes client configuration.  Though we *could* make it optional
> (which in turn has another downside that we can't really unify our
> parsing, which has some benefits like consistent error reporting,
> xinclude support, and pretty substantial code deduplication, among
> (probably) other things).
>
> I'm leaning towards just going ahead with it and creating a small
> wildfly-client-configuration project which parses a "wildfly-client.xml"
> file and does the business.
>
> Any thoughts, opinions, additional reasons not to do this?