Hi,
On Wed, Feb 18, 2015 at 10:13 PM, Anatole Tresch <atsticks_at_gmail.com> wrote:
> 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.
That's indeed a pretty good point. It's easy to think of resources in
terms of the well known ones like a stateless data source that can be
easily shared and reference counted. However, a resource can of course
be anything and even a data source can contain anything. Not every
data source is just a driver for an external DB, some actually
represent the DB itself (common for embedded DBs).
Aren't two Bean definitions for the same thing, even if completely
identical, a conflict (error) in CDI as well?
Kind regards,
Arjan Tijms
> 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/
> Google: atsticks
> Mobile +41-76 344 62 79
>
>
>
> --
> 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/
> Google: atsticks
> Mobile +41-76 344 62 79