[Reposting to dev_at_glassfish.dev.java.net]
Hi Jerome,
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);
> public Filter addFilter(String name, Class<?> filterClass);
The ServletContext#addServlet and ServletContext#addFilter methods that
we've added
in Servlet 3.0 already support the kind of chaining you want, but
instead of returning Servlet or Filter
instances, they return javax.servlet.ServletRegistration and
javax.servlet.FilterRegistration
objects, respectively, which allow futher configuration, e.g., with init
params.
The XXXRegistration classes were missing from Rajiv's javadocs.
So you can already do:
context.addServlet("foo", "Foo").setInitParameter("somename", "somevalue")
We added support for servlet and filter configuration to the
ServletRegistration
and FilterRegistration objects, instead of directly on the Servlet or
Filter interfaces,
for backward compatibility reasons.
I don't think we should define new Servlet and Filter interfaces
specifically for
Embedded. Instead, we should leverage the standard interfaces, so that
existing
Servlet and Filter impls may be reused in the Embedded usecase.
Passing Class instead of String objects to addServlet and addFilter
seems like a good
idea, though. We'll pass this on to the EG and see what they think.
>
> // some normal accessors should also be provided
> public Collection<Servlet> getServlets();
> public Servlet getServlet(String name);
These seem like good ideas, but their semantics would have to be defined
carefully.
By default, servlets are instantiated lazily (when first requested), unless
they've been marked as <load-on-startup>.
What should getServlet return if the named servlet has not yet been
instantiated?
>
> }
>
> interface Servlet {
>
> public Servlet addMapping(String mapping);
> public Servlet addMappings(String... mappings);
> public Servlet addInitParam(String initParam);
> public Servlet start();
> public Servlet stop();
> }
>
> interface Filter {
> /// similar to servlet but for filters
> }
>
> then you can write code like :
>
> context.addServlet("foo",
> Foo.class).addMapping("/foo/bar").addInitParam("something").start();
Chaining is already supported (see above), with the exception of addMapping.
There are several reasons why addMapping was not added to the
(javax.servlet.)Servlet interface:
1. Preserve backward compatibility
2. We wanted to support the use case where a mapping needs to be added to an
already declared (e.g., in a web.xml fragment) or already added
servlet, which
is why ServletContext#addMapping references the servlet by name.
Same is true for Filter mappings.
Thanks,
Jan
>
> Jerome
>
> On Feb 6, 2009, at 8:37 AM, Rajiv Mordani wrote:
>
>> Jeanfrancois,
>> I know I am on grizzly tech and I saw some of that. This is a
>> starting point with just the basic API that if everyone agrees upon
>> then we can build on top of. Once I get it to compile (some maven
>> repo issue right now where I am getting a stale version of the api
>> jar for some reason) I will send this out to the dev_at_embedded mailing
>> list. In the mean time I thought I would at least share this with
>> Jennifer and Byron so that they can start seeing what we are looking
>> to provide.
>>
>> As for the addValve to a virtual server - good point. We probably
>> need that.
>> As for exposing the session tracking stuff, the motivation is the
>> same as in servlet 3.0 :). These APIs are already in Servlet 3.0
>> today :) and we are having to backport it since the prelude branch is
>> based on javaee 5 which I am not too happy about.
>> unregister is for removing a context.
>>
>> - Rajiv
>>
>> Jeanfrancois Arcand wrote:
>>> Salut,
>>>
>>> [ adding Paul/Eduardo/Jerome as we are having parallel discussions
>>> :-) ]
>>>
>>> Question for everyone:
>>>
>>> Can we have the discussion on users_at_glassfish? There is not a lot of
>>> peoples on the embed list.
>>>
>>> Rajiv Mordani wrote:
>>>> Hi Jennifer,
>>>> You can see the first cut at the javadocs at
>>>>
>>>> http://rator.sfbay/mode/Workspaces/v3/v3/web/web-core/target/site/apidocs/org/glassfish/web/embed/package-summary.html
>>>>
>>>>
>>>> I am not yet sending this to the dev_at_embedded as I am running into
>>>> issues with compiling hte v3 workspace. Take a look and we can talk
>>>> more about this in a meeting if you prefer.
>>>
>>> There is some features missing on Context:
>>>
>>> + Listener(s) can't be added right now. Same some Context/init params
>>> + Do we really needs to expose the Session tracking stuff? What is
>>> the use case for that? The less we expose the easier it will be IMO.
>>> + If we expose Valve, we must allow adding Valve to VirtualServer as
>>> well. Also we must allow the user to manipulate the Valves list,
>>> e.g. where to inject the Valve inside the Pipeline. Also I'm +0 to
>>> expose Valve as I would think using a Filter can almost do exactly
>>> what does now.
>>> + What is the proposed use of unregister()?
>>>
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>> Kohsuke I haven't made some of the changes we talked about today as
>>>> yet.
>>>>
>>>> - Rajiv
>>>>
>>>> Jennifer Chou wrote:
>>>>> Hi Rajiv,
>>>>>
>>>>> Just checking in...how are the webtier APIs? When it's ready can
>>>>> you send them out for review to
>>>>>
>>>>> dev_at_embedded-glassfish.dev.java.net
>>>>>
>>>>> We'd like to review before our asarch API review on 2/10.
>>>>>
>>>>> Thanks,
>>>>> Jennifer
>