If the config data type is java.lang.String (or any other primitive types), just use <env-entry>. Do not use <resource-env-ref> or <resource-ref>, both are intended for more complex resources like jdbc or jms.
Any reason you have to use the conflicting names? Whether you prefix it or not, they are still conflicting names. The reason it worked in some case is probably the validaton is not triggered but it may ultimately fail down the road.
My suggestion would be to fix the application web.xml. This is the only way to achieve consistent and compatible results across differnet servers.
On second thought I still think the "Incompatible conflicting binding" error shouldn't be there.
A small note on what I actually try to achieve here (since I oversimplified my example):
- Local development server is JBoss/Jetty (deploy frequently)
- Remote development server is WebSphere (deploy occasionally)
- In web.xml I define the resource-env-ref entries. (I would like the deployment to fail if the refered references are not present)
- In jboss-web.xml I define the env-entries. Which makes it easy to frequently change the values during development (or just install another JBoss version).
(For Jetty there is a jetty-env.xml with an equivalent of env-entry records)
- In Websphere the resource-env-ref values are server side defined as name space bindings (the same way as the production environment).
In my opinion the env-entry should just be handled as a simple binding as in standalone.xml:
some string value"
There should only be a conflict once there are two bindings defined with the same name. The resource-env-ref tag doesn't count since it is only a reference (it doesn't define any value)
Whether you use <env-entry>, <resource-env-ref>, <resource-ref>, or <ejb-ref>, they are all reference names in a single namespace belonging to your webapp, hence the conflict.
some/entry/name, is the same as java:comp/env/some/entry/name, and is also the same as java:module/env/some/entry/name, for reference resolution purpose.
Not sure I completely understand your use case, but I would declare a <env-entry>, mapping it to a global jndi name with <lookup-name> or <mapped-name>. So you app always looks up or injects the same ref name, and different server can create this global resource differently.
Ok thanks for the explanation Cheng.
Simply put I just need a way to define a value for a resource-env-ref of type java.lang.String directly in a deployment descriptor.
Is there a possibility to do this somehow in JBoss? (without replacing resource-env-ref with env-entry)