Jeanfrancois Arcand wrote:
> Hi Harsha,
>
Hi Jeanfrancois,
> Harsha Godugu wrote:
>> Jeanfrancois Arcand wrote:
>>> Hi Alexey,
>>>
>>> Oleksiy Stashok wrote:
>>>> Hi,
>>>>
>>>> IMHO this bug should be closed.
>>>> Don't think we really need this extension to apply to our
>>>> AttributeHolder implementation.
>>>> As attributes are used both inside Grizzly framework and outside,
>>>> by developers, it's difficult to make any assumptions about
>>>> possible parameter types.
>>>>
>>>> What do you think?
>>>
>>> I agree :-)
>>>
>>> -- Jeanfrancoid
>> I disagree :-(
>>
>> Reason.. think about a generic use-case of Collections (since you are
>> using a Map..) in the places where we /Grizzly is using Keys .. for
>> example, in SlectorHandler, Collector,
>
> Collector :-)
oops.. I meant to say Controller .. (out of subject /context... all
these terms are going in a rhyme like.. controller, selector,
collection, handler... with a great difference in meaning!)
>
> Context... What would be the
>> BEST to describe an attribute in a collection, in the context of
>> grizzly's Context, SelectorHandler, Controller? does it really a
>> String type? Actually, the way Grizzly using the *term* attribute is
>> not even appropriate. Why? attribute is something that describes a
>> specific distinguishable feature of the particular object (or
>> instance). The way grizzly uses here is, to store SOME objects and
>> their references, in case it needs at various scopes. This forces
>> users to "create" their own strings?keys (to accommodate in) to
>> retrieve the references.
>
> Right. Might not be perfect, but a lot of API use that approach:
>
> http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html
> http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html
Ok. I think, I'm looking this issue from a different (non-Web)
background Certainly, not XML/Key-Value pairs.
>
>>
>> Take the case of grizzly's Context which ALSO acts as an
>> AttributeHolder.
>> If I read the API for the latest Context.java... what does it say -
>> "Used to share objects b/w ProtocolFilter"
>> Now, if I want to use this place-holder to STORE my objects , what's
>> the best way to identify my collection of Objects in a Grizzly's
>> Context. Does it really a String?
>
> Implementation wise, the code is less complex when String is used. I
> think you should send a patch with your changes so we can see exactly
> the use case.
>
>>
>> Since we can not go back, now we ought to stick to the one in place.
>> Thats where we are.
>
> I don't understand what you means above :-)
What I meant was, since we have this code already in place, we have a
dependency; which will break existing applications if we fix this issue.
Thanks,
Harsha
>
> Thanks
>
> -- Jeanfrancois
>
>>
>> -hg
>>
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> Subject:
>>>> [Issue 53] AttributeHolder needs maps with parameterized types <T>
>>>> From:
>>>> jfarcand_at_dev.java.net
>>>> Date:
>>>> Thu, 14 Feb 2008 22:28:23 +0000
>>>> To:
>>>> issues_at_grizzly.dev.java.net
>>>>
>>>> To:
>>>> issues_at_grizzly.dev.java.net
>>>>
>>>>
>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=53
>>>>
>>>>
>>>>
>>>> User jfarcand changed the following:
>>>>
>>>> What |Old value |New value
>>>> ================================================================================
>>>>
>>>> Priority|P1 |P3
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------- Additional comments from jfarcand_at_dev.java.net Thu Feb 14
>>>> 22:28:23 +0000 2008 -------
>>>> Not a p1 IMO
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: issues-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: issues-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>