-
1. Re: BoundRequestContext and store
manovotn Aug 7, 2018 8:02 AM (in response to flavien.laurent)The associated store is where the beans with that scope reside. BoundRequestContext can attach and detach such a store - this is handy for when you actually have this data within HTTP request.
For instance, when you use @RequestScoped with Weld SE, it internally uses UnboundRequestContext as there is no need to have attachable store.
So the question is whether you really need BoundRequestContext? Or can you just make do with @ActivateRequestScope in SE which does the job for you?
Do you have your code somewhere on GitHub where we could look at it?
-
2. Re: BoundRequestContext and store
flavien.laurent Aug 7, 2018 9:52 AM (in response to manovotn)Thanks for your help. I rephrase my question a bit.
If I put an object in this map before calling associate like so
final Map<String, Object> storage = new HashMap<>();
storage.put("foobar", foobarObject);
requestContext.associate(storage);
requestContext.activate();
myService.doIt();
[...]
In MyService class, is it possible to get what I put in the storage? If yes, how to do it? If no, what is the purpose to be able to create a map as storage if it will always be empty?
All samples are written with the same empty map, I don't understand why.
I can make a full example on Github if necessary.
-
3. Re: BoundRequestContext and store
manovotn Aug 8, 2018 2:35 AM (in response to flavien.laurent)You cannot retrieve them like you say, they are not metadata, they are actual bean instances.
The map is a backing storage for your request context and if you @Inject FoobarObject in your code (assuming it's @RequestScoped), Weld will look into this map for the FoobarObject bean.
If it is there, it will inject it straight away, if not it will create the bean and store into the map for future injections - Weld populates this Map, not you.
You are probably misunderstanding the meaning of storage here. It isn't meant as a custom metadata storage for scope-related data. It is just a structure Weld uses for storing all the beans if you tell it to.
The Map is usually empty in those samples because upon creating the scope, you have no beans in it and likewise when you deactive the scope (at the end of request in this case), you likely want to sweep all the beans as well.
So why allow for association/dissociation?
This way the storage is externally managed, integrators can choose when to associate the Map.
You could also take the same Map, make a copy and associate it to context activated in another thread for instance.
There are more use cases, albeit not so common.
Does it make sense now?
-
4. Re: BoundRequestContext and store
flavien.laurent Aug 8, 2018 3:49 AM (in response to manovotn)Ok it makes more sense now! Thanks a lot.
Last thing. There is on example where the storage is not empty. In HttpContextLifeCycle, the HttpServletRequest is associated as storage on the HttpRequestContext (which extends BoundContext<HttpServletRequest>).
Do you know why?
-
5. Re: BoundRequestContext and store
manovotn Aug 8, 2018 4:19 AM (in response to flavien.laurent)Servlet request in just another form of externally managed storage (e.g. Weld doesn't create/destroy it, we just use it).
It can contain more information than just beans (I guess that's what you mean by not empty?) so we but grab it and attach it as storage to our context.
Obviously, when you do this at the beginning of a request, there are no beans stored, so from our PoV, it is as if it were empty.
-
6. Re: BoundRequestContext and store
flavien.laurent Aug 8, 2018 4:23 AM (in response to manovotn)Ok, this phrase: "Servlet request in just another form of externally managed storage (e.g. Weld doesn't create/destroy it, we just use it)." rang a bell in my head.
Thanks for your time
-
7. Re: BoundRequestContext and store
manovotn Aug 8, 2018 4:25 AM (in response to flavien.laurent)Glad I could help