Jerome Dochez wrote:
>
> On Feb 6, 2009, at 12:40 PM, Jan Luehe wrote:
>
>> [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.
>
> ok so my Servlet and Filter names confused you, you can call them
> whatever you want like ServletRegistration or FilterRegistration, by
> no means I wanted to override the javax.servlet.Servlet interface.
>
> so this seems to be the same solution which I will verify once the
> javadocs are updated.
Yes I will provide the updated javadocs - or to see the javadocs for
servlet 3.0 from the public review (it does not have some of the changes
we have talked about here of course).
>>
>>
>> So you can already do:
>>
>> context.addServlet("foo", "Foo").setInitParameter("somename",
>> "somevalue")
> ok great but then why having addInitParameter and addMappings methods
> on the context. That seems like a very unintuitive duplication.
Maybe we should rename the addInitParameter on the context to
addContextParameter() to make it more clear. The initparam for the
servlet is added via the ServletRegistration object.
- Rajiv
>
>>
>>
>> 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.
> that's fine. again naming confusion from my poor example naming.
>>
>>
>> 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.
> of course not.
>>
>>
>> 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.
> so this is very necessary, or you need to rely on ContextClassLoader
> to be set which is quite a side effect imo
Not only from the class loader perspective but also from the type safety
of the code I think it is a good idea.
>>
>>
>>> // 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?
> following on the naming confusion, here you just return
> ServletRegistration instances.
>>
>>
>>>
>>> }
>>>
>>> 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.
> replace Servlet with ServletRegistration, same for filters and let me
> know if you still see issues.
:).
- Rajiv
>
> Jerome
>
>>
>>
>> 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
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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