And what about EJB? In that context, blocking calls are forbidden. A
synchronous http GET will block.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 28. Juni 2012 15:45
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Server sided use
> of JAX-RS client API: Valid in which server sided components?
>
>
> On Jun 27, 2012, at 10:43 PM, Bill Burke wrote:
>
> > Whether or not you are allowed to open a socket is irrelevant.
> Servlets have always been allowed to make remote EJB- RMI, IIOP, or
> SOAP invocations. I don't see how an HTTP client API is any different.
> JAX-RS *IS* a Java EE specification. And since it is a Java EE
> specification the application server can control and manage client
> HTTP connections in a predicable manner just as it does for EJB
> clients, jms clients, jdbc clients, ...
>
> +1
>
> Marek
>
> >
> > On 6/27/12 1:44 PM, Markus KARG wrote:
> >> Well, in fact nobody says that it should be forbidden. The question
> >> was whether the spec must explicitly allow it, as opening sockets IS
> >> explicitly forbidden by the Java EE spec already.
> >>
> >>> -----Original Message-----
> >>> From: Bill Burke [mailto:bburke_at_redhat.com]
> >>> Sent: Dienstag, 26. Juni 2012 23:57
> >>> To: jsr339-experts_at_jax-rs-spec.java.net
> >>> Subject: [jsr339-experts] Re: Server sided use of JAX-RS client
> API:
> >>> Valid in which server sided components?
> >>>
> >>>
> >>>
> >>> On 6/26/12 5:41 PM, Jan Algermissen wrote:
> >>>> Hi Markus,
> >>>>
> >>>> On Jun 16, 2012, at 3:50 PM, Markus KARG wrote:
> >>>>
> >>>>> Experts,
> >>>>>
> >>>>> some weeks ago we discussed server sided use of the new JAX-RS
> >>> client API, e. g. to pull information from an external RESTful web
> >>> service.
> >>>>>
> >>>>> As I remember, at least for EJBs (SBs, MDBs) it is forbidden to
> >>>>> use
> >>> blocking operations, threading operations, files API and sockets
> API.
> >>> All this for the sake of stability and security.
> >>>>
> >>>> Yes, this is a good question because it is too easy to assume you
> >>> could just chunk up a larger system into HTTP services and fire
> >>> calls between the services all over the place.
> >>>>
> >>>> In my opinion, serving an HTTP request must not involve an
> upstream
> >>> HTTP call unless in the case of relatively infrequent requests
> (e.g.
> >>> order submission) or unless a local cache is very well known to
> have
> >>> a sufficient hit ration.
> >>>>
> >>>> Turning every user request into a (cascade of) upstream HTTP
> >>>> requests
> >>> is not really what we want. This statement is not as ridiculous as
> >>> it sounds because software architects and consulting firms come up
> with
> >>> such designs all over the place :-) ... or, well, rather :-(
> >>>>
> >>>> I am not sure how a container could 'enforce' anything here, but
> >>>> IMHO
> >>> HTTP-servers-as-clients is as much a container issue as
> transactions
> >>> are.
> >>>>
> >>>> Ideas?
> >>>>
> >>>
> >>> So you're saying using the client API within a server should be
> >>> forbidden? We're talking about distributed systems here, not
> >>> one-off Web UIs.
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>>
> >>
> >>
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> >