Sent from my iPhone

On Jan 16, 2012, at 18:46, George Gastaldi <gegastaldi@gmail.com> wrote:

One solution is to have a backend store for the conversation scoped beans (Infinispan maybe ?) and never mess with the session. Probably the conversation Ids should be unique as well, so you must generate them uniquely.

My thoughts. 

Since you are using JSF, why not queueing events using the ajax support  in JSF 2.0+? Adding REST services with JSF sounds like an action based solution which may subestimate the power of the JSF itself.

Not if you have multiple entries into the app. If you do it right, all the business logic ends up going through the REST classes. You could simply inject the REST classes and use them like normal POJOs in JSF backing beans, an entry into the app using HTML5, GWT, desktop client, native mobile client, etc. it's actually a very good separation if you need multiple entry points into the app. This essentially boils down to one common entry point, multiple views. I think it's quickly becoming my preferred architecture. 

My two cents ;)

Regards,

George Gastaldi

Em 16/01/2012, às 22:27, Jason Porter <lightguard.jp@gmail.com> escreveu:

I'll have to think on this some more.

On Mon, Jan 16, 2012 at 16:36, Ove Ranheim <oranheim@gmail.com> wrote:
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@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@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@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@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@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




--
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
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev