Rajiv Mordani wrote:
>
>
> 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.
Actually looking at the API we already have a getInitParameter (which
has been there since before 3.0) which is for the context param. So
given that I think to be consistent we should keep the name as
addInitParameter.
- Rajiv
>
> - 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net