I understand. To sum up: Servlet filters will work even with JAX-RS
implementation which are not basing on Servlets, since Servlet Filters are
prefixed to an application, which includes JAX-RS in common and is not
limited to Servlets. Right? That's great. :-)
Regards
Markus
> -----Original Message-----
> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Sent: Montag, 19. Januar 2009 02:31
> To: dev_at_jersey.dev.java.net
> Subject: Re: [Jersey][WebDAV] Different handling of lax=true
>
> On Jan 16, 2009, at 5:58 PM, Markus KARG wrote:
> >
> > yes, certainly you can bundle explicitly jersey with the app and
> > distributing some more JARs and kilobytes together with your
> > originally
> > small application, resulting in more complex deployment and
> footprint.
>
> If you want to use non-standard filters like Jersey supports then you
> either need to deploy in an app server that directly incorporates
> Jersey or bundle Jersey with your web app.
>
> If, however, you are happy with Servlet filters then I think you are
> OK. The JAX-RS specification only defines packaging of JAX-RS
> applications as web apps so filters included with the web app should
> be executed prior to dispatching the request just as they are for
> anything else included in the web app and accessible via a URI.
>
> Its possible that in future some app server might support some other
> way of deploying a JAX-RS app but presumably that would be using
> something other than a .war to do it so you'd have to even package
> your application differently to make use of that...
>
> Marc.
>
> > But I
> > see Java EE as the chance to strip a lot of such third party stuff
> > in favour
> > of one standardized platform that I as an ISV can rely upon to be
> > there and
> > work the same everywhere. For me, the idea of Java EE is to have a
> > powerful
> > platform which removes the need for third party stuff. If we now
> > start again
> > bundling things, then this sense starts to fade. In the end, I can
> > bundle
> > all of the JARs described in Java EE manually, so no more Java EE is
> > needed
> > at all anymore. So to strengthen the platform, I see a strong need
> > for a
> > phrase like one of the two I proposed today (either enforce Servlet-
> > Base to
> > allow Servlet-Filtering or enforce a to-be-defined JAX-RS-Filtering).
> > Everything else will look like JAX-RS beeing just an addon bundled
> > with
> > GlassFish by incident and Jersey beeing just another JAR that I can
> > bundle
> > with anything, instead of being an integral part of the Java EE
> > Reference
> > Implementation. For my understanding as a long time Java EE
> > developer and
> > fresh Jersey committer, I want Jersey to be not just a bundled
> > addon, but I
> > want JAX-RS to be a real part of the Java EE platform, that fits
> > together
> > with the other parts in a smart way.
> >
> > Regards
> > Markus
> >
> >> -----Original Message-----
> >> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> >> Sent: Freitag, 16. Januar 2009 22:45
> >> To: dev_at_jersey.dev.java.net
> >> Subject: Re: [Jersey][WebDAV] Different handling of lax=true
> >>
> >> Jersey supports deployment as a servlet so you can bundle Jersey
> with
> >> any web app and it should run on any servlet container.
> >>
> >> Marc.
> >>
> >>
> >> On Jan 16, 2009, at 2:12 PM, Markus KARG wrote:
> >>
> >>> For ISVs like us this is a real problem: We need to ensure that our
> >>> applications are working on any implementation of Java EE 6. So
> both
> >>> solutions are not possible:
> >>>
> >>> * Jersey-Filters will not work since the customer's server possibly
> >>> is not
> >>> using Jersey at all but a different JAX-RS provider.
> >>>
> >>> * Servlet-Filters will not work since the customer's server
> possibly
> >>> is
> >>> using a JAX-RS provider which is not based on Servlets.
> >>>
> >>> So from the theory, you solution sounds great. But in practice, we
> >>> still
> >>> have no solution. That is bad. So I really appeal to change the
> >>> JAX-
> >>> RS
> >>> specification that either JAX-RS must be prefixable by Servlet-
> >>> Filters or
> >>> contains another pluggable filter technology to be implemented by
> >>> any JAX-RS
> >>> implementation. I do not see that it would be a big hurdle to
> change
> >>> the
> >>> spec and fix this, but it would be a huge benefit for ISVs (I know,
> >>> must
> >>> users are not ISVs and do not have this kind of problems).
> >>>
> >>> Thanks!
> >>> Markus
> >>>
> >>>> -----Original Message-----
> >>>> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> >>>> Sent: Freitag, 16. Januar 2009 14:56
> >>>> To: dev_at_jersey.dev.java.net
> >>>> Subject: Re: [Jersey][WebDAV] Different handling of lax=true
> >>>>
> >>>>
> >>>> On Jan 15, 2009, at 8:44 PM, Markus KARG wrote:
> >>>>
> >>>>> Silly me. ;-)
> >>>>>
> >>>>> BTW, is that guaranteed to work together in all Java EE 6
> servers?
> >> I
> >>>>> mean,
> >>>>> AFAIK an implementation of JAX-RS is free to not base it on
> >>>>> Servlets, so
> >>>>> maybe there could be a Java EE 6 server that is not able to
> >>>>> apply a
> >>>>> Servlet
> >>>>> filter in front of JAX-RS, can that be the case? That would be
> >>>>> bad.
> >>>>>
> >>>>
> >>>> Tis true. JAX-RS does not mandate that Servlet be used but does
> >> state
> >>>> what is required if servlet is used. Note that we have not
> >>>> completed
> >>>> the specification of JAX-RS for EE 6, but i don't recall we were
> >>>> going
> >>>> to mandate that EE 6 use Servlet.
> >>>>
> >>>> Paul.
> >>>>
> >>>>
> >>>>> Thanks
> >>>>> Markus
> >>>>>
> >>>>>>> Well... Filters sounds good but actually (maybe I am blind) I
> >> have
> >>>>>>> not seen
> >>>>>>> something like that in the JAX-RS specification...?
> >>>>>> You sight is fine :-) There is nothing in the JAX-RS
> >> specification.
> >>>>>> You can use servlet filters or Jersey specific filters.
> >>>>>
> >>>>> Regards
> >>>>> Markus
> >>>>>
> >>>>>
> >>>>> -----------------------------------------------------------------
> --
> >> --
> >>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >>>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >>>>>
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------
> --
> >> -
> >>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >>>
> >>>
> >>> -------------------------------------------------------------------
> --
> >>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >>>
> >>
> >> ---
> >> Marc Hadley <marc.hadley at sun.com>
> >> CTO Office, Sun Microsystems.
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: dev-help_at_jersey.dev.java.net
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net