deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunzenreiner Simon <simon.gunzenrei...@axa-tech.com>
Subject RE: ContextControl for Weld EE
Date Thu, 22 May 2014 06:34:59 GMT
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 <gudnabrsam@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" <gudnabrsam@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
> >>>
> >>
> >
> >
> >
>
Mime
View raw message