I like D (reference counting). Also, it would be ideal to know the "apps"
that have declared such resource. It would be ideal to have a way (API,
admin...) to know which applications have declared it.
Antonio
On Tue, Feb 10, 2015 at 1:19 AM, Bill Shannon <bill.shannon_at_oracle.com>
wrote:
> 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.
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>