Skip to main content

Re: attribute stores - general comments

  • From: binod pg < >
  • To:
  • Subject: Re: attribute stores - general comments
  • Date: Mon, 10 Feb 2014 21:04:02 +0530
  • Organization: Oracle Corporation

Hi Tom,

On 2/10/2014 5:42 PM, Tom Strickland wrote:
Text: 7.1 Attributes
"Attributes are visible only in the same application. Here the application boundary is determined by the ear files. If an application access the attributes across different modules of the same ear file, then the class visibility rules apply for the class of the attribute objects."

TomStrickland: I'm a little confused. These two sentences seem to refer to two different things. Firstly, the visibility of an attribute. Perhaps it is more accurate to talk about the visibility of an AttributeStore - such as SipApplicationSession. Secondly, the "class visibility rules" is about classloading, and a reminder that a class' definition includes its classloader in addition to its package and name. The running on of these sentences is slightly confusing, as these are separate points.
Have I understood the wording correctly? If I have, I'm working on a clearer text. I also think that the first point is a little unclear and that the implications of the second point could be spelled out more clearly.
EAR boundaries in AttributeStore visibility.
This originally started out as a longer piece of text, but to save you all the tedium, I've cut it down to a stupid question :-)
Am I right in thinking that application boundaries vary, being defined at the EAR level. Given WAR-A and WAR-b, both within the same EAR: whether a SipApplicationSession from WAR-a is visible in WAR-b depends on how the EAR is configured: sometimes yes, sometimes no.

For an attribute to be visible in a different module, both attribute store and the attribute class should be visible.
Attribute Store visibility is at the application level. i.e SAS of EAR-A cannot be accessed by SAS of EAR-B.
Even when attribute stores are visible, the class visibility of attribute classes depend on the class loading.

Seems like EE spec has clearly spelled out the rules for class visibility under section 8.3.1. May be we should
refer to that to be super clear.

7.2 AttributeStores
Text: "SipSession, SipApplicationSession, ForkingContext, SipServletRequest, and SipServletResponse and InviteBranch are the attribute stores at the time of writing this specification."
TomStrickland: Could ConvergedHttpSession also be an AttributeStore?

Since the attribute specific methods are part of HttpSession and not ConvergedHttpSession, I thought not to disturb that.

Text: void removeAttributes()
TomStrickland: Would removeAllAttributes() be a better method name - more readable at a glance than a single letter difference?




Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. CafeX Communications.

attribute stores - general comments

Tom Strickland 02/10/2014

Re: attribute stores - general comments

binod pg 02/10/2014

Re: attribute stores - general comments

Tom Strickland 02/10/2014

Re: attribute stores - general comments

binod pg 02/11/2014

Re: attribute stores - general comments

Tom Strickland 02/11/2014
Please Confirm