Hi! I've tried to look at JSR-299 CDI, JSR-318 EJB and JSR-109 Enterprise Web Services (the ones we need to rely on)...
I try to understand how I can combine EJB/CDI (is possible) with a JAX-WS WebService, a @WebService annotated class... We are in production currently on JavaEE 6. Questions/assumptions: - JSR-109 say that a JAX-WS WebService can also be a @Stateless or @Singleton EJB. The choice here would be if I need thread-safety or not. Correct? - I did not see that I could annotated a Web Service with @Stateful? My idea here was to create a @Stateful @SessionScoped/@RequesScoped @WebService but I guess that is outside the specs and possible outside all appserver implementations, correct? - I assume that an alternative would be to Inject and use e.g. @SessionScoped bean in the webservice/ejb.... however I want to explore my possibilities. - Reading JSR-109 -5.3.2.4.2 I see the following: "A JAX-WS Service Endpoint can be single or multi-threaded." and "A container may use any bean instance to service a request.". Does this mean that its up to the JAX-WS implementation to pool instance or not and up to the implementation if it chooses to let the same instance serve multiple requests concurrently? I talking about the case where I only annotate using @WebService, the web service is not an EJB in this case. - JSR-109 talks about implementing "SingleThreadModel" and that its deprecated, are there any options to achieve the same without using a @Stateless @WebService? - When using JavaEE7 I can annotate any POJO with @Transactional and for some use-cases I not need an EJB. Is there in JavaEE7 also some options to using @Stateless or @Singleton @WebService? Maybe using CDI scopes... however I not see anything about this in the CDI spec? Thanks Lars-Fredrik -- Med vänlig hälsning / Best regards Lars-Fredrik Smedberg STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the address(es) and may contain confidential or privileged information. If you are not the intended recipient, please notify Lars-Fredrik Smedberg immediately at [email protected], and destroy all copies of this message and any attachments.
