]
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.