Hi Bill
I strongly would recommend *A*, since it is the only concise behaviour. All
other variants can have unexpected side effects, especially when the shared
resource is capable of holding references to things, it can get very ugly.
Applications should basically be aware of the fact that global JNDI
namespace is global. If they produce conflicts they should be encouraged to
use application local names, if possible.
Best
Anatole
2015-02-10 1:19 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
> Here's another issue that we're looking to clarify...
>
> In section EE.5.2.2 of the platform spec it says:
>
> If multiple application components declare an environment entry
> in one of the shared namespaces, all attributes of that entry
> must be identical in each declaration. For example, if multiple
> components declare a resource reference with the same java:app
> name, the authentication and shareable attributes must be
> identical.
>
> If all attributes of each declaration of a shared environment
> entry are not identical, this must be reported as a deployment
> error to the Deployer. The deployment tool may allow the
> Deployer to correct the error and continue deployment.
>
> What's not completely clear is what should happen if multiple application
> components *in different applications* declare an entry in the java:global
> namespace. There are a few possibilities:
>
> A. disallow
>
> app1 declares java:global/myDB
> app2 declares java:global/myDB with identical attributes
> app1 is deployed, java:global/myDB is created
> app2 fails to deploy because the name java:global/myDB is already
> in use
>
> B. allow, creator owns
>
> app1 declares java:global/myDB
> app2 declares java:global/myDB with identical attributes
> app1 is deployed, java:global/myDB is created
> app2 is deployed, java:global/myDB already exists
> app1 is undeployed, java:global/myDB is removed
> app2 no longer has access to java:global/myDB
>
> C. allow, no reference counting
>
> app1 declares java:global/myDB
> app2 declares java:global/myDB with identical attributes
> app1 is deployed, java:global/myDB is created
> app2 is deployed, java:global/myDB already exists
> app2 is undeployed, java:global/myDB is removed
> app1 no longer has access to java:global/myDB
>
> D. allow, reference counting
>
> app1 declares java:global/myDB
> app2 declares java:global/myDB with identical attributes
> app1 is deployed, java:global/myDB is created
> app2 is deployed, java:global/myDB already exists
> app1 is undeployed, java:global/myDB still exists
> app2 is undeployed, java:global/myDB is removed
>
>
>
> For Java EE implementors:
>
> Which approach do you implement?
>
> A. disallow
> B. allow, creator owns
> C. allow, no reference counting
> D. allow, reference counting
> E. other (explain)
>
>
>
> For Java EE developers:
>
> Which approach do you expect?
>
> A. disallow
> B. allow, creator owns
> C. allow, no reference counting
> D. allow, reference counting
> E. other (explain)
>
>
> For everyone:
>
> Which approach do you think the Java EE 7 spec requires?
>
> A. disallow
> B. allow, creator owns
> C. allow, no reference counting
> D. allow, reference counting
> E. other (explain)
>
>
> Thanks.
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79 <%2B41-76%20344%2062%2079>*
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*