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.
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.
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
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at:
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org