[wildfly-dev] About client-side configuration

David M. Lloyd david.lloyd at redhat.com
Fri Nov 21 13:42:53 EST 2014


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?
-- 
- DML


More information about the wildfly-dev mailing list