Hi Cheng,
Cheng Fang wrote:
> Thanks Jan and Dianne.
>
> So can we clarify that in the next version of JavaEE Platform Spec or
> Servlet Spec, to exclude HttpSessionBindingListener and
> HttpSessionActivationListener from accepting injection?
>
> I think this remains a spec issue, in addition to a doc issue.
Not sure I agree. :)
I think it's OK for the JavaEE (umbrella) spec to point to the component
specs for injection details, and I'm reading the Servlet spec in such a
way that any classes not listed as eligible for injection won't be injected.
I don't think we need to exclude any classes explicitly: any classes not
listed are excluded.
Also, I would not consider HttpSessionBindingListener or
HttpSessionActivationListener
to be "web application listeners", since they are not configured in web.xml.
Jan
>
> -cheng
>
> Jan.Luehe_at_Sun.COM wrote:
>
>> Dianne Jiao wrote:
>>
>>> Hi, Jan,
>>>
>>> Jan.Luehe_at_Sun.COM wrote:
>>>
>>>> Hi Cheng,
>>>>
>>>> Cheng Fang wrote:
>>>>
>>>>> JavaEE Platform Spec states injection is supported in all web
>>>>> application listeners, without listing all
>>>>> the listener classes. Various Sun docs [1] list the following 7
>>>>> listeners that support injection:
>>>>>
>>>>> javax.servlet.ServletContextListener
>>>>> javax.servlet.ServletContextAttributeListener
>>>>> javax.servlet.ServletRequestListener
>>>>> javax.servlet.ServletRequestAttributeListener
>>>>> javax.servlet.http.HttpSessionListener
>>>>> javax.servlet.http.HttpSessionAttributeListener
>>>>> javax.servlet.http.HttpSessionBindingListener
>>>>>
>>>>> Among the 7 listeners, HttpSessionBindingListener is different
>>>>> than the other 6. It is implemented by
>>>>> application types that are to be stored in session. An
>>>>> HttpSessionBindingListener type is usually created
>>>>> by application, not by the container. So it's hardly a
>>>>> container-managed component. Is injection really required by the
>>>>> spec, and supported in glassfish for HttpSessionBindingListener?
>>>>>
>>>>> Also missing from the above list is HttpSessionActivationListener,
>>>>> which is similar to
>>>>> HttpSessionBindingListener in that both interfaces are implemented
>>>>> by interested
>>>>> session attributes. I would image they should be treated the same
>>>>> for injection purpose.
>>>>>
>>>>> When I tried to inject resources into a HttpSessionBindingListener
>>>>> class, it was silently ignored. The
>>>>> same resources can be successfully injected into other 6 web event
>>>>> listeners.
>>>>>
>>>>> Did anyone get injections into HttpSessionBindingListener or
>>>>> HttpSessionActivationListener
>>>>> working?
>>>>
>>>>
>>>>
>>>>
>>>> Looks like a bug in the spec to me.
>>>>
>>>> I agree with you that neither HttpSessionBindingListener nor
>>>> HttpSessionActivationListener
>>>> instances are container-managed (they are instantiated by the app
>>>> and stored in the session),
>>>> and therefore, I don't see how they could be candidates for
>>>> injection by the container.
>>>>
>>>> I don't think there are any TCKs for this (I don't see how there
>>>> could be), but I'm cc'ing Dianne
>>>> to confirm.
>>>>
>>>>
>>> Just checked again, the Servlet spec does not require resource
>>> injection of both the following:
>>> - HttpSessionBindingListener
>>> - HttpSessionActivationListener. So there are no TCK tests for this.
>>
>>
>>
>> Great! Thanks for verifying, Dianne!
>>
>> I just checked the Servlet spec myself and confirmed that it does not
>> list HttpSessionBindingListener or HttpSessionActivationListener as
>> eligible for injection. So we're safe on the spec side.
>>
>> So the confusion is caused by the tutorials/articles only, which is
>> easier
>> to fix.
>>
>>
>> Jan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>