[VOTE] support of implicit bean archive under Java SE
by Antoine Sabot-Durand
Hi all,
Yesterday during the meeting we had a discussion about implicit bean archive support under Java SE.
The idea is to have it disabled by default and provide a way to activate it thru parameter "javax.enterprise.inject.scan.implicit=true”on command line or in the parameter map of the initialize method.
Details of the discussion and points of people pro and against this support can be found in meeting log :
http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-de...
I’d like to call for a vote regarding the support of implicit bean archive under Java SE.
This vote will be open for 72 hrs. Answer +1 (yes), 0 (don’t care), -1 (no) to this mail to vote.
Thanks
Antoine
8 years, 10 months
[JBoss JIRA] (CDI-529) Define bean discovery rules when CDI in Java SE
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-529?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-529:
------------------------------------------
[~agoncal] this ticket doesn't exclude CDI-529, it's a reminder to seriously deal with general discovery mode in SE. CDI-526 is more general and could be applied at core level (so for SE and EE).
> Define bean discovery rules when CDI in Java SE
> -----------------------------------------------
>
> Key: CDI-529
> URL: https://issues.jboss.org/browse/CDI-529
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java SE Integration
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
>
> We should specify how bean discovery works under Java SE. Since the default {{annotated}} bean discovery mode in Java EE could lead to performance issue we need to provide a different behavior for SE.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (CDI-526) Include filters
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-526:
---------------------------------------
+1
And you could mix both includes and excludes for the same application (including some packages and excluding others)
{code}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" bean-discovery-mode="all">
<scan>
<include name="my.app1.*" />
<include name="my.app2.*" />
<exclude name="my.app2.pack1*" />
</scan>
</beans>
{code}
> Include filters
> ---------------
>
> Key: CDI-526
> URL: https://issues.jboss.org/browse/CDI-526
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
>
> CDI has support for exclude filters in the beans.xml where a certain part of a bean archive (no matter whether "annotated" or "all" type) can be excluded from CDI processing on a package level, e.g:
> {code:XML}
> <exclude name="com.acme.rest.*" />
> {code}
> With the rise of fat jars and CDI support for SE it would also be useful to be able to define an include filter. Suppose we have a single large jar file with all its dependencies shaded in. This jar file has the beans.xml file which means that all the packages in that file are processed (all classes are at least scanned for bean defining annotations or even turned into CDI beans in "all" mode). We can obviously add a couple of exclude filters for each of the libraries we do not want to scan. It would however be much nicer if we could define a single include filter e.g.:
> {code:XML}
> <include name="my.application.*" />
> {code}
> Other packages (that belong to shaded-in libraries) in the same jar would not be scanned at all.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
Async event proposal
by Antoine Sabot-Durand
Hi all,
You may have missed the proposal I sent in this PR https://github.com/cdi-spec/cdi/pull/250 <https://github.com/cdi-spec/cdi/pull/250>.
It gathers most facts we agreed on regarding async events but I had to make some choices that could be discussed t have a consistent a real proposal:
1) Introducing @ObservesAsync
I won’t go back on the discussion around backward compatibility for Asyc Event. If you want read a sum up on it please go there: http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-D... <http://cdi-development-mailing-list.1064426.n5.nabble.com/Previously-on-D...>
We had 4 solutions to activate async on the observer side. I removed the ones bringing modification to @Observes annotation, removed the @Async solution since I didn’t want to to introduce such a generic annotation in CDI and the place to put it elsewhere in Java EE is not obvious. That would let us @AsyncSupported and @ObservesAsync solutions. I kept @ObservesAsync because it’s simpler for user to have only one annotation to activate this feature and because @AsyncSupport didn’t seems to have other application than activating async on observer.
I think form an user pov it’s the less worst solution to support this double activation requirement
2) Restricting fireAsync to ObservesAsync
Following the logic in 1 my draft restrict fireAsync call to only notify ObservesAsync observers. As we introduce a new feature and don’t want to break previously existing one I found this approach less confusing for our users. If we’re not happy with this restriction we could add parameter to fireAsync to target synchronous observer as well, but I really think we should consider this default behavior…
3) Change fireAsync signature
In our initial proposal fireAsync basic signature was
<U extends T> CompletionStage<U> fireAsync(U event);
I simplified the signature with
CompletionStage<void> fireAsync (U event);
As the original fire method returns void I found confusing to return anything something letting think that a value (different than a status) was obtained from the observers notification.
As Jozef pointed there are aspect lacking to the proposal. I plan to add a solution to solve multiple exception and need proposal for Invocation context definition and mention for thread safety.
So help and feedback are welcome.
Antoine
8 years, 10 months
[JBoss JIRA] (CDI-534) Section 3.8 on CDI 1.2 spec javax.security.Principal
by Emily Jiang (JIRA)
Emily Jiang created CDI-534:
-------------------------------
Summary: Section 3.8 on CDI 1.2 spec javax.security.Principal
Key: CDI-534
URL: https://issues.jboss.org/browse/CDI-534
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.2.Final
Environment:
n/a
Reporter: Emily Jiang
Priority: Minor
In section 3.8 Additional built-in beans
a bean with bean type javax.security.Principal, allowing injection of a Principal
representing the current caller identity.
javax.security.Principle should be java.security.Principal.
The same typo exists in CDI 1.0, 1.1 and 1.2.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-533:
---------------------------------
Jozef,
If you interpret weblib1.jar, weblib2.jar and earlib1.jar as library jars, it makes sense. However, I don't think people who read the spec interpret that way.
In your example,
app.ear
|-- web1.war
| |-- WEB-INF/classes
| |-- WEB-INF/lib
| |-- weblib1.jar
| |-- weblib2.jar
|-- ejb1.jar
|-- lib/
| |-- earlib1.jar
A big portion of people will think weblib1.jar belongs to the war module, which is logical. Besides these jars lie in the war module physically. Maybe the section 5 needs to be rephrased to spell it out.
> Bean Deployment archive conflicts between section 5 and section 12
> ------------------------------------------------------------------
>
> Key: CDI-533
> URL: https://issues.jboss.org/browse/CDI-533
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12;
> In section 5,
> Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file.
> This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib.
> While in section 12:
> When determining which archives are bean archives, the container must consider:
> • Library jars, EJB jars or application client jars
> • The WEB-INF/classes directory of a war
> • Directories in the JVM classpath
> It indicates each jar should be a bean archive. The smallest unit is a jar.
> I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked.
> All conversation is on the cdi-dev mailing list.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-533:
-----------------------------------
In that sense you are right. There should actually be 2 different 'BDA' terms. If you are talking about bean-scanning and class pickup then this of course should be per-jar (or classpath entry).
I otoh was solely talking about the enablement of Alternatives, Interceptors and Decorators which imo is fine to behave on a per-EE-module basis. The reason why I answered this issue is that the spec links those 2 via the 'BDA' term, which is highly confusing.
> Bean Deployment archive conflicts between section 5 and section 12
> ------------------------------------------------------------------
>
> Key: CDI-533
> URL: https://issues.jboss.org/browse/CDI-533
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12;
> In section 5,
> Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file.
> This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib.
> While in section 12:
> When determining which archives are bean archives, the container must consider:
> • Library jars, EJB jars or application client jars
> • The WEB-INF/classes directory of a war
> • Directories in the JVM classpath
> It indicates each jar should be a bean archive. The smallest unit is a jar.
> I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked.
> All conversation is on the cdi-dev mailing list.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-533:
-------------------------------------
You're confusing things, Mark. We are talking about the definition of a bean archive whereas you are talking about enablement (per bean archive or per application). The question of enablement has been resolved with @Priority.
> Bean Deployment archive conflicts between section 5 and section 12
> ------------------------------------------------------------------
>
> Key: CDI-533
> URL: https://issues.jboss.org/browse/CDI-533
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12;
> In section 5,
> Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file.
> This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib.
> While in section 12:
> When determining which archives are bean archives, the container must consider:
> • Library jars, EJB jars or application client jars
> • The WEB-INF/classes directory of a war
> • Directories in the JVM classpath
> It indicates each jar should be a bean archive. The smallest unit is a jar.
> I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked.
> All conversation is on the cdi-dev mailing list.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-533?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-533:
-----------------------------------
Of course you _can_ interpret it that way. But there is the other option as well. And your interpretation is a.) not historically sound and b.) not what the users really want. Just go over to the DeltaSpike list and ask the question what behaviour they like most. In OpenWebBeans we interpreted it as Section 5 wide ever since. Any no user ever complained.
As you know I do quite a lot conference talks. And I asked the question whether they like it per jar or app wide. And there was literally no single hand for the per-jar but the whole room for the application wide behaviour. And I asked this on quite a few occasions in front of a few thousand people till now! This is the no 1 most hated thing in CDI (which people otherwise really love ever since).
> Bean Deployment archive conflicts between section 5 and section 12
> ------------------------------------------------------------------
>
> Key: CDI-533
> URL: https://issues.jboss.org/browse/CDI-533
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI1.2 spec, the definition for bean archive are conflicting between section 5 and section 12;
> In section 5,
> Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a module architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file.
> This section talks about the bean deployment on the module or library level. It indicates one web module (may contain web-inf\lib etc) is a single bean archive. The smallest unit is a module or a lib.
> While in section 12:
> When determining which archives are bean archives, the container must consider:
> • Library jars, EJB jars or application client jars
> • The WEB-INF/classes directory of a war
> • Directories in the JVM classpath
> It indicates each jar should be a bean archive. The smallest unit is a jar.
> I started this conversation with Mark, Jozef, Antoine, Romain. The correct implementation is section 12. So section 5 needs to be reworked.
> All conversation is on the cdi-dev mailing list.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months