Sent from my iPhone
On Jan 16, 2012, at 19:06, George Gastaldi <[email protected]> wrote: > Jason, > > You're Right, i completely forgot about the multiple entry view approach. > > But since Ove didnt mentioned about multiple views, I assumed JSF is the only > entry point, which adding REST may be overengineering. Yes, that would be true. How many apps now days, that are public facing, only need one view though? > > Em 17/01/2012, às 00:00, Jason Porter <[email protected]> escreveu: > >> >> >> Sent from my iPhone >> >> On Jan 16, 2012, at 18:46, George Gastaldi <[email protected]> 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 <[email protected]> escreveu: >>> >>>> I'll have to think on this some more. >>>> >>>> On Mon, Jan 16, 2012 at 16:36, Ove Ranheim <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
