Actually, after thinking this over and reading OSGI's war deployment strategy, I get it :-) ...
We should not remove the ability to set a default Servlet ahead of the service chain, we would be stifling anyone that wishes to extend grizzly in some unforeseen way (a Dynamic Servlet Bridge for example).
soooo I retract my previous comments on this issue, standards are good once you understand them :)
--Richard
----- Original Message ----
From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
To: dev_at_grizzly.dev.java.net
Sent: Wednesday, April 22, 2009 4:54:37 PM
Subject: Re: grizzly context loading
Richard Corsale wrote:
> I haven't written a web app with servlets in about a year and that was JSF on GlassFish :-) but I seem to remember that I used to define a servlet for <domain:port>/ as well as <domain:port>/<OtherValidContext> and that worked. I know how to get around this if its not possible due to the Spec... but if that is part of the spec, wtf were they thinking? :)
GlassFish has a special way (like Tomcat) to handle the "/". Out-of-the-box it doesn't work (probably the same issue as right now). I think we need to define how we want tot behave (maybe we should just reject "/" like GF is doing by default).
>
> --Richard
> ------------------------------------------------------------------------
> *From:* Hubert Iwaniuk <neotyk_at_kungfoo.pl>
> *To:* dev_at_grizzly.dev.java.net
> *Sent:* Wednesday, April 22, 2009 4:32:35 PM
> *Subject:* Re: grizzly context loading
>
> Hi Richard,
>
> Are you talking about situation where you have multiple servlets registered under different contexts out of witch one is "/"? And only one registered under "/" is called for all requests?
>
> If yes this kind of setup is only supported for now in OSGi Http Service, and Mapper just managed to bite us again.
> Don't really know what spec says about this kind of setup, since "most" servlet containers will behave like you described.
> Depending on spec we could try porting osgi mapper to GWS, problem here would be probably to keep up with current performance.
Actually we need to try as the concurrent class has been optimized a lot since the original Mapper was written. I think we should write a little micro benchmark to test both and then decide. For sure I would like to use the osgi mapper (much more easy to debug!).
Thanks!
-- Jeanfrancois
>
> HTH,
> Hubert
>
>
> On Wed, Apr 22, 2009 at 10:11 PM, Richard Corsale <igf1_at_yahoo.com <mailto:igf1_at_yahoo.com>> wrote:
>
>
> ok :) this is another one that I just noticed. if I define a servlet
> context of"/" all queries , even ones addressed to other contexts
> that are valid are calling the one loaded at "/" is this normal? I'm
> using 1.9.9
>
>
>
>
> ----- Original Message ----
> From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
> To: dev_at_grizzly.dev.java.net <mailto:dev_at_grizzly.dev.java.net>
> Cc: users_at_grizzly.dev.java.net <mailto:users_at_grizzly.dev.java.net>
> Sent: Tuesday, April 21, 2009 5:56:17 PM
> Subject: Re: Releasing Grizzly 2.0 M1 tomorrow
>
> And the History of Grizzly:
>
> http://weblogs.java.net/blog/jfarcand/archive/2009/04/grizzly_200m1_r.html
>
> Make noise!!!
>
> -- Jeanfrancois
>
> charlie hunt wrote:
> > Cool!
> >
> > I'm just about ready to start hacking away with it. :-)
> >
> > charlie ...
> >
> > Oleksiy Stashok wrote:
> > > http://blogs.sun.com/oleksiys/entry/grizzly_2_0_m1_release
> >>
> >> to be continued...
> >>
> >> On Apr 21, 2009, at 21:49 , Jeanfrancois Arcand wrote:
> >>
> >>> Salut,
> >>>
> >>> uploading the release now (may take time). Time to start the blog
> >>> machine!!
> >>>
> >>> -- Jeanfrancois
> >>>
> >>> Oleksiy Stashok wrote:
> >>>> Hi,
> >>>> tomorrow we're going to make first Grizzly 2.0 milestone release,
> >>>> which will contain framework, rcm, http and servlet modules.
> >>>> Please let us know, if you have any particullar questions or
> comments.
> >>>> Thanks.
> >>>> WBR,
> >>>> Alexey.
> >>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> >>>> For additional commands, e-mail:
> users-help_at_grizzly.dev.java.net <mailto:users-help_at_grizzly.dev.java.net>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> >>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
> >>>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: dev-help_at_grizzly.dev.java.net