Alignment of container configuration property names

[dan.j.allen]

While evaluating and documenting the various container adapters and configuration, I've noticed a large variation in property names for the same attribute. To improve the usability of Arquillian, we should adhere to a unified set of names for common properties across containers.

I'll provide some examples.

Host or Address:

JBoss OSGi: host

GlassFish: adminHost

Embedded containers: bindAddress

Remote/managed containers: remoteServerAddress

(point here is that we should use either "Address" or "Host" and be consistent...the obvious choice is "Address")

Http Port:

JBoss AS / Tomcat: httpPort

GlassFish: remoteServerHttpPort

GlassFish: adminPort

In many cases, the httpPort is really a remoteServerHttpPort and what type of port is the adminPort for GlassFish?

Username/Password:

Tomcat: user/pass

GlassFish: adminUser/adminPassword

All other containers: username/password

We should also be clear what the username and password is for. In the case of tomcat, it's really adminUser and adminPassword.

---

Those are just some examples. More digging may reveal others. Ideally it would be good to have a conventions table that we can cross reference. It would also help users understand our naming conventions so that they know what to expect.

As part of that documentation, we should make it very clear whether we use CamelCase or ACRONYMCASE for acronyms like HTTP. It's pretty clear that we've mostly adopted CamelCase, so we might as well continue in that direction.

[aslak]

I've had it in the back of my head to align them, but currently they attempt to follow the domain they are used in, the containers lingo if you will.

But it's a more difficult task then it might seem. e.g. bindAddress vs remoteServerAddress, vs adminHost(tho adminAddress is probably better). In some embedded/managed containers we can control the address so it's called bind, while others embedded or not, we can't(you need to setup the bindAddress in their config and only tell arquillian here it is). In GlassFish lingo it's the admin server you connect to, not the server it self. Hench also why it's adminUser/adminPassword for GlassFish.

In Tomcat it is really managerUser/managerPassword.

GlassFish adminPort, there is only one i think. If i remember correctly, glassfish multiplex different types of protocol on the same port.

[dan.j.allen]

After pondering this for awhile, I realized it isn't quite as divergent as I had first thought.

There are probably two really sore thumbs, as you just summarized:

Tomcat user/pass, which are just terrible property names anyway. Sounds like a JIRA is in order there.

GlassFish adminPort I'm pretty sure is a REST endpoint (or we are using it that way) so it should be adminHttpPort. Maybe a JIRA?

I was aware of the bind prefix. That part I get. The way I see it, the property should go one of two ways...it's either bind (hence local) or remoteServer (for remote). Unless I'm missing a case, there shouldn't be anything in between.

Aside from maybe a few JIRAs, what should come out of this I think is just some documentation as to how we got to the names (shouldn't take long for the basic stuff), so that third-party container adapters can align if they so choose.

[aslak]

Dan Allen wrote:

I was aware of the bind prefix. That part I get. The way I see it, the property should go one of two ways...it's either bind (hence local) or remoteServer (for remote). Unless I'm missing a case, there shouldn't be anything in between.

That's kinda the thing, remoteServer. what remoteServer? GlassFish has a well known termonolgy that says AdminServer. Same with JBoss 7, Management Address.

We could in theory support two sets of properties, the arquillian lingo and the container lingo. Making sure the ContainerConfgiuration can do the 'translation', it would simplify container configuration extensions, as they can 'safely' rely on x number of predefined properties to be available on a container type, while the user can rely on the container lingo as they are used to.

Might end up causing more confusion..

[aslak]

Dan Allen wrote:

Aside from maybe a few JIRAs, what should come out of this I think is just some documentation as to how we got to the names (shouldn't take long for the basic stuff), so that third-party container adapters can align if they so choose.

We should document our usage of bind vs remote, admin vs server etc. Atleast will give a picture to why they are named differently and make it easier for others to follow.