[seam-dev] Seam REST and WELD-001303 No active contexts
George Gastaldi
gegastaldi at gmail.com
Mon Jan 16 21:06:09 EST 2012
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.
Em 17/01/2012, às 00:00, Jason Porter <lightguard.jp at gmail.com> escreveu:
Sent from my iPhone
On Jan 16, 2012, at 18:46, George Gastaldi <gegastaldi at 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 at gmail.com> escreveu:
I'll have to think on this some more.
On Mon, Jan 16, 2012 at 16:36, Ove Ranheim < <oranheim at gmail.com>
oranheim at 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 at gmail.com>
> oranheim at 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 at gmail.com>
>> oranheim at 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 at gmail.com>
>>> oranheim at 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 at gmail.com>
>>> oranheim at 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 at lists.jboss.org>seam-dev at lists.jboss.org
>>>
>>> <https://lists.jboss.org/mailman/listinfo/seam-dev>
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Jason Porter
>> <http://lightguard-jp.blogspot.com/>http://lightguard-jp.blogspot.com
>> <http://twitter.com/lightguardjp>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: <http://keyserver.net/>keyserver.net,
>> <http://pgp.mit.edu/>pgp.mit.edu
>>
>>
>>
>
>
> --
> Jason Porter
> <http://lightguard-jp.blogspot.com/>http://lightguard-jp.blogspot.com
> <http://twitter.com/lightguardjp>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: <http://keyserver.net/>keyserver.net,
> <http://pgp.mit.edu/>pgp.mit.edu
>
>
>
--
Jason Porter
<http://lightguard-jp.blogspot.com>http://lightguard-jp.blogspot.com
<http://twitter.com/lightguardjp>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: <http://keyserver.net>keyserver.net,
<http://pgp.mit.edu>pgp.mit.edu
_______________________________________________
seam-dev mailing list
seam-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20120117/1f1ed863/attachment-0001.html
More information about the seam-dev
mailing list