On 02/06/09 13:55, 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.
OK, good!
>
> 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.
There are 2 types of init params: context and servlet init params.
Currently, context init params are set on ServletContext, and servlet
init params are set on ServletRegistration. There is no duplication.
I like the idea of defining the addMapping methods on the XXXRegistration
objects (rather than on ServletContext): For a just registered Servlet
or Filter,
the caller holds the Registration object, and can add mappings to it.
For an already registered Servlet or Filter, it can retrieve the
Registration object
via the new ServletContext#get[Servlet|Filter]Registration(String name)
method
and add the mappings to it.
There is one difference to the curent
ServletContext#add[Servlet|Filter]Mapping,
though, which does not require that the Servlet or Filter whose mappings are
being added have already been registered. Not sure about the motivation
for this.
Moving the addMapping methods to the XXXRegistration objects seems cleaner,
though. We'll propose this to the EG.
>
>>
>>
>> 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
I agree that passing Class objects would be very necessary in the
Embedded case,
given what we currently have.
The javadocs for ServletContext#add[Servlet|Filter] in Servlet 3.0
currently mention this:
The specified <tt>className</tt> will be loaded using the
classloader associated with the application represented by this
ServletContext.
This classloader is the same classloader that will be set as the context
classloader
during a servlet invocation. It is the same classloader that is
established from
WEB-INF/lib and WEB-INF/classes during deployment.
Granted that there is not going to be any "deployment" for most of the
Embedded
use cases, we should consider overloading the Context creation method in
Embedded
to take a classloader, and require that this classloader will be set as
the context
classloader during Servlet and Filter invocations, and will also be used
to load
any resources (including any Servlet and Filter class names passed to
add[Servlet|Filter]).
But I still think passing Class objects (instead of, or in addition to
class names) to
add[Servlet|Filter] would be useful.
>>
>>
>>> // 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.
Yes. :)
>>
>>
>>>
>>> }
>>>
>>> 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.
No, I think we're in sync.
Thanks,
Jan
>
> 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
>