Sent from my iPhone
On Jan 16, 2012, at 18:46, George Gastaldi <gegastaldi(a)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(a)gmail.com> escreveu:
> I'll have to think on this some more.
>
> On Mon, Jan 16, 2012 at 16:36, Ove Ranheim <oranheim(a)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(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
>
>
>
>
> --
> 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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev