Question regarding producer methods and default no-arg constructor
by Michael Remijan
Greetings,
I recently ran into a situation where I had created a producer method for an object but when Weld was starting up I got errors about something being ambiguous. I finally tracked the issue to the fact that the bean my producer method was responsible for producing only had a default no-arg constructor. I was able to "work around" this problem by annotating the bean as an @Alternative. So I have a few questions.
(1)Is this expected behavior from CDI? If a bean only has the default no-arg constructor should you get an ambiguous error if you also have a producer method for the bean?
(2)Is annotating the bean as an @Alternative an acceptable "work around"? Seems hackish to me. If not, what is the appropriate solution.
Thanks!
11 years
[JBoss JIRA] (CDI-496) Clarification (or completion) for interceptor binding to session bean
by Tomas Remes (JIRA)
Tomas Remes created CDI-496:
-------------------------------
Summary: Clarification (or completion) for interceptor binding to session bean
Key: CDI-496
URL: https://issues.jboss.org/browse/CDI-496
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Tomas Remes
It's not clear if the session bean can have interceptor binding and what rules (if any) apply to this case. In the beginning of chapter 9. Interceptor bindings there is following statement:
{quote}Managed beans and EJB session and message-driven beans support interception.{quote}
But at the end of "9.3. Binding an interceptor to a bean" There is only:
{quote}
If a managed bean has a class-level or method-level interceptor binding, the managed bean must
be a proxyable bean type, as defined in Section 3.15, “Unproxyable bean types”.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
unproxyable constraint for ejbs
by Romain Manni-Bucau
Hi
org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelMissile
will make the container throw a DeploymentException cause of public
final void finalManeuver() which is final...but it is not in the EJB
API so CDI shouldn't even know it.
Is the test buggy -
org.jboss.cdi.tck.tests.interceptors.definition.broken.finalClassInterceptor.FinalMethodClassLevelInterceptorTest?
IMO this has not to be tested since the EJB container already does it.
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
11 years
Ordering of AfterTypeDiscovery#getAlternatives() et al
by Mark Struberg
Hi!
If I have a
@Priority(100)
public class MyAlternative implements Foo ..
and
@Priority(101)
public class ABetterAlternative implements Foo ..
Then ABetterAlternative will finally be chosen.
This ordering can be changed via AfterTypeDiscovery#getAlternatives().
But the spec only says "returns the ordered list of enabled alternatives for the application.."
But it does NOT define in which sorting this list is ordered ;)
In OWB we hat the 'most important' alternative come first. It seems in Weld it is the other way around.
I have no problem with changing this in OWB, but I would like to get this clarified in our JavaDocs and spec.
LieGrue,
strub
11 years
