The REST service beans are usually scoped RequestScoped. Mixing REST and JSF is really
useful, just like it works with Remoting and JSF. I use the latter quite a lot when 1) JSF
component doesn't do what I want it to do, and 2) I need to send some UI state info
back to the server; like what tab in a tabview is selected etc. What would be the
appropriate way to handle this? Since REST is REST, we don't want to mess up the
session store and have the back-end operate incorrectly.
However, would it be possible to demote the conversion scoped beans to request scoped
beans? From a programmatic point of view, it all boils down to being able to interact with
ConversationScoped beans from a RequestScoped REST bean. If not, a more comprehensive
implementation/architecture must take place. In a mixed environment (JSF/REST), you're
likely to delegate business logic to Dependent scoped beans, and proxy two delegates 1)
into a ConversationScoped JSF bean variant, and/or 2) RequestScoped REST bean variant.
Hence, you'd end up with one dependent scoped impl bean, with two scoped variants.
When the object graph expands, it'll be complex to maintain. This has a clear impact.
Btw, how's this done in Remoting to back JSF?
On Jan 17, 2012, at 12:20 AM, Jason Porter wrote:
I agree that Conversations should be supported for other connections
besides JSF, however, with REST or any web service call there is a problem about tying a
request to a session, you'd either have to have the client's support sending
cookies in their requests or create store like a session yourself. If you go with the
latter approach then it should be fairly easy to (well, as easy as creating passivation
capable scopes is) to create a scope that would work with this cache / store.
If it is a regression, please create a JIRA with attached Arquillian test(s).
On Mon, Jan 16, 2012 at 16:03, Ove Ranheim <oranheim(a)gmail.com> wrote:
The below test case impl doesn't track any sessions and the conversation only
survives per method call. So the lifecycle to it isn't proper :) It's nothing more
than a workaround.
It'd be better to have support for ConversationScope in Seam REST. Maybe I'm
doing something wrong here, but my code case is as simple as:
1) PU produces a ConversationScoped entity manager in Seam Persistence
2) The REST service makes a call to a Stateful ConversationScoped bean, in which invokes
the ConversationScoped PU
3) REST service beans are used to accommodate natural REST crud on top of a JSF page.
That's all there are to it. The deployment includes solder, faces, international,
persistence, transaction, security, conversation-{weld and spi} and rest. I'm
investigating ways to make a hybrid model that uses JSF and REST. So far so good, except
for the aforementioned.
On Jan 16, 2012, at 11:50 PM, Jason Porter wrote:
> Since you're using REST, how are you tracking the session? If don't have some
way of doing that you'll end up possibly creating a new session / conversation with
each request because it isn't tied to the same session.
>
> On Mon, Jan 16, 2012 at 15:35, Ove Ranheim <oranheim(a)gmail.com> wrote:
> Jason,
>
> Thanks for your feedback and maybe this is a regression. I made an interceptor to
make my test code work, but I'm not sure what implication it'll have in a
production environment.
>
> Ove
>
> @InterceptorBinding
> @Target({ TYPE, METHOD })
> @Retention(RetentionPolicy.RUNTIME)
> public @interface ConversationAware {
> }
>
> @ConversationAware
> @Interceptor
> public class ConversationHandler implements Serializable {
>
> private static final long serialVersionUID = -6414852756277060457L;
>
> private BoundConversationContext ctx;
> private BoundRequest request;
>
> private void createBoundConversationRequest() {
> request = new MutableBoundRequest(new HashMap<String, Object>(), new
HashMap<String, Object>());
> }
>
> private void selectBoundConversationContext() {
> ctx =
Container.instance().deploymentManager().instance().select(BoundConversationContext.class).get();
> ctx.associate(request);
> ctx.activate();
> }
>
> private void cleanupBoundConversation() {
> if (ctx != null && ctx.isActive()) {
> ctx.deactivate();
> ctx.dissociate(request);
> }
> }
>
> @AroundInvoke
> public Object handle(InvocationContext ctx) throws Exception {
> if (ctx.getMethod().isAnnotationPresent( ConversationAware.class )) {
> createBoundConversationRequest();
> try {
> selectBoundConversationContext();
> return ctx.proceed();
> } finally {
> cleanupBoundConversation();
> }
> }
> return null;
> }
> }
>
> @GET
> @Path("/{id:[0-9][0-9]*}")
> @Produces(MediaType.APPLICATION_JSON)
> @ConversationAware
> public Pojo lookupPojoById(@PathParam("id") Long id) {
> // do something
> }
>
>
> On Jan 16, 2012, at 9:45 PM, Jason Porter wrote:
>
>> I'd have to go through the seam conversation code as it is not documented.
But I don't think the interceptor will work as in REST there isn't really a
session to tie the conversation to.
>>
>> Sent from my iPhone
>>
>> On Jan 16, 2012, at 13:35, Ove Ranheim <oranheim(a)gmail.com> wrote:
>>
>>> I have configured
class>org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptor</class>
in WEB-INF/beans.xml and seam-faces is used. In fact I use both JSF and REST.
>>>
>>> Anything else that needs to be wired up?
>>>
>>> On Jan 16, 2012, at 9:14 PM, Jason Porter wrote:
>>>
>>>> If you're using Seam Conversation and starting the conversation it
will work. Out of the box, conversations don't work outside JSF.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 16, 2012, at 13:04, Ove Ranheim <oranheim(a)gmail.com> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I'm getting a "WELD-001303 No active contexts for scope type
javax.enterprise.context.ConversationScoped" when making a call to a REST service
that invokes a ConversationScoped bean.
>>>>>
>>>>> Did I miss a configuration setting, or isn't ConversationScoped
supported?
>>>>>
>>>>> Ove
>>>>>
>>>>> javax.ejb.EJBTransactionRolledbackException: WELD-001303 No active
contexts for scope type javax.enterprise.context.ConversationScoped
>>>>>
org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:133)
>>>>>
org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:196)
>>>>>
org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:286)
>>>>>
org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:182)
>>>>>
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
>>>>>
org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
>>>>>
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
>>>>>
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>>>
org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
>>>>>
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
>>>>>
org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
>>>>>
org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
>>>>>
com.parts.apartment.management.ApartmentService$$$view2.listApartmentUnits(Unknown
Source)
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> java.lang.reflect.Method.invoke(Method.java:597)
>>>>>
org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
>>>>>
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
>>>>>
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
>>>>>
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
>>>>>
org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:125)
>>>>>
org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62)
>>>>>
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
>>>>>
com.parts.apartment.management.ApartmentService$Proxy$_$$_Weld$Proxy$.listApartmentUnits(ApartmentService$Proxy$_$$_Weld$Proxy$.java)
>>>>>
com.parts.apartment.management.ApartmentService$Proxy$_$$_WeldClientProxy.listApartmentUnits(ApartmentService$Proxy$_$$_WeldClientProxy.java)
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> java.lang.reflect.Method.invoke(Method.java:597)
>>>>>
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
>>>>>
org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255)
>>>>>
org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220)
>>>>>
org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209)
>>>>>
org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519)
>>>>>
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496)
>>>>>
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119)
>>>>>
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>>>>>
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>>>>>
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>>>>>
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
>>>>>
org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
>>>>>
org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
>>>>> com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:126)
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> seam-dev mailing list
>>>>> seam-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>
>
>
>
> --
> Jason Porter
>
http://lightguard-jp.blogspot.com
>
http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at:
keyserver.net,
pgp.mit.edu
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at:
keyserver.net,
pgp.mit.edu