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.
>
>
> 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.
>
>
> 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
>
>
>> // 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.
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
>