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
>