[JBoss JIRA] (CDI-372) clarify behaviour of implicit bean archive
by David Konecny (JIRA)
David Konecny created CDI-372:
---------------------------------
Summary: clarify behaviour of implicit bean archive
Key: CDI-372
URL: https://issues.jboss.org/browse/CDI-372
Project: CDI Specification Issues
Issue Type: Clarification
Components: Packaging and Deployment
Affects Versions: 1.1.PFD
Reporter: David Konecny
Priority: Minor
I read chapter "12.1 Bean archives" which defines 'explicit bean archive' and 'implicit bean archive' and following that I removed beans.xml from my existing application only to find out that deployment of my app now fails because of unsatisfied dependencies. It took me a while to figure out the problem: there is behavioural difference between explicit and implicit bean archive which is mentioned later in the middle of chapter "12.4 Bean discovery":
The container discovers:
• each Java class, interface or enum deployed in an explicit bean archive, and
• each Java class interface, or enum with a bean defining annotation in an implicit bean archive.
The fact that implicit bean archive provides only beans with defining annotations is very important piece of information and I would like to suggest to mention that early in chapter 12.1 when the bean archive concepts are defined. Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
javax.enterprise.event.Event and Serialization
by Jens Schumann
Hi all!
While fixing FindBugs issues I came across javax.enterprise.event.Event members that are not serializable. Is there anything that prevents javax.enterprise.event.Event extends Serializable?
Jens
10 years, 11 months
Doubt about bean discovery default behaviour
by Michel Graciano
Hi all,
I have been reading the CDI spec and did some little tests with a prototype we have here and I am facing a issue when I deploy our application at GF 4 (which has guava as ine of the dependencies):
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
Basically I am facing it because guava has some classes annotated with @Inject and the container by default are scanning all the deps.
I have read the spec and for me it is not clear what the default behaviour is, if the container should or not scan all the dependencies when my app is supposedly following 1.0 spec (see our beans.xml above). Digging a little bit more, I found a issue [1] which says basically that 'Auto-discover is false by default in CDI 1.1 and the attribute is required...', which for me means that by default the container should work as CDI 1.0 at this matter. R eading the spec a little further I found ' For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present.' (which is the case for guava library) which could means that by default the container will not work as expected by CDI 1.0, so we have an incompatible change here.
Our beans.xml file has just this content:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>
My question here is: Am I facing a issue at Weld/GF 4 (glassfish-4.0-b86) or it is the default behaviour expected for CDI 1.1 specification?
IMHO this behaviour should be clear at the specification, maybe following as did by JSR 344 adding a 'Breakages in Backward Compatibility' section for changelog section if it is the case.
I am sorry if this question have already been asked, but I was unable to find it (I swear I tried :).
Thanks in advance.
[1] https://issues.jboss.org/browse/CDI-321
--
Michel Graciano
Pesquisa e Desenvolvimento
Betha Sistemas Ltda.
10 years, 11 months
[JBoss JIRA] (CDI-31) Asynchronous events
by Gerhard Petracek (JIRA)
[ https://issues.jboss.org/browse/CDI-31?page=com.atlassian.jira.plugin.sys... ]
Gerhard Petracek edited comment on CDI-31 at 5/7/13 5:39 PM:
-------------------------------------------------------------
i haven't said that it is spec compliant or portable or supports every use-case. currently it only works with owb.
was (Author: gpetracek):
i haven't said that it is spec compliment or portable or supports every use-case. currently it only works with owb.
> Asynchronous events
> -------------------
>
> Key: CDI-31
> URL: https://issues.jboss.org/browse/CDI-31
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Fix For: TBD
>
>
> Consider including asynchronous events as their were specified in one of the previous drafts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (CDI-371) Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-371?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-371:
-------------------------------
Any server which uses Weld will ensure a that a request context is active when an MDB is invoked. There is no requirement that a request context is *created*. This was not tested in the 1.0 TCK, but is tested in the 1.1 TCK.
Why does the EJB spec need changing?
> Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
> -----------------------------------------------------------------------------------------
>
> Key: CDI-371
> URL: https://issues.jboss.org/browse/CDI-371
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.PFD
> Reporter: John Ament
>
> In CDI spec, section 6.7.1 message-driven beans are included as having Request Scope enabled during invocation. This is not consistent with other areas where MDBs were removed. Further more this section needs additional review with the updated MDB spec that the EJB group has come up with.
> I believe Transaction Scope is more appropriate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months
[JBoss JIRA] (CDI-371) Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-371?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-371:
--------------------------------
This functionality has never been implemented as far as anyone is aware. Currently MDBs do not create a request scope context when they are invoked (at least not consistently across app servers). In order to do this, an EJB spec change needs to be done to turn on this context.
> Message-Driven Beans should not have request scope active OR EJB spec needs to be updated
> -----------------------------------------------------------------------------------------
>
> Key: CDI-371
> URL: https://issues.jboss.org/browse/CDI-371
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.0, 1.1.PFD
> Reporter: John Ament
>
> In CDI spec, section 6.7.1 message-driven beans are included as having Request Scope enabled during invocation. This is not consistent with other areas where MDBs were removed. Further more this section needs additional review with the updated MDB spec that the EJB group has come up with.
> I believe Transaction Scope is more appropriate.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 11 months