users@javaee-spec.java.net

[javaee-spec users] Re: ​Re: [jsr366-experts] global resources

From: Romain Manni-Bucau <rmannibucau_at_gmail.com>
Date: Wed, 18 Feb 2015 23:52:49 +0100

Not exactly, it is the case only when the container (CDI) can't do the
difference or choose. For resources you can since you know which app
asks it and where.


Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2015-02-18 23:48 GMT+01:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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