deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: ContextControl for Weld EE
Date Thu, 22 May 2014 09:01:29 GMT
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 <gerhard.petracek@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message