Re: [wildfly-dev] About client-side configuration

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?