[JBoss JIRA] Created: (WELD-918) interceptor binding for java interfaces/methods
by Manuel Hartl (JIRA)
interceptor binding for java interfaces/methods
-----------------------------------------------
Key: WELD-918
URL: https://issues.jboss.org/browse/WELD-918
Project: Weld
Issue Type: Feature Request
Components: Weld SPI
Affects Versions: 1.1.0.Final
Environment: tomcat6
Reporter: Manuel Hartl
Priority: Minor
- i created an interceptor and marked an java interface class with its binding (or a method of the interface)
- interception does not work on methods of beans, that implement this interface.
should this work? (interceptor binding to java interfaces?)
if yes: it's a bug :)
if no: please update weld documentation
actually, i would like to use in interfaces
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (WELD-930) Producer is made an alternative if the declaring bean class is an alternative
by Alexey Kazakov (JIRA)
Producer is made an alternative if the declaring bean class is an alternative
-----------------------------------------------------------------------------
Key: WELD-930
URL: https://issues.jboss.org/browse/WELD-930
Project: Weld
Issue Type: Bug
Components: Producers (Methods, Fields and Disposers)
Affects Versions: 1.1.0.Final
Reporter: Alexey Kazakov
I'm looking at examples from https://github.com/pmuir/jboss-as-developer-guide/tree/master/quickstarts
There is org.jboss.as.quickstarts.login.EJBUserManager:
{code:title=org.jboss.as.quickstarts.login.EJBUserManager|borderStyle=solid}
...
@Named("userManager")
@RequestScoped
@Alternative
@Stateful
public class EJBUserManager implements UserManager {
...
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
{code}
And there is also another bean org.jboss.as.quickstarts.login.ManagedBeanUserManager:
{code:title=org.jboss.as.quickstarts.login.ManagedBeanUserManager|borderStyle=solid}
...
@Named("userManager")
@RequestScoped
public class ManagedBeanUserManager implements UserManager {
@SuppressWarnings("unchecked")
@Produces
@Named
@RequestScoped
public List<User> getUsers() throws Exception {
...
}
...
}
{code}
This code works in Weld even if EJBUserManager.getUsers() is not annotated @Alternative. But regarding the spec such a method has an ambiguous EL name "users":
{quote}
5.3.1. Ambiguous EL names
An ambiguous EL name exists in an EL expression when an EL name resolves to multiple beans. When an ambiguous EL
name exists, the container attempts to resolve the ambiguity. If any of the beans are alternatives, the container eliminates
all beans that are not alternatives, *except for producer methods and fields of beans that are alternatives*. If there is exactly
one bean remaining, the container will select this bean, and the ambiguous EL name is called resolvable.
{quote}
There is a comment from Pete Muir:
{quote}
This looks to me like a bug in Weld (one that crept in from a pre-final spec revision) - that it checks if the declaring bean class is an alternative, and if it is, makes the producer an alternative. Can you file a WELD issue for this? I'll update the quickstart to explicitly make the producer an alternative.
Pete
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WELD-1052) Unproxyable bean type check too strict
by Jozef Hartinger (JIRA)
Jozef Hartinger created WELD-1052:
-------------------------------------
Summary: Unproxyable bean type check too strict
Key: WELD-1052
URL: https://issues.jboss.org/browse/WELD-1052
Project: Weld
Issue Type: Bug
Components: Proxies
Affects Versions: 1.1.5.Final
Reporter: Jozef Hartinger
Assignee: Jozef Hartinger
Fix For: 2.0.0.Alpha2
According to the specification, a deployment that contains the following bean:
{code:JAVA}
public interface FooInterface {
}
@ApplicationScoped
public final class Foo implements FooInterface {
}
{code}
is valid as long as there is no injection point injecting Foo directly.
The following injection point is valid:
{code:JAVA}
@Inject
private FooInterface foo;
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months