Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: Future
-
Component/s: None
-
Estimated Difficulty:Low
Description
It adds the ELResolver belonging to the BeanManager of the seam-solder.jar module, when in fact the user will want the ELResolver for the bean manager from their module/app.
public class ELResolverProducer
{
@Produces
@Composite
public ELResolver getELResolver(@Resolver Instance<ELResolver> resolvers, BeanManager beanManager)
}
Gliffy Diagrams
Issue Links
- is related to
-
CDI-23
Allow BeanManager to be resolved as though you were in another bean archive
-
- Reopened
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
No, the bean manager injected will be the one for the BDA in which solder is present. This is completely correct if you think about it, resolvability follows accessibility, so the only resolvable beans from solder will be the ones that are accessible (which if solder is used as e.g. an installed library or perhaps an ear library is not much...).
I don't believe there is a good solution to this problem, short of finding a way to find the BeanManager the client code (which you could do via a setter I guess).
Pete Muir
added a comment - No, the bean manager injected will be the one for the BDA in which solder is present. This is completely correct if you think about it, resolvability follows accessibility, so the only resolvable beans from solder will be the ones that are accessible (which if solder is used as e.g. an installed library or perhaps an ear library is not much...).
I don't believe there is a good solution to this problem, short of finding a way to find the BeanManager the client code (which you could do via a setter I guess). Thanks for the explanation. Just gotta remember that now 
So perhaps the solution here is to expose a field into which the client code can set the BeanManager (via Seam Config perhaps?). If that field is not set, then we fallback to assuming the flat model. The only thing I'm unsure of is whether what Seam Config pushes in will be any different. If it's not, can it be assigned programmatically in a application startup method?
Sounds like this might be a documentation issue as much as a code change.
Dan Allen
added a comment - Thanks for the explanation. Just gotta remember that now
So perhaps the solution here is to expose a field into which the client code can set the BeanManager (via Seam Config perhaps?). If that field is not set, then we fallback to assuming the flat model. The only thing I'm unsure of is whether what Seam Config pushes in will be any different. If it's not, can it be assigned programmatically in a application startup method?
Sounds like this might be a documentation issue as much as a code change. I assume Seam Config will just inject it, you would need to actually attach the BM from client code.
Really we should add a way to inject the BM for the current thread context.
I'm having trouble understanding the problem. The producers for ELResolver, ELContext and Expressions are all dependent-scoped. They are presumably used to inject into an injection point in the user's application. I would assume, then, that the BeanManager that is injected into the producer is going to be the one corresponding to the injection point, which would be the right one.
If my explanation is incorrect, can you please suggest where we should be looking to solve this problem?