On Mon, Apr 15, 2013 at 5:04 PM, Reinis Vicups <[email protected]> wrote:
>
> @Howard - well, if I understand you correctly, your solution is to have
> (may I call it like this?)
Yes, you may call it like that. :)
> a application scoped cache (the list in a singleton) or queue?
yes, it's definitely application scoped, a queue, but not a cache. :)
> This solution has couple of disadvantages in my case (IF I understood your
> design correctly) such as
> - disposal of instances I don't require (in my case they are quite
> "statey" entities thus I want to dispose them).
Your use of the word, 'statey' reminds me of the word 'stateful', and we
both know that @SessionScoped is definitely 'stateful' or 'statey' as you
called it. :)
I do understand your approach,
> Is your JMS popping the instances off the list?
>
No. @Schedule is popping the instances off of the application-scoped
list/queue. :)
> - and nillage of the CDI contexts/EJB lifecycles, because basically I have
> a global variable (fact that it is in @Singleton bean saves me only the
> boilerplate code).
>
>
Saves you only the boilerplate code? So, you do like 'savings', so I'm sure
you can go with John's recommendation, and do all the work in a non-statey
(or 'stateless') context, and 'save' yourself of the ('statey')
@SessionScoped 'annotation' (see below) and 'save' yourself of asking the
list, why the test case does not work. :)
>> ONLY IF the producer method produceUser() is annotated as
@SessionScoped. If I remove annotation, the test case works and User entity
is being persisted.
