Details
-
Type:
Feature Request
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 3.0.0.Beta1
-
Component/s: Core
-
Labels:None
-
Estimated Difficulty:Low
Description
The BeanManagerAware#getBeanManager() method currently throws an IllegalArgumentException when the BeanManager cannot be found by any provider. Because this exception is so generic, it's dangerous to bundle the lookup with other code because you aren't sure whether the IllegalArgumentException came from the BeanManager lookup or from a subsequent call, as in:
try
{ BeanManager beanManager = BeanManagerAccessor.getBeanManager(); beanManager.fireEvent(payload); }catch (IllegalArgumentException e)
{ // what caused this? }Introduce a specialized checked exception for this unique failure. The proposed name is BeanManagerNotAvailable (or BeanManagerNotFound)
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
(The reason it looks it up twice is because the static methods on BeanManagerAccessor don't hold state, obviously).
So can we just make it this?
BeanManagerLocator locator = new BeanManagerLocator();
if (locator.isBeanManagerAvailable())
And still have a specialized unchecked exception that extends IllegalStateException when the getter fails.
public class BeanManagerNotAvailable extends IllegalStateException {}
Dan Allen
added a comment - So can we just make it this?
BeanManagerLocator locator = new BeanManagerLocator();
if (locator.isBeanManagerAvailable())
{
BeanManager beanManager = locator.getBeanManager();
beanManager.fireEvent(payload);
}
And still have a specialized unchecked exception that extends IllegalStateException when the getter fails.
public class BeanManagerNotAvailable extends IllegalStateException {} We also need to reword because EE simply has missing areas of coverage for CDI. So for instance, w/o Seam Faces, people have no choice but to use BeanManagerAware/Accessor/Locator to do any sort of CDI tie-in.
The way I like to put it is "you should be using this to provide CDI integration, not spreading it all over application code. The goal is to shift into a managed environment so you can leverage the CDI programming model in a native way."
Dan Allen
added a comment - We also need to reword because EE simply has missing areas of coverage for CDI. So for instance, w/o Seam Faces, people have no choice but to use BeanManagerAware/Accessor/Locator to do any sort of CDI tie-in.
The way I like to put it is "you should be using this to provide CDI integration, not spreading it all over application code. The goal is to shift into a managed environment so you can leverage the CDI programming model in a native way." 
Locator sounds good. There are cases when you shouldn't use it for integration. For example if you can place the BM in a context in a location where can inject it, do it.
I don't think that this should be a checked exception, as IMHO in most cases this is not recoverable. I am in favour of a BeanManagerNotAvailible unchecked exception