[jboss-jira] [JBoss JIRA] (DROOLS-972) CDI annotations are not following CDI scopes

[Mauricio Salatino (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13185954#comment-13185954 ] 

Mauricio Salatino commented on DROOLS-972:
------------------------------------------

I've added some tests in linked PR that shows how the @KSession annotation fails to follow the bean scope as the specification dictates. Each bean also includes an injection of MyBean which is used to check the correct behaviour. 

In the PR is also included a new scope definition, and I'm working on trying to understand if we can create our own scope to wrap a KieSession lifecycle. This scope should be similar to the @ConversationScoped but not linked at all to the HTTPSession, but from the behaviour point of view should be extremely similar.


> CDI annotations are not following CDI scopes
> --------------------------------------------
>
>                 Key: DROOLS-972
>                 URL: https://issues.jboss.org/browse/DROOLS-972
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Mauricio Salatino
>            Assignee: Mario Fusco
>
> I'm wondering if it is just a missing feature of if there is a technical limitation why we are not following the CDI scopes approach.
> To be concrete what I wanted to achieve is to have 
> Something like this:
>     @Inject
>     @KReleaseId(groupId = "xxx", artifactId = "xxxxx", version = "1.0-SNAPSHOT")
>     @KSession
>     private KieSession kSession;
> Inside a bean with @ApplicationScoped.. that works well because the KieSession is application scoped and shared between different requests, but now when I do 
> @RequestScoped or @SessionScoped the KieSession is still shared :(
> I imagine that supporting these two scopes should be fairly easy from the CDI point of view:
> 1) @RequestScoped: just recreate the session everytime and look for the @ReleaseId everytime, because the idea is that if the ReleaseId is updated, the new request will need to load the new ReleaseId artifact
> 2) @BusinessSessionScoped: the session will have an ID and just a check is needed, if the session exist just use the KieSession registered for that ID, if it doesn't exist create a new one. Notice that I didn't use the existing @SessionScoped because that is usually tied to the HTTPSession, which might be another case.
> The lack of scopes also interfere with Arquillian for CDI testing, the @Ksession annotation seems to be creating a singleton, so when JUnit fork to execute several tests in parallel the @Injected @Ksession is shared among all the tests :(
> I'm sure that you guys already know about this, but I just wrote it down to state clear what the user expectations are regarding this and also to clarify my thoughts. If you guys can guide me and give me some pointers I can even help on this side.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)