It sounds good to me. I can't think of a strong reason to make the
On 11/21/2014 1:42 PM, David M. Lloyd wrote:
I'm currently working on reorganizing most of our client-side
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?