Marek,
I checked my archive and now can remember better about the context. I have
to correct myself in details, after reading Chapter 21.2.2 of EJB 3.1 spec:
It is true that an EJB must not use File API, Threading API, etc. and lots
more (see EJB 3.1 Specification Chapter 21.2.2 for a complete list and
justification of the rules; also there is an old but still valid explanation
of the rules found here:
http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html). But I was
wrong about client sockets in particular: An EJB is allowed to open client
sockets, but it must not change the socket factory.
So for the JAX-RS spec it might not be of direct interest, but for the RI it
will be. As Jersey is intended to get included in GF4, you maybe like to
check the actual client implementation for use of Threading API or
replacement of socket factory, which Jersey possibly does (e. g. to
implement asynchronous invocations, handling of non-http method tokens,
etc.). Also, it might be of indirect interest for the JAX-RS spec, as the
sense of the spec is not only to standardize a standalone JAX-RS
implementation, but also to standardize an implementation that can run
inside of Java EE (the spec contains a chapter on this), and in that context
the JAX-RS implementator must know about this special rules. I mean, if
someone will replace Jersey by another JAX-RS implementation inside of GF4,
that other implementor must know what its engine must not do then (it makes
no difference if an EJB calls an invalid API, or if an EJB calls a JAX-RS
implementation that calls an invalid API).
I think it would be a good idea to ask the EJB spec leads of Java EE 7 about
the particular implications induced by use of JAX-RS client API within EJB.
I am confident they can deliver a text proposal, what the JAX-RS spec should
declare about this special use case.
Regards
Markus
> -----Original Message-----
> From: Markus KARG [mailto:markus_at_headcrashing.eu]
> Sent: Donnerstag, 28. Juni 2012 23:21
> 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?
>
> Marek,
>
> I will check my mail archive, as I can remember that Bill Shannon last
> year sent me a link with to the exact part of the spec. The idea behind
> it was that a EJB component must interfere with the container's
> responsibility on resource and security government. So yes, typically
> it is talking about direct use. But on the otherhand that means, that
> possibly the implementation must provide a SPI to forward blocking and
> threading responsibility into the container. So once I found the mail,
> I will forward it.
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> > Sent: Donnerstag, 28. Juni 2012 23:08
> > 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?
> >
> > Hi Markus,
> >
> > Can you please point me to the section(s) of Java EE spec you are
> > talking about? I may pass your issue to Java EE architects if needed.
> >
> > My hunch is that the intention might have been to forbid a direct
> > usage. But I cannot imagine that one would want to prevent EE users
> > from indirect use of threads, sockets, files etc. It would mean users
> > could not connect to other components via RMI, IIOP, SOAP, JMS, SMTP
> > or HTTP (e.g. servlet forwarding). Also it would be impossible to
> > implement things like business process orchestration solutions on top
> > of Java EE container.
> >
> > All that makes me think that there this issue must be caused by some
> > misunderstanding.
> >
> > Marek
> >
> > On Jun 28, 2012, at 10:20 PM, Markus KARG wrote:
> >
> > > Well, Java EE IS rather clear (no blocking, no sockets, no files,
> no
> > > threads), that's why I started this thread. I think that there
> > > should be clear words in the JAX-RS spec about usage of the client
> > > inside of EJB (which methods are not allowed in that context).
> > >
> > >> -----Original Message-----
> > >> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> > >> Sent: Donnerstag, 28. Juni 2012 10:44
> > >> 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 27/06/12 18:46, Markus KARG wrote:
> > >>>>> I cannot see a sensible solution at the moment.
> > >>>>
> > >>>> Solution for what ? I think supporting the client invocations in
> > >>>> the context of the service request is simply to do with making a
> > >>>> tool
> > >> for
> > >>>> the job available when it is actually needed.
> > >>>>
> > >>>> Cheers, Sergey
> > >>>
> > >>> Solution for the fact that Java EE components must not open
> > sockets.
> > >>>
> > >> But the JAX-RS specification needs to be able to act as a stand-
> > alone
> > >> specification. Perhaps the spec EE profile might say something
> else
> > >> in this regard
> > >>
> > >> Sergey
> > >
>