[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:
-------------------------------------
I don't think there is a conflict actually:
Section 5.1 says:
{quote}
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.
{quote}
It basically says that a bean archive is either a Java EE module or a library jar.
Let's use an example
{noformat}
app.ear
|-- web1.war
| |-- WEB-INF/classes
| |-- WEB-INF/lib
| |-- weblib1.jar
| |-- weblib2.jar
|-- ejb1.jar
|-- lib/
| |-- earlib1.jar
{noformat}
According to section 5.1 we (possibly) have the following bean archives:
* web1.war and ejb1.jar which are modules
* weblib1.jar, weblib2.jar and earlib1.jar are library jars
On top of 5.1, section 12.1 defines what it means for a module to be a bean archive. More specifically it says:
{quote}
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
{quote}
The *The WEB-INF/classes directory of a war* is important here. It defines what it means specifically for a web module to be a bean archive. It defines that the web1.war, as a bean archive, only contains classes located under the _WEB-INF/classes_ directory.
Therefore, in our application we have the following bean archives:
* web1.war (contains WEB-INF/classes only) and ejb1.jar which are modules
* weblib1.jar, weblib2.jar and earlib1.jar which are library jars
Therefore, there is no overlap as library jars are handled separately (by 5.1 and 12.1) and the bean archive for a web module is defined to contain classes from _WEB-INF/classes_ only.
> 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)
9 years, 6 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:
-----------------------------------
{quote}
The correct implementation is section 12.
{quote}
No that is not correct. The _original_ (way back in early 2008) intention was EE module. Then there was some discussion about interceptor ordering ambiguity and it got narrowed to JARs. But this was only intended for interceptors, and only half done. So it is still ambiguous till today and many containers enable Alternatives for the whole EE module if they are enabled in one of the beans.xml in it. Even the EE6 RI behaved that way (and only got 'patched' by a Weld update and the RI implementers seems to not even have been aware of that functional change).
The important point is that the per-jar interceptor/alternatives/decorator interpretation is pure PITA for all users.
> 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)
9 years, 6 months
Fwd: bean archives
by Emily Jiang
I agree with Mark. I am confused about section 5 and section 12. Weld-2
leaves the work of specifying the bean archive to the integrator. I am
wondering how the new version of app server using Weld-2 can pass the CDI
1.1/1.2 CTS at all if the integrator creates its bean archives based on
section 12.
I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based
on section 5. Can someone confirm? The spec needs to be updated to remove
the conflict between section 5 and section 12.
---------- Forwarded message ----------
From: Emily Jiang <emijiang6(a)googlemail.com>
Date: Sat, May 2, 2015 at 10:21 PM
Subject: Re: [cdi-dev] bean archives
To: Mark Struberg <struberg(a)yahoo.de>
I agree with Mark. I am confused about section 5 and section 12. Weld-2
leaves the work of specifying the bean archive to the integrator. I am
wondering how the new version of app server using Weld-2 can pass the CDI
1.1/1.2 CTS at all if the integrator creates its bean archives based on
section 12.
I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based
on section 5. Can someone confirm? The spec needs to be updated to remove
the conflict between section 5 and section 12.
On Sat, May 2, 2015 at 3:47 PM, Mark Struberg <struberg(a)yahoo.de> wrote:
> Actually the rules are still not clear. Section 5 and 12 contradict each
> other. The EE6 RI, JBossAS6 and TomEE and WAS did behave like in section 5
> (1 BDA per ee-module) whereas Weld-2 behaves like in section 12.
>
> LieGrue,
> strub
>
>
>
> On Saturday, 2 May 2015, 10:13, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
>
>
> Hi Emily,
>
> The rules) apply to each jar (archive). There is no merging, thus an app
> can contain three types of archives :
> Non bean archives,
> Implicit bean archives,
> Explicit bean archives.
>
> Antoine Sabot-Durand
>
>
> Le 1 mai 2015 à 23:03, Emily Jiang <emijiang6(a)googlemail.com> a écrit :
>
>
> I have a question on bean archives.
>
> For the jars under web-inf\lib, are they individual bean archives or they
> should be merged with web-inf\classes files and use the beans.xml under
> web-inf\ to form one bean archive?
>
>
> If they are merged together to form one bean archive, what will happen if
> they have their own beans.xml under Meta-inf dir?
>
> Below is the what spec says, but it does not mention the jar under
> web-inf\lib. The spec should make this situation clear.
>
> In the CDI1.2 spec:
> 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
> The container is not required to support application client jar bean
> archives.
> A Java EE container is required by the Java EE specification to support
> Java EE modules. Other
> containers may or may not provide support for war, EJB jar or rar bean
> archives.
> The beans.xml file must be named:
> • META-INF/beans.xml , or,
> • in a war, WEB-INF/beans.xml or WEB-INF/classes/META-INF/beans.xml.
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang(a)apache.org
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
9 years, 6 months
[JBoss JIRA] (CDI-533) Bean Deployment archive conflicts between section 5 and section 12
by Emily Jiang (JIRA)
Emily Jiang created CDI-533:
-------------------------------
Summary: 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)
9 years, 6 months
[JBoss JIRA] (CDI-499) Firing events asynchronously
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-499:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> Firing events asynchronously
> -----------------------------
>
> Key: CDI-499
> URL: https://issues.jboss.org/browse/CDI-499
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface.
> Our proposal is:
> h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}}
> Signature of the method on {{Event<T>}} would be
> {code:java}
> <U extends T> CompletionStage<U> fireAsync(U event);
> {code}
> Signature on {{BeanManager}} would be
> {code:java}
> <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers)
> {code}
> h2. 2. Add an {{asyncSupported()}} member to {{@Observes}}
> For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect.
> So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously.
> h2. 3. Observer bound to a transaction phase
> these observer will be invoked in the right transaction phase but asynchronously
> h2. 4. Event Ordering
> Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync).
> h2. 5. Event state (payload mutability)
> We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
Re: [cdi-dev] cdi-dev Digest, Vol 55, Issue 1
by Werner Keil
Hi,
I'm in a new project and country now.
Actually though earlier releases as of now CDI plays an important role
here, so unless IRC or the web-based variants are blocked for security
reasons I might be able to join the call.
Werner
On Tue, Jun 2, 2015 at 11:08 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>
> 10. Today's meeting (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 10
> Date: Tue, 2 Jun 2015 11:08:41 +0200
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Today's meeting
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <4FB29736-4671-4A08-913F-A36508AAC178(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Today I?d like to discuss EDR1 release and its final content.
>
> And then, discuss about the next step:
>
> - finishing features started in EDR1
> - prioritize our feature list for the coming months.
>
> Meeting is still at 6:00pm CET on IRC (freenode #cdi-dev channel)
>
> Regards,
>
> Antoine
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150602/5dbcf9b0/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 55, Issue 1
> **************************************
>
9 years, 7 months
Today's meeting
by Antoine Sabot-Durand
Hi all,
Today I’d like to discuss EDR1 release and its final content.
And then, discuss about the next step:
- finishing features started in EDR1
- prioritize our feature list for the coming months.
Meeting is still at 6:00pm CET on IRC (freenode #cdi-dev channel)
Regards,
Antoine
9 years, 7 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-280:
--------------------------------------
What is a "tenant proxy"? You mean a proxy written by the application developer himself? If so, then I'd not worry about it at all.
Half of the rest is related to EJB and JPA.
If CDI enforce different proxy types, then it should be clarified (but it doesn't right?). "CDI proxy" would be a valid term that encapsulate all types (but again, there are no different CDI proxy types?), or just "proxy" for short. The bottom line is that if we deal with a proxy, why not just call it that? Everything in the spec is "contextual" already. The word feels a bit bloated.
Actually, I think that the word "proxy" is one of those things that is quite clear without semantic noise. Now you want to replace all references made to a proxy with "contextual reference"? I just don't get it why.
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 2.0 (discussion)
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-280:
-----------------------------------
No, just calling it 'the proxy' would not be enough. Actually there are many different kind of proxies involved besides the 'Contextual Reference'. And depending on the implementation it could even be more.
1.) interceptor proxies
2.) decorator proxies
3.) subclassing proxies for abstract decorators
4.) EJB API proxies
5.) EJB NIV proxies
6.) JPA proxies
7.) customer specific proxies like custom InjectionTarget
8.) tenant proxies
etc
All those can be either used in parallel or some of them even stacked for the same bean!
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 2.0 (discussion)
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-280:
--------------------------------------
bq. The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
Or why not just call the proxy a proxy? If the origin of the proxy is not clear, call it a CDI proxy. In either way, I find that "contextual reference" is confusing.
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: CDI_api_chge, CDI_spec_chge
> Fix For: 2.0 (discussion)
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
