deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Kaltepoth <christ...@kaltepoth.de>
Subject Re: [DISCUSS] BeanManagerProvider API
Date Mon, 23 Jan 2012 08:14:12 GMT
@gerhard:

Thanks for the clarification. You are right. In most cases
#getInstance() will fail earlier. However I see other cases in which
#getBeanManager() could return null. For example if the context
classloader is different from the one for which the BeanManager is
stored (see [1] for an example). Therefore I think it would make sense
to throw a runtime exception in this case to notify the user. If we
don't do that the user will most likely see a NPE as soon as the
BeanManager is used which isn't nice. :)

Christian

[1] https://issues.apache.org/jira/browse/EXTCDI-74


2012/1/23 Gerhard Petracek <gerhard.petracek@gmail.com>:
> @mark:
> you can ask the person who did it for myfaces codi (see [1]) :)
>
> regards,
> gerhard
>
> [1]  http://svn.apache.org/viewvc?view=revision&revision=929170
>
>
>
> 2012/1/23 Mark Struberg <struberg@yahoo.de>
>
>> +1
>>
>> But why do we need the manual setBeanManager public at all?
>> I'll go on and make it protected.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>> > From: Gerhard Petracek <gerhard.petracek@gmail.com>
>> > To: deltaspike-dev@incubator.apache.org
>> > Cc:
>> > Sent: Monday, January 23, 2012 7:56 AM
>> > Subject: Re: [DISCUSS] BeanManagerProvider API
>> >
>> > hi christian,
>> >
>> > thx for moving this discussion to the mailing list!
>> >
>> > actually you don't have to check it because it would fail earlier.
>> > due to the basic mechanism you would see an IllegalStateException in
>> > #getInstance, if the cdi implementation isn't configured correctly (this
>> > topic is related to an upcoming discussion).
>> >
>> > the only case i can see right now would be caused by a manual call of
>> > #setBeanManager which resets it.
>> > -> imo we have to decide if we allow such a manual call.
>> >
>> > in general we should also discuss if we re-use existing exception types
>> (if
>> > it makes sense) or if we create our own types.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2012/1/23 Christian Kaltepoth <christian@kaltepoth.de>
>> >
>> >>  Hey @all,
>> >>
>> >>  yesterday I had a deeper look at the BeanManagerProvider
>> >>  implementation and found something that could be improved. I created
>> >>  DELTASPIKE-56 (see [1]) for this but it turned out that we should
>> >>  discuss this topic on the mailing list.
>> >>
>> >>  I saw that getBeanManager() may return null in some rare
>> >>  circumstances. Unfortunately this forces everyone calling this method
>> >>  to check the result for null. I think most code calling the method
>> >>  absolutely requires the BeanManager and cannot proceed without it.
>> >>
>> >>  My first idea was to add another method getRequiredBeanManager() that
>> >>  doesn't return null if the BeanManager is not available but instead
>> >>  throws a meaningful runtime exception. That's what Solder does per
>> >>  default. Calling Solder's BeanManagerLocator.getBeanManager() without
>> >>  a BeanManager being available will result in a
>> >>  BeanManagerUnavailableException (see [2]).
>> >>
>> >>  However Mark suggested that throwing an exception should be the
>> >>  default behavior. I for myself like Mark's idea.
>> >>
>> >>  What do you think?
>> >>
>> >>  Christian
>> >>
>> >>  [1] https://issues.apache.org/jira/browse/DELTASPIKE-56
>> >>  [2]
>> >>
>> >
>> https://github.com/seam/solder/blob/master/api/src/main/java/org/jboss/solder/beanManager/BeanManagerLocator.java#L82
>> >>
>> >>  --
>> >>  Christian Kaltepoth
>> >>  Blog: http://chkal.blogspot.com/
>> >>  Twitter: http://twitter.com/chkal
>> >>
>> >
>>



-- 
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal

Mime
View raw message