dev@glassfish.java.net

Re: Webtier APIs for GlassFish Embedded

From: Jan Luehe <Jan.Luehe_at_Sun.COM>
Date: Mon, 09 Feb 2009 15:53:04 -0800

Hi Jeanfrancois,

On 02/09/09 15:34, Jeanfrancois Arcand wrote:
> Salut,
>
> Jan Luehe wrote:
>> On 02/06/09 09:25, Jerome Dochez wrote:
>>> I could not resist looking at the APIs and it seems very similar to
>>> the XML inspired way of organization the metadata, wouldn't be more
>>> java centric to propose APIs like :
>>>
>>> Interface Contect {
>>>
>>> public Servlet addServlet(String name, Class<? extends
>>> javax.servlet.Servlet> servletClass);
>>
>> Would it make more sense to pass a Servlet instance, rather
>> than a Servlet Class object?
>
> +1.
>
>>
>> This would give developers more flexibility in how the Servlet is
>> constructed, rather than limiting them to a zero-arg constructor
>> (which would be the case when passing in a Class object).
>>
>> To address Jeanfrancois' comment about missing listener support, i
>> think we
>> should define methods on Context for adding each of the following
>> listener types (which may already be declared in web.xml):
>>
>> javax.servlet.ServletContextAttributeListener
>> javax.servlet.ServletRequestAttributeListener
>> javax.servlet.ServletRequestListener
>> javax.servlet.ServletContextListener
>> javax.servlet.http.HttpSessionAttributeListener
>> javax.servlet.http.HttpSessionListener
>>
>> Again, I suggest we pass listener instances, instead of the underlying
>> Class objects.
>
> The issue here is they don't share any base class (do they..too lazy
> to look at :-)).

They all extend the java.util.EventListener marker interface, which
means we could
define a single method that would cover them all, and have this method
throw an
IllegalArgumentException if the passed in EventListener was not an
instance of any
of the above interfaces.

> That's why (at least in Grizzly) we support passing the String, e.g.
> the fully qualified class name. That way the API doesn't have all the
> get/set for every listener.
>

Agreed, but in this case, we would again be limited to a zero-arg
constructor.

Maybe exposing a single Context#addListener(EventListener listener),
which would throw
an IllegalArgumentException under the condition described above, would
be best?

Thanks,

Jan

> A+
>
> -- Jeanfrancois
>
>
>>
>>
>> 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
>