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.