BoundRequestContext and store

[flavien.laurent]

Hi all,

I'm playing with BoundRequestContext to create my own request context in a non servlet application but I don't understand what is the purpose of the associated store.

I through it was meant for passing contextual data but in this case, how to retrieve those data in beans called in this custom context?

I read the documentation https://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_available_contexts_in_weld and how it's done for the http request in HttpContextLifecycle but still not clear how to use it. All the example found use an empty map as store so it doesn't help.

Thanks for your help,

[manovotn]

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?

[flavien.laurent]

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.

[manovotn]

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?

[flavien.laurent]

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?

[manovotn]

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.

[flavien.laurent]

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

[manovotn]

Glad I could help