You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Gunzenreiner Simon <si...@axa-tech.com> on 2014/05/21 13:28:38 UTC
ContextControl for Weld EE
Hi
Am I right in understanding that the Deltaspike context control API for weld is only available for Weld SE? There seems to be no "binding" for Weld in an EE context, specifically JBoss.
It would be nice if the doc would make that more clear, maybe the weld binding could even highlight this in the name (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
Are there any plans to support the context control API also in the EE context? My use case is the following: I have a "stateful" Object that should survive multiple user interactions and is therefore ConversationScoped. The same managed bean should also be usable in situations where we have only an active request scope (EJB timer), and it's life cycle should then be bound to the request scope. For this case, I would like to activate the Converation scope when the timer method is entered programmatically (or rather via an Interceptor).
Regards
Simon
Re: ContextControl for Weld EE
Posted by Gerhard Petracek <ge...@gmail.com>.
short addition:
fyi: you can use the window- and grouped-conversation-scope provided by
deltaspike instead. starting/stopping them works without issues.
e.g.:
inject ContextControl and WindowContext
->
String virtualWindowId = UUID.randomUUID().toString(); //just as an example
try
{
this.contextControl.startContext(SessionScoped.class);
this.windowContext.activateWindow(virtualWindowId);
//...
}
finally
{
this.windowContext.closeWindow(virtualWindowId);
this.contextControl.stopContext(SessionScoped.class);
}
+ you can inject and use GroupedConversationManager, if you need to control
@GroupedConversationScoped beans.
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-05-22 10:35 GMT+02:00 Gerhard Petracek <ge...@gmail.com>:
> hi simon,
>
> you can ignore the ClassNotFoundException in this case. you just see the
> exception during the startup. however, the deployment will continue.
> i've tried it on as7. e.g. starting contexts works, however, stopping them
> gets ignored by as7 (without exception).
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2014-05-22 8:34 GMT+02:00 Gunzenreiner Simon <
> simon.gunzenreiner@axa-tech.com>:
>
> Indeed - the problem is that the ContextControl and Boot APIs are packaged
>> togeather. And yes, it seems the same - I got the same
>> ClassNotFoundException.
>>
>> Regards
>> Simon
>>
>> -----Original Message-----
>> From: Karl Kildén [mailto:karl.kilden@gmail.com]
>> Sent: Mittwoch, 21. Mai 2014 21:16
>> To: users@deltaspike.apache.org
>> Subject: Re: ContextControl for Weld EE
>>
>> Starting to sound a lot like my issue I reported a year ago.
>> https://issues.apache.org/jira/browse/DELTASPIKE-284
>>
>> But in the thread I posted before you can see that "Thanks guys. My
>> question is not really in tune with jsr 236, but I was able to get it
>> working. I'll update the docs in the next day or two on how to make it
>> work in EE." [from John D. Ament]
>>
>>
>>
>>
>>
>> On 21 May 2014 21:05, Gunzenreiner Simon <simon.gunzenreiner@axa-tech.com
>> >wrote:
>>
>> > Thanks Mark
>> >
>> > I have noticed 2 problems with
>> > <artifactId>jet-stream-deltaspike-cdictrl-weld</artifactId>
>> > - when deployed in JBoss (EAP 6.0), Weld itself throws a
>> > NoClassDefFoundError, since WeldContainerControl has dependencies on
>> > org.jboss.weld.environment.se.Weld, which is not on the JBoss classpath.
>> > - when WeldContainerControl is removed from the jar, I get a
>> > IllegalStateException from org.jboss.weld.manager BeanManagerImpl
>> > .getContext(). The reason is that the current deltaspike
>> > implementation simply has Weld inject a BoundRequestContext - but for
>> > an EJB environment, an EjbRequestContextImpl is already active.
>> >
>> > If the EE context control scenario should actually work - shall I
>> > report bugs for these issues?
>> >
>> > Simon
>> >
>> > -----Original Message-----
>> > From: Mark Struberg [mailto:struberg@yahoo.de]
>> > Sent: Mittwoch, 21. Mai 2014 19:00
>> > To: users@deltaspike.apache.org
>> > Subject: Re: ContextControl for Weld EE
>> >
>> > Nope, we DO also handle contexts. Those are 2 different aspects.
>> > The first one is booting - this obviously only makes sense in SE.
>> > The other one is ContextControl - and this also should work in EE.
>> >
>> > But please note that we only have a few backends yet: weld, owb and
>> > openejb. There is no wildfly nor glassfish backend YET. Means that the
>> > cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is
>> > *not* guaranteed. It _would_ be easily possible to write backends for
>> > those containers. I'd be happy about some contributions ;)
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com>
>> > wrote:
>> >
>> >
>> > >
>> > >
>> > >On rereading your original message, you should be able to manage
>> > >custom contexts using appropriate extensions regardless, but the
>> > >cdictrl module, AIUI, is concerned with bootstrapping.
>> > >
>> > >Matt
>> > >
>> > >On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
>> > >
>> > >> In an EE container CDI should just "be"; you only have to bootstrap
>> > >> it outside an EE or EE web profile container.
>> > >>
>> > >> HTH,
>> > >> Matt
>> > >> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
>> > >> simon.gunzenreiner@axa-tech.com> wrote:
>> > >>
>> > >>> Hi
>> > >>>
>> > >>> Am I right in understanding that the Deltaspike context control
>> > >>> API for weld is only available for Weld SE? There seems to be no
>> > >>> "binding" for Weld in an EE context, specifically JBoss.
>> > >>>
>> > >>> It would be nice if the doc would make that more clear, maybe the
>> > >>> weld binding could even highlight this in the name
>> > >>> (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
>> > >>>
>> > >>> Are there any plans to support the context control API also in the
>> > >>> EE context? My use case is the following: I have a "stateful"
>> > >>> Object that should survive multiple user interactions and is
>> > >>> therefore ConversationScoped. The same managed bean should also be
>> > >>> usable in situations where we have only an active request scope
>> > >>> (EJB timer), and it's life cycle should then be bound to the
>> > >>> request scope. For this case, I would like to activate the
>> > >>> Converation scope when the timer method is entered
>> > >>> programmatically (or rather via an
>> > Interceptor).
>> > >>>
>> > >>> Regards
>> > >>> Simon
>> > >>>
>> > >>
>> > >
>> > >
>> > >
>> >
>>
>
>
RE: ContextControl for Weld EE
Posted by Gunzenreiner Simon <si...@axa-tech.com>.
I know - but as I wrote:
contextControl.startContext(ConversationScoped.class) throws an NPE because I did not call contextControl.startContext(RequestScoped.class), but calling the latter results in the " IllegalStateException: WELD-001304 More than one context active for scope type javax.enterprise.context.RequestScoped" Exception.
I'll try your suggestion though regarding windowsScope later.
Thanks
Simon
-----Original Message-----
From: Gerhard Petracek [mailto:gerhard.petracek@gmail.com]
Sent: Donnerstag, 22. Mai 2014 13:33
To: users@deltaspike.apache.org
Subject: Re: ContextControl for Weld EE
hi simon,
you can't use #startContexts here.
as you can see in the message, you can't start the request-scope again.
(-> use #startContext instead)
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-05-22 13:02 GMT+02:00 Gunzenreiner Simon <
simon.gunzenreiner@axa-tech.com>:
> Hallo Gerhard
>
> The application starts up despite the stack trace, you are right.
>
> - starting the conversation context does not work though in my
> scenario (timed EJB invocation), I get the following exception after
> initializing the Conversation like this:
> contextControl.startContexts()
>
> org.jboss.weld.exceptions.IllegalStateException: WELD-001304 More than
> one context active for scope type
> javax.enterprise.context.RequestScoped
> at
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java
> :614)
> at
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanI
> nstance.java:71)
> at
> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler
> .java:104)
> at
> org.jboss.weld.proxies.Session$2059085923$Proxy$_$$_WeldClientProxy.ge
> tRootNode(Session$2059085923$Proxy$_$$_WeldClientProxy.java)
>
> - when simply starting the conversationScope with
> startConversationScope(), I get Caused by:
> java.lang.NullPointerException
> at
> org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:34)
> at
> org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:10)
> at
> org.jboss.weld.context.AbstractConversationContext.associate(AbstractConversationContext.java:108)
> at
> org.apache.deltaspike.cdise.weld.ContextController.startConversationScope(ContextController.java:122)
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.startConversationScope(WeldContextControl.java:149)
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.startContext(WeldC
> ontextControl.java:74)
>
> because the request Scope was not initialized via
> ContextController.starRequestScope(). Doing this would result in the
> former exception, but should not be necessary anyway, because there is
> an active requestContext of type EjbRequestContextImpl
>
>
> Regards
> Simon
>
Re: ContextControl for Weld EE
Posted by Gerhard Petracek <ge...@gmail.com>.
hi simon,
you can't use #startContexts here.
as you can see in the message, you can't start the request-scope again.
(-> use #startContext instead)
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-05-22 13:02 GMT+02:00 Gunzenreiner Simon <
simon.gunzenreiner@axa-tech.com>:
> Hallo Gerhard
>
> The application starts up despite the stack trace, you are right.
>
> - starting the conversation context does not work though in my scenario
> (timed EJB invocation), I get the following exception after initializing
> the Conversation like this: contextControl.startContexts()
>
> org.jboss.weld.exceptions.IllegalStateException: WELD-001304 More than one
> context active for scope type javax.enterprise.context.RequestScoped
> at
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:614)
> at
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
> at
> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:104)
> at
> org.jboss.weld.proxies.Session$2059085923$Proxy$_$$_WeldClientProxy.getRootNode(Session$2059085923$Proxy$_$$_WeldClientProxy.java)
>
> - when simply starting the conversationScope with
> startConversationScope(), I get
> Caused by: java.lang.NullPointerException
> at
> org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:34)
> at
> org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:10)
> at
> org.jboss.weld.context.AbstractConversationContext.associate(AbstractConversationContext.java:108)
> at
> org.apache.deltaspike.cdise.weld.ContextController.startConversationScope(ContextController.java:122)
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.startConversationScope(WeldContextControl.java:149)
> at
> org.apache.deltaspike.cdise.weld.WeldContextControl.startContext(WeldContextControl.java:74)
>
> because the request Scope was not initialized via
> ContextController.starRequestScope(). Doing this would result in the former
> exception, but should not be necessary anyway, because there is an active
> requestContext of type EjbRequestContextImpl
>
>
> Regards
> Simon
>
RE: ContextControl for Weld EE
Posted by Gunzenreiner Simon <si...@axa-tech.com>.
Hallo Gerhard
The application starts up despite the stack trace, you are right.
- starting the conversation context does not work though in my scenario (timed EJB invocation), I get the following exception after initializing the Conversation like this: contextControl.startContexts()
org.jboss.weld.exceptions.IllegalStateException: WELD-001304 More than one context active for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:614)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:71)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:104)
at org.jboss.weld.proxies.Session$2059085923$Proxy$_$$_WeldClientProxy.getRootNode(Session$2059085923$Proxy$_$$_WeldClientProxy.java)
- when simply starting the conversationScope with startConversationScope(), I get
Caused by: java.lang.NullPointerException
at org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:34)
at org.jboss.weld.context.bound.BoundConversationContextImpl.getRequestAttribute(BoundConversationContextImpl.java:10)
at org.jboss.weld.context.AbstractConversationContext.associate(AbstractConversationContext.java:108)
at org.apache.deltaspike.cdise.weld.ContextController.startConversationScope(ContextController.java:122)
at org.apache.deltaspike.cdise.weld.WeldContextControl.startConversationScope(WeldContextControl.java:149)
at org.apache.deltaspike.cdise.weld.WeldContextControl.startContext(WeldContextControl.java:74)
because the request Scope was not initialized via ContextController.starRequestScope(). Doing this would result in the former exception, but should not be necessary anyway, because there is an active requestContext of type EjbRequestContextImpl
Regards
Simon
Re: ContextControl for Weld EE
Posted by Gerhard Petracek <ge...@gmail.com>.
hi simon,
you can ignore the ClassNotFoundException in this case. you just see the
exception during the startup. however, the deployment will continue.
i've tried it on as7. e.g. starting contexts works, however, stopping them
gets ignored by as7 (without exception).
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-05-22 8:34 GMT+02:00 Gunzenreiner Simon <
simon.gunzenreiner@axa-tech.com>:
> Indeed - the problem is that the ContextControl and Boot APIs are packaged
> togeather. And yes, it seems the same - I got the same
> ClassNotFoundException.
>
> Regards
> Simon
>
> -----Original Message-----
> From: Karl Kildén [mailto:karl.kilden@gmail.com]
> Sent: Mittwoch, 21. Mai 2014 21:16
> To: users@deltaspike.apache.org
> Subject: Re: ContextControl for Weld EE
>
> Starting to sound a lot like my issue I reported a year ago.
> https://issues.apache.org/jira/browse/DELTASPIKE-284
>
> But in the thread I posted before you can see that "Thanks guys. My
> question is not really in tune with jsr 236, but I was able to get it
> working. I'll update the docs in the next day or two on how to make it
> work in EE." [from John D. Ament]
>
>
>
>
>
> On 21 May 2014 21:05, Gunzenreiner Simon <simon.gunzenreiner@axa-tech.com
> >wrote:
>
> > Thanks Mark
> >
> > I have noticed 2 problems with
> > <artifactId>jet-stream-deltaspike-cdictrl-weld</artifactId>
> > - when deployed in JBoss (EAP 6.0), Weld itself throws a
> > NoClassDefFoundError, since WeldContainerControl has dependencies on
> > org.jboss.weld.environment.se.Weld, which is not on the JBoss classpath.
> > - when WeldContainerControl is removed from the jar, I get a
> > IllegalStateException from org.jboss.weld.manager BeanManagerImpl
> > .getContext(). The reason is that the current deltaspike
> > implementation simply has Weld inject a BoundRequestContext - but for
> > an EJB environment, an EjbRequestContextImpl is already active.
> >
> > If the EE context control scenario should actually work - shall I
> > report bugs for these issues?
> >
> > Simon
> >
> > -----Original Message-----
> > From: Mark Struberg [mailto:struberg@yahoo.de]
> > Sent: Mittwoch, 21. Mai 2014 19:00
> > To: users@deltaspike.apache.org
> > Subject: Re: ContextControl for Weld EE
> >
> > Nope, we DO also handle contexts. Those are 2 different aspects.
> > The first one is booting - this obviously only makes sense in SE.
> > The other one is ContextControl - and this also should work in EE.
> >
> > But please note that we only have a few backends yet: weld, owb and
> > openejb. There is no wildfly nor glassfish backend YET. Means that the
> > cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is
> > *not* guaranteed. It _would_ be easily possible to write backends for
> > those containers. I'd be happy about some contributions ;)
> >
> > LieGrue,
> > strub
> >
> >
> > On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com>
> > wrote:
> >
> >
> > >
> > >
> > >On rereading your original message, you should be able to manage
> > >custom contexts using appropriate extensions regardless, but the
> > >cdictrl module, AIUI, is concerned with bootstrapping.
> > >
> > >Matt
> > >
> > >On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
> > >
> > >> In an EE container CDI should just "be"; you only have to bootstrap
> > >> it outside an EE or EE web profile container.
> > >>
> > >> HTH,
> > >> Matt
> > >> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
> > >> simon.gunzenreiner@axa-tech.com> wrote:
> > >>
> > >>> Hi
> > >>>
> > >>> Am I right in understanding that the Deltaspike context control
> > >>> API for weld is only available for Weld SE? There seems to be no
> > >>> "binding" for Weld in an EE context, specifically JBoss.
> > >>>
> > >>> It would be nice if the doc would make that more clear, maybe the
> > >>> weld binding could even highlight this in the name
> > >>> (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
> > >>>
> > >>> Are there any plans to support the context control API also in the
> > >>> EE context? My use case is the following: I have a "stateful"
> > >>> Object that should survive multiple user interactions and is
> > >>> therefore ConversationScoped. The same managed bean should also be
> > >>> usable in situations where we have only an active request scope
> > >>> (EJB timer), and it's life cycle should then be bound to the
> > >>> request scope. For this case, I would like to activate the
> > >>> Converation scope when the timer method is entered
> > >>> programmatically (or rather via an
> > Interceptor).
> > >>>
> > >>> Regards
> > >>> Simon
> > >>>
> > >>
> > >
> > >
> > >
> >
>
RE: ContextControl for Weld EE
Posted by Gunzenreiner Simon <si...@axa-tech.com>.
Indeed - the problem is that the ContextControl and Boot APIs are packaged togeather. And yes, it seems the same - I got the same ClassNotFoundException.
Regards
Simon
-----Original Message-----
From: Karl Kildén [mailto:karl.kilden@gmail.com]
Sent: Mittwoch, 21. Mai 2014 21:16
To: users@deltaspike.apache.org
Subject: Re: ContextControl for Weld EE
Starting to sound a lot like my issue I reported a year ago.
https://issues.apache.org/jira/browse/DELTASPIKE-284
But in the thread I posted before you can see that "Thanks guys. My question is not really in tune with jsr 236, but I was able to get it working. I'll update the docs in the next day or two on how to make it work in EE." [from John D. Ament]
On 21 May 2014 21:05, Gunzenreiner Simon <si...@axa-tech.com>wrote:
> Thanks Mark
>
> I have noticed 2 problems with
> <artifactId>jet-stream-deltaspike-cdictrl-weld</artifactId>
> - when deployed in JBoss (EAP 6.0), Weld itself throws a
> NoClassDefFoundError, since WeldContainerControl has dependencies on
> org.jboss.weld.environment.se.Weld, which is not on the JBoss classpath.
> - when WeldContainerControl is removed from the jar, I get a
> IllegalStateException from org.jboss.weld.manager BeanManagerImpl
> .getContext(). The reason is that the current deltaspike
> implementation simply has Weld inject a BoundRequestContext - but for
> an EJB environment, an EjbRequestContextImpl is already active.
>
> If the EE context control scenario should actually work - shall I
> report bugs for these issues?
>
> Simon
>
> -----Original Message-----
> From: Mark Struberg [mailto:struberg@yahoo.de]
> Sent: Mittwoch, 21. Mai 2014 19:00
> To: users@deltaspike.apache.org
> Subject: Re: ContextControl for Weld EE
>
> Nope, we DO also handle contexts. Those are 2 different aspects.
> The first one is booting - this obviously only makes sense in SE.
> The other one is ContextControl - and this also should work in EE.
>
> But please note that we only have a few backends yet: weld, owb and
> openejb. There is no wildfly nor glassfish backend YET. Means that the
> cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is
> *not* guaranteed. It _would_ be easily possible to write backends for
> those containers. I'd be happy about some contributions ;)
>
> LieGrue,
> strub
>
>
> On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com>
> wrote:
>
>
> >
> >
> >On rereading your original message, you should be able to manage
> >custom contexts using appropriate extensions regardless, but the
> >cdictrl module, AIUI, is concerned with bootstrapping.
> >
> >Matt
> >
> >On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
> >
> >> In an EE container CDI should just "be"; you only have to bootstrap
> >> it outside an EE or EE web profile container.
> >>
> >> HTH,
> >> Matt
> >> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
> >> simon.gunzenreiner@axa-tech.com> wrote:
> >>
> >>> Hi
> >>>
> >>> Am I right in understanding that the Deltaspike context control
> >>> API for weld is only available for Weld SE? There seems to be no
> >>> "binding" for Weld in an EE context, specifically JBoss.
> >>>
> >>> It would be nice if the doc would make that more clear, maybe the
> >>> weld binding could even highlight this in the name
> >>> (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
> >>>
> >>> Are there any plans to support the context control API also in the
> >>> EE context? My use case is the following: I have a "stateful"
> >>> Object that should survive multiple user interactions and is
> >>> therefore ConversationScoped. The same managed bean should also be
> >>> usable in situations where we have only an active request scope
> >>> (EJB timer), and it's life cycle should then be bound to the
> >>> request scope. For this case, I would like to activate the
> >>> Converation scope when the timer method is entered
> >>> programmatically (or rather via an
> Interceptor).
> >>>
> >>> Regards
> >>> Simon
> >>>
> >>
> >
> >
> >
>
Re: ContextControl for Weld EE
Posted by Karl Kildén <ka...@gmail.com>.
Starting to sound a lot like my issue I reported a year ago.
https://issues.apache.org/jira/browse/DELTASPIKE-284
But in the thread I posted before you can see that "Thanks guys. My
question is not really in tune with jsr 236, but I
was able to get it working. I'll update the docs in the next day or
two on how to make it work in EE." [from John D. Ament]
On 21 May 2014 21:05, Gunzenreiner Simon <si...@axa-tech.com>wrote:
> Thanks Mark
>
> I have noticed 2 problems with
> <artifactId>jet-stream-deltaspike-cdictrl-weld</artifactId>
> - when deployed in JBoss (EAP 6.0), Weld itself throws a
> NoClassDefFoundError, since WeldContainerControl has dependencies on
> org.jboss.weld.environment.se.Weld, which is not on the JBoss classpath.
> - when WeldContainerControl is removed from the jar, I get a
> IllegalStateException from org.jboss.weld.manager BeanManagerImpl
> .getContext(). The reason is that the current deltaspike implementation
> simply has Weld inject a BoundRequestContext - but for an EJB environment,
> an EjbRequestContextImpl is already active.
>
> If the EE context control scenario should actually work - shall I report
> bugs for these issues?
>
> Simon
>
> -----Original Message-----
> From: Mark Struberg [mailto:struberg@yahoo.de]
> Sent: Mittwoch, 21. Mai 2014 19:00
> To: users@deltaspike.apache.org
> Subject: Re: ContextControl for Weld EE
>
> Nope, we DO also handle contexts. Those are 2 different aspects.
> The first one is booting - this obviously only makes sense in SE.
> The other one is ContextControl - and this also should work in EE.
>
> But please note that we only have a few backends yet: weld, owb and
> openejb. There is no wildfly nor glassfish backend YET. Means that the
> cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is *not*
> guaranteed. It _would_ be easily possible to write backends for those
> containers. I'd be happy about some contributions ;)
>
> LieGrue,
> strub
>
>
> On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com>
> wrote:
>
>
> >
> >
> >On rereading your original message, you should be able to manage custom
> >contexts using appropriate extensions regardless, but the cdictrl
> >module, AIUI, is concerned with bootstrapping.
> >
> >Matt
> >
> >On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
> >
> >> In an EE container CDI should just "be"; you only have to bootstrap
> >> it outside an EE or EE web profile container.
> >>
> >> HTH,
> >> Matt
> >> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
> >> simon.gunzenreiner@axa-tech.com> wrote:
> >>
> >>> Hi
> >>>
> >>> Am I right in understanding that the Deltaspike context control API
> >>> for weld is only available for Weld SE? There seems to be no
> >>> "binding" for Weld in an EE context, specifically JBoss.
> >>>
> >>> It would be nice if the doc would make that more clear, maybe the
> >>> weld binding could even highlight this in the name
> >>> (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
> >>>
> >>> Are there any plans to support the context control API also in the
> >>> EE context? My use case is the following: I have a "stateful" Object
> >>> that should survive multiple user interactions and is therefore
> >>> ConversationScoped. The same managed bean should also be usable in
> >>> situations where we have only an active request scope (EJB timer),
> >>> and it's life cycle should then be bound to the request scope. For
> >>> this case, I would like to activate the Converation scope when the
> >>> timer method is entered programmatically (or rather via an
> Interceptor).
> >>>
> >>> Regards
> >>> Simon
> >>>
> >>
> >
> >
> >
>
RE: ContextControl for Weld EE
Posted by Gunzenreiner Simon <si...@axa-tech.com>.
Thanks Mark
I have noticed 2 problems with <artifactId>jet-stream-deltaspike-cdictrl-weld</artifactId>
- when deployed in JBoss (EAP 6.0), Weld itself throws a NoClassDefFoundError, since WeldContainerControl has dependencies on org.jboss.weld.environment.se.Weld, which is not on the JBoss classpath.
- when WeldContainerControl is removed from the jar, I get a IllegalStateException from org.jboss.weld.manager BeanManagerImpl .getContext(). The reason is that the current deltaspike implementation simply has Weld inject a BoundRequestContext - but for an EJB environment, an EjbRequestContextImpl is already active.
If the EE context control scenario should actually work - shall I report bugs for these issues?
Simon
-----Original Message-----
From: Mark Struberg [mailto:struberg@yahoo.de]
Sent: Mittwoch, 21. Mai 2014 19:00
To: users@deltaspike.apache.org
Subject: Re: ContextControl for Weld EE
Nope, we DO also handle contexts. Those are 2 different aspects.
The first one is booting - this obviously only makes sense in SE.
The other one is ContextControl - and this also should work in EE.
But please note that we only have a few backends yet: weld, owb and openejb. There is no wildfly nor glassfish backend YET. Means that the cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is *not* guaranteed. It _would_ be easily possible to write backends for those containers. I'd be happy about some contributions ;)
LieGrue,
strub
On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com> wrote:
>
>
>On rereading your original message, you should be able to manage custom
>contexts using appropriate extensions regardless, but the cdictrl
>module, AIUI, is concerned with bootstrapping.
>
>Matt
>
>On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
>
>> In an EE container CDI should just "be"; you only have to bootstrap
>> it outside an EE or EE web profile container.
>>
>> HTH,
>> Matt
>> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
>> simon.gunzenreiner@axa-tech.com> wrote:
>>
>>> Hi
>>>
>>> Am I right in understanding that the Deltaspike context control API
>>> for weld is only available for Weld SE? There seems to be no
>>> "binding" for Weld in an EE context, specifically JBoss.
>>>
>>> It would be nice if the doc would make that more clear, maybe the
>>> weld binding could even highlight this in the name
>>> (deltaspike-cdictrl-weld-se instead of deltaspike-cdictrl-weld).
>>>
>>> Are there any plans to support the context control API also in the
>>> EE context? My use case is the following: I have a "stateful" Object
>>> that should survive multiple user interactions and is therefore
>>> ConversationScoped. The same managed bean should also be usable in
>>> situations where we have only an active request scope (EJB timer),
>>> and it's life cycle should then be bound to the request scope. For
>>> this case, I would like to activate the Converation scope when the
>>> timer method is entered programmatically (or rather via an Interceptor).
>>>
>>> Regards
>>> Simon
>>>
>>
>
>
>
Re: ContextControl for Weld EE
Posted by Karl Kildén <ka...@gmail.com>.
This thread is similar:
http://markmail.org/message/35mupjy4444f62k3
On 21 May 2014 19:00, Mark Struberg <st...@yahoo.de> wrote:
> Nope, we DO also handle contexts. Those are 2 different aspects.
> The first one is booting - this obviously only makes sense in SE.
> The other one is ContextControl - and this also should work in EE.
>
> But please note that we only have a few backends yet: weld, owb and
> openejb. There is no wildfly nor glassfish backend YET. Means that the
> cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is *not*
> guaranteed. It _would_ be easily possible to write backends for those
> containers. I'd be happy about some contributions ;)
>
> LieGrue,
> strub
>
>
> On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com>
> wrote:
>
>
> >
> >
> >On rereading your original message, you should be able to manage custom
> >contexts using appropriate extensions regardless, but the cdictrl module,
> >AIUI, is concerned with bootstrapping.
> >
> >Matt
> >
> >On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
> >
> >> In an EE container CDI should just "be"; you only have to bootstrap it
> >> outside an EE or EE web profile container.
> >>
> >> HTH,
> >> Matt
> >> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
> >> simon.gunzenreiner@axa-tech.com> wrote:
> >>
> >>> Hi
> >>>
> >>> Am I right in understanding that the Deltaspike context control API for
> >>> weld is only available for Weld SE? There seems to be no "binding" for
> Weld
> >>> in an EE context, specifically JBoss.
> >>>
> >>> It would be nice if the doc would make that more clear, maybe the weld
> >>> binding could even highlight this in the name
> (deltaspike-cdictrl-weld-se
> >>> instead of deltaspike-cdictrl-weld).
> >>>
> >>> Are there any plans to support the context control API also in the EE
> >>> context? My use case is the following: I have a "stateful" Object that
> >>> should survive multiple user interactions and is therefore
> >>> ConversationScoped. The same managed bean should also be usable in
> >>> situations where we have only an active request scope (EJB timer), and
> it's
> >>> life cycle should then be bound to the request scope. For this case, I
> >>> would like to activate the Converation scope when the timer method is
> >>> entered programmatically (or rather via an Interceptor).
> >>>
> >>> Regards
> >>> Simon
> >>>
> >>
> >
> >
> >
>
Re: ContextControl for Weld EE
Posted by Mark Struberg <st...@yahoo.de>.
Nope, we DO also handle contexts. Those are 2 different aspects.
The first one is booting - this obviously only makes sense in SE.
The other one is ContextControl - and this also should work in EE.
But please note that we only have a few backends yet: weld, owb and openejb. There is no wildfly nor glassfish backend YET. Means that the cdictrl-weld _might_ work in glassfish, jbossas or wildfly, but it is *not* guaranteed. It _would_ be easily possible to write backends for those containers. I'd be happy about some contributions ;)
LieGrue,
strub
On Wednesday, 21 May 2014, 14:23, Matt Benson <gu...@gmail.com> wrote:
>
>
>On rereading your original message, you should be able to manage custom
>contexts using appropriate extensions regardless, but the cdictrl module,
>AIUI, is concerned with bootstrapping.
>
>Matt
>
>On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
>
>> In an EE container CDI should just "be"; you only have to bootstrap it
>> outside an EE or EE web profile container.
>>
>> HTH,
>> Matt
>> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
>> simon.gunzenreiner@axa-tech.com> wrote:
>>
>>> Hi
>>>
>>> Am I right in understanding that the Deltaspike context control API for
>>> weld is only available for Weld SE? There seems to be no "binding" for Weld
>>> in an EE context, specifically JBoss.
>>>
>>> It would be nice if the doc would make that more clear, maybe the weld
>>> binding could even highlight this in the name (deltaspike-cdictrl-weld-se
>>> instead of deltaspike-cdictrl-weld).
>>>
>>> Are there any plans to support the context control API also in the EE
>>> context? My use case is the following: I have a "stateful" Object that
>>> should survive multiple user interactions and is therefore
>>> ConversationScoped. The same managed bean should also be usable in
>>> situations where we have only an active request scope (EJB timer), and it's
>>> life cycle should then be bound to the request scope. For this case, I
>>> would like to activate the Converation scope when the timer method is
>>> entered programmatically (or rather via an Interceptor).
>>>
>>> Regards
>>> Simon
>>>
>>
>
>
>
Re: ContextControl for Weld EE
Posted by Matt Benson <gu...@gmail.com>.
On rereading your original message, you should be able to manage custom
contexts using appropriate extensions regardless, but the cdictrl module,
AIUI, is concerned with bootstrapping.
Matt
On May 21, 2014 7:20 AM, "Matt Benson" <gu...@gmail.com> wrote:
> In an EE container CDI should just "be"; you only have to bootstrap it
> outside an EE or EE web profile container.
>
> HTH,
> Matt
> On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
> simon.gunzenreiner@axa-tech.com> wrote:
>
>> Hi
>>
>> Am I right in understanding that the Deltaspike context control API for
>> weld is only available for Weld SE? There seems to be no "binding" for Weld
>> in an EE context, specifically JBoss.
>>
>> It would be nice if the doc would make that more clear, maybe the weld
>> binding could even highlight this in the name (deltaspike-cdictrl-weld-se
>> instead of deltaspike-cdictrl-weld).
>>
>> Are there any plans to support the context control API also in the EE
>> context? My use case is the following: I have a "stateful" Object that
>> should survive multiple user interactions and is therefore
>> ConversationScoped. The same managed bean should also be usable in
>> situations where we have only an active request scope (EJB timer), and it's
>> life cycle should then be bound to the request scope. For this case, I
>> would like to activate the Converation scope when the timer method is
>> entered programmatically (or rather via an Interceptor).
>>
>> Regards
>> Simon
>>
>
Re: ContextControl for Weld EE
Posted by Matt Benson <gu...@gmail.com>.
In an EE container CDI should just "be"; you only have to bootstrap it
outside an EE or EE web profile container.
HTH,
Matt
On May 21, 2014 6:29 AM, "Gunzenreiner Simon" <
simon.gunzenreiner@axa-tech.com> wrote:
> Hi
>
> Am I right in understanding that the Deltaspike context control API for
> weld is only available for Weld SE? There seems to be no "binding" for Weld
> in an EE context, specifically JBoss.
>
> It would be nice if the doc would make that more clear, maybe the weld
> binding could even highlight this in the name (deltaspike-cdictrl-weld-se
> instead of deltaspike-cdictrl-weld).
>
> Are there any plans to support the context control API also in the EE
> context? My use case is the following: I have a "stateful" Object that
> should survive multiple user interactions and is therefore
> ConversationScoped. The same managed bean should also be usable in
> situations where we have only an active request scope (EJB timer), and it's
> life cycle should then be bound to the request scope. For this case, I
> would like to activate the Converation scope when the timer method is
> entered programmatically (or rather via an Interceptor).
>
> Regards
> Simon
>