From emijiang6 at googlemail.com  Fri May  1 17:03:09 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Fri, 1 May 2015 22:03:09 +0100
Subject: [cdi-dev] bean archives
Message-ID: <CAECq3A9UVXjVz4_KqzX3pfHc71WZ_2WOWfdx4PbOHsNXMcCFvw@mail.gmail.com>

I have a question on bean archives.

For the jars under web-inf\lib, are they individual bean archives or they
should be merged together 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 at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150501/583d7251/attachment.html 

From antoine at sabot-durand.net  Sat May  2 04:13:15 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Sat, 2 May 2015 10:13:15 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A9UVXjVz4_KqzX3pfHc71WZ_2WOWfdx4PbOHsNXMcCFvw@mail.gmail.com>
References: <CAECq3A9UVXjVz4_KqzX3pfHc71WZ_2WOWfdx4PbOHsNXMcCFvw@mail.gmail.com>
Message-ID: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>

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 at 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 at apache.org
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150502/3a9765b2/attachment-0001.html 

From struberg at yahoo.de  Sat May  2 10:47:04 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sat, 2 May 2015 14:47:04 +0000 (UTC)
Subject: [cdi-dev] bean archives
In-Reply-To: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
Message-ID: <1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>

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 at 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 at 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 at apache.org


_______________________________________________
cdi-dev mailing list
cdi-dev at 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 at 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.

 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150502/68450767/attachment.html 

From issues at jboss.org  Sat May  2 14:31:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 14:31:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495533@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5960.1430591505496@Atlassian.JIRA>

Martin Andersson created CDI-523:
------------------------------------

             Summary: CDI spec tries to dispose a container-managed entity manager.
                 Key: CDI-523
                 URL: https://issues.jboss.org/browse/CDI-523
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 1.2.Final, 1.1.Final
            Reporter: Martin Andersson


Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class UserDatabaseEntityManager {
    @Produces @ConversationScoped @UserDatabase
    public EntityManager create(EntityManagerFactory emf) {
        return emf.createEntityManager();
    }

    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open.

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 14:34:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 14:34:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5961.1430591685501@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-523:
---------------------------------
    Description: 
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open.

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

  was:
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class UserDatabaseEntityManager {
    @Produces @ConversationScoped @UserDatabase
    public EntityManager create(EntityManagerFactory emf) {
        return emf.createEntityManager();
    }

    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open.

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
>                 Key: CDI-523
>                 URL: https://issues.jboss.org/browse/CDI-523
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Martin Andersson
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
>     @PersistenceContext
>     @Produces @UserDatabase
>     private EntityManager em;
>     
>     public void close(@Disposes @UserDatabase EntityManager em) {
>     em.close();
>     }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open.
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 14:44:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 14:44:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5970.1430592285524@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-523:
---------------------------------
    Description: 
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This is expected as the JPA spec forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

  was:
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open.

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
>                 Key: CDI-523
>                 URL: https://issues.jboss.org/browse/CDI-523
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Martin Andersson
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
>     @PersistenceContext
>     @Produces @UserDatabase
>     private EntityManager em;
>     
>     public void close(@Disposes @UserDatabase EntityManager em) {
>     em.close();
>     }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This is expected as the JPA spec forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 14:44:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 14:44:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5971.1430592285558@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-523:
---------------------------------
    Description: 
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

  was:
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This is expected as the JPA spec forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
>                 Key: CDI-523
>                 URL: https://issues.jboss.org/browse/CDI-523
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Martin Andersson
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
>     @PersistenceContext
>     @Produces @UserDatabase
>     private EntityManager em;
>     
>     public void close(@Disposes @UserDatabase EntityManager em) {
>     em.close();
>     }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 16:24:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 16:24:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.5987.1430598285770@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064792#comment-13064792 ] 

Martin Andersson commented on CDI-520:
--------------------------------------

I was trying to understand the life cycle of a container-managed entity manager when using CDI to look it up. My research has been put [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java]. As far as my understanding goes, the well spread practice of putting a CDI scope on a container-managed entity manager is not a good thing to do and it contradicts the outspoken goal of container-managed entity managers. Quoting JPA 1.2 specification, section "7.1 Persistence Contexts":

{quote}
This propagation of persistence contexts by the Java EE container avoids the need for the application to pass references to EntityManager instances from one component to another.
{quote}

Having CDI pass around the not thread-safe reference for us may expose the entity manager to concurrent calls. Furthermore, many close the entity manager following an example outlined in the CDI specification which is simply wrong because a container-managed entity manager must not be closed by the application. I opened a [ticket|https://issues.jboss.org/browse/CDI-523] for that.

My research has been put [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

My personal end goal was to know better how to use the entity manager in a Java EE application. This research has been put [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/jpa/entitymanagers/package-info.java#L314].

> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 16:24:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 16:24:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5988.1430598285797@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-523:
---------------------------------
    Description: 
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

  was:
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
    em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
>                 Key: CDI-523
>                 URL: https://issues.jboss.org/browse/CDI-523
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Martin Andersson
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
>     @PersistenceContext
>     @Produces @UserDatabase
>     private EntityManager em;
>     
>     public void close(@Disposes @UserDatabase EntityManager em) {
>         em.close();
>     }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sat May  2 16:24:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sat, 2 May 2015 16:24:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-523) CDI spec tries to dispose a
 container-managed entity manager.
In-Reply-To: <JIRA.12570548.1430591495000@Atlassian.JIRA>
References: <JIRA.12570548.1430591495000@Atlassian.JIRA>
	<JIRA.12570548.1430591495000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570548.1430591495000.5989.1430598285821@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-523:
---------------------------------
    Description: 
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {

    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].

  was:
Section "3.5.2. Declaring a disposer method" has this example:

{code:java}
public class Resources {
    @PersistenceContext
    @Produces @UserDatabase
    private EntityManager em;
    
    public void close(@Disposes @UserDatabase EntityManager em) {
        em.close();
    }
}
{code}

The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:

{quote}
The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
{quote}

This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
>                 Key: CDI-523
>                 URL: https://issues.jboss.org/browse/CDI-523
>             Project: CDI Specification Issues
>          Issue Type: Bug
>    Affects Versions: 1.2.Final, 1.1.Final
>            Reporter: Martin Andersson
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
>     @PersistenceContext
>     @Produces @UserDatabase
>     private EntityManager em;
>     
>     public void close(@Disposes @UserDatabase EntityManager em) {
>         em.close();
>     }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/unsafe/OracleTest.java] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/producers/entitymanager/package-info.java].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From struberg at yahoo.de  Sat May  2 18:01:00 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Sun, 3 May 2015 00:01:00 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
Message-ID: <93B26212-78EA-4D70-B761-DE17239C4FCF@yahoo.de>

Guess you meant to send this to the EG and not to me privately?

I guess it makes not that much difference except for legacy apps. Nowadays it is encouraged to use @Priority on decorators, interceptors and alternatives. And that will ?globally enable? those beans anyway. With section 5 interpretation as BDA you come to the same result (although also works for CDI-1.0 containers).

LieGrue,
strub


> Am 02.05.2015 um 23:21 schrieb Emily Jiang <emijiang6 at googlemail.com>:
> 
> 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 at 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 at 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 at 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 at apache.org
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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 at 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 at apache.org



From issues at jboss.org  Sat May  2 18:10:45 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sat, 2 May 2015 18:10:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6014.1430604645822@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064794#comment-13064794 ] 

Mark Struberg commented on CDI-520:
-----------------------------------

I agree that the sample with the @PersistenceContext EntityManager is not the best and has many implications and problems. E.g. you can inject a @PersistenceContext into a CDI bean but the EJB and EE umbrella specs only define that this EntityManager works _inside_ an EJB (read section about TransactionManagementType.CONTAINER).  So it doesn't make much sense at all to produce this...

Of course producing an EntityManager makes perfect sense in some other scenarios. E.g. injecting a @PersistenceUnit and producing a @RequestScoped EntityManager: https://github.com/struberg/lightweightEE/blob/jta/backend/src/main/java/de/jaxenter/eesummit/caroline/backend/tools/EntityManagerProducer.java

> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From emijiang6 at googlemail.com  Sat May  2 18:20:57 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Sat, 2 May 2015 23:20:57 +0100
Subject: [cdi-dev] Fwd:  bean archives
In-Reply-To: <CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
Message-ID: <CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>

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 at googlemail.com>
Date: Sat, May 2, 2015 at 10:21 PM
Subject: Re: [cdi-dev] bean archives
To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at 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 at apache.org



-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150502/9bec97b8/attachment-0001.html 

From issues at jboss.org  Sun May  3 05:48:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 05:48:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6035.1430646525953@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064798#comment-13064798 ] 

Martin Andersson commented on CDI-520:
--------------------------------------

Mark, thank you for your comment. Appreciative that. You wrote:

{quote}
[..] but the EJB and EE umbrella specs only define that this EntityManager works inside an EJB (read section about TransactionManagementType.CONTAINER).
{quote}

I don't agree with this as far as my understanding goes. The JPA specification does not restrict where an entity manager is used.

JPA 2.1, section "7.2.1. Obtaining an Entity Manager in the Java EE Environment":

{quote}
A container-managed entity manager is obtained by the application through dependency injection or through direct lookup of the entity manager in the JNDI namespace. The container manages the persistence context lifecycle and the creation and the closing of the entity manager instance transparently to the application.
{quote}

Nor does the umbrella specification restrict where an entity manager is used, as long as you inject the entity manager into a [managed bean|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/cdi/package-info.java#L68].

Java Platform, Enterprise Edition Specification v7 (JSR-342), section "EE.5.14.1.1 Injection of Persistence Context References":

{quote}
A field or a method of an application component may be annotated with the PersistenceContext annotation.
{quote}

Managed Beans 1.0 (JSR-316), section "MB.2.1.3 Lifecycle and Resource Injection":

{quote}
In a Java EE implementation, a Managed Bean may use any of the resource injection functionality laid out in Chapter EE.5 of the Java EE Platform specification, "Resources, Naming and Injection".
{quote}

Speaking of EJB:s, the EJB specification does not restrict any EJB component type from injecting the entity manager. See EJB 3.2 specification, sections 11.11.1.1., 4.6.2, 4.7.2, 4.8.6, and 5.5.1.

I could not find what section you referred to. I would be a bit shocked if the EJB specification limit any other specification. The persistence context is not even defined by EJB.

Java Platform, Enterprise Edition Specification v7 (JSR-342), section "EE.5 Resources, Naming, and Injection":

{quote}
The PersistenceUnit and PersistenceContext annotations described here are defined in more detail in the Java Persistence specification.
{quote}

You're example of using CDI to look up an _application-managed_ entity manager is a valid one. If all container-managed entity managers share the same entity manager factory (persistence unit), then there are little to no use of using CDI to look up a container-managed entity manager. A too wide CDI scope may in fact expose the entity manager reference to many threads which violate the programming model outlined in JPA. Furthermore, a CDI disposer method must never close a container-managed entity manager. Please read the provided links in my last comment if you want to read my full research on this topic.

> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sun May  3 06:49:46 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sun, 3 May 2015 06:49:46 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6048.1430650186236@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064799#comment-13064799 ] 

Mark Struberg commented on CDI-520:
-----------------------------------

a.) there is not _the_ EntityManager, there are in fact a few of them. E.g. the 'native' one from JPA vs the 'Facade' you get when using @PersistenceContext in EJBs. The later is really just a facade which delegates to the 'real' EM which he gets from the TransactionSynchronizationRegistry [1] (This is why the getDelegate() method exists btw). And the point is that this mapping gets basically maintained by the EJB container.

b.) The EJB spec clearly says in chapter 13, esp 13.2.5 'Container-Managed Demarcation' and 13.3.3 'Enterprise Beans Using Bean-Managed Transaction Demarcation' that container-managed and bean-managed transactions are only defined for 'enterprise beans'. Please note that 'enterprise beans' are ONLY javax.ejb beans and _not_ the rest which is subsummed under the more generic term 'managed beans'.

c.) there is no other spec which defines how transaction demarcation works for EE 'Managed Beans' (btw there are many different 'Managed Beans' in EE still...)

I'm not saying this for fun but because I know a few containers which will blow up if you access a @PersistenceContext EntityManager without being in the call frame of any EJB. It might work for a few, but not that: "You are now leaving the portable sector" :D

Feel free to get this fixed/clarified for EE-8 :)

[1] http://docs.oracle.com/javaee/6/api/javax/transaction/TransactionSynchronizationRegistry.html

> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sun May  3 06:55:45 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Sun, 3 May 2015 06:55:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6053.1430650545988@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064799#comment-13064799 ] 

Mark Struberg edited comment on CDI-520 at 5/3/15 6:55 AM:
-----------------------------------------------------------

a.) there is not _the_ EntityManager, there are in fact a few of them. E.g. the 'native' one from JPA vs the 'Facade' you get when using @PersistenceContext in managed beans. The later is really just a facade which delegates to the 'real' EM which he gets from the TransactionSynchronizationRegistry [1] (This is why the getDelegate() method exists btw). And the point is that this mapping gets basically maintained by the EJB container.

b.) The EJB spec clearly says in chapter 13, esp 13.2.5 'Container-Managed Demarcation' and 13.3.3 'Enterprise Beans Using Bean-Managed Transaction Demarcation' that container-managed and bean-managed transactions are only defined for 'enterprise beans'. Please note that 'enterprise beans' are ONLY javax.ejb beans and _not_ the rest which is subsummed under the more generic term 'managed beans'.

c.) there is no other spec which defines how transaction demarcation works for EE 'Managed Beans' (btw there are many different 'Managed Beans' in EE still...)
*edit* To make this more clear: a few specs define that you can inject an EntityManager into managed beans. But only the EJB spec defines how that EntityManager gets instrumented. And it only defines the behaviour for EJBs itself.

I'm not saying this for fun but because I know a few containers which will blow up if you access a @PersistenceContext EntityManager without being in the call frame of any EJB. It might work for a few, but not that: "You are now leaving the portable sector" :D

Feel free to get this fixed/clarified for EE-8 :)

[1] http://docs.oracle.com/javaee/6/api/javax/transaction/TransactionSynchronizationRegistry.html


was (Author: struberg):
a.) there is not _the_ EntityManager, there are in fact a few of them. E.g. the 'native' one from JPA vs the 'Facade' you get when using @PersistenceContext in EJBs. The later is really just a facade which delegates to the 'real' EM which he gets from the TransactionSynchronizationRegistry [1] (This is why the getDelegate() method exists btw). And the point is that this mapping gets basically maintained by the EJB container.

b.) The EJB spec clearly says in chapter 13, esp 13.2.5 'Container-Managed Demarcation' and 13.3.3 'Enterprise Beans Using Bean-Managed Transaction Demarcation' that container-managed and bean-managed transactions are only defined for 'enterprise beans'. Please note that 'enterprise beans' are ONLY javax.ejb beans and _not_ the rest which is subsummed under the more generic term 'managed beans'.

c.) there is no other spec which defines how transaction demarcation works for EE 'Managed Beans' (btw there are many different 'Managed Beans' in EE still...)

I'm not saying this for fun but because I know a few containers which will blow up if you access a @PersistenceContext EntityManager without being in the call frame of any EJB. It might work for a few, but not that: "You are now leaving the portable sector" :D

Feel free to get this fixed/clarified for EE-8 :)

[1] http://docs.oracle.com/javaee/6/api/javax/transaction/TransactionSynchronizationRegistry.html

> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sun May  3 08:24:46 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 08:24:46 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6057.1430655886072@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064800#comment-13064800 ] 

Martin Andersson commented on CDI-520:
--------------------------------------

Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..

The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.

EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

The EJB container use the _transaction manager_ to control transaction demarcation.

JTA 1.2, ?3.2:

{quote}
**For example**, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread?s transaction context.
{quote}

JTA 1.2, ?3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.

This interface is implemented by the application server as a stateless service object. The same object can be used **by any number of components** with complete thread safety.
{quote}

The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#getDelegate()]", may be retrieved using {{EntityManager.getDelegate()}}.

Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.

JTA 1.2 ?1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.

\[..]

A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}

JTA 1.2 ?2.1:

{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}

JTA 1.2 ?3.7:

{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}

The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.

I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.

It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?

Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.


> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Sun May  3 08:25:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 08:25:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6061.1430655945718@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064800#comment-13064800 ] 

Martin Andersson edited comment on CDI-520 at 5/3/15 8:25 AM:
--------------------------------------------------------------

Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..

The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.

EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

The EJB container use the _transaction manager_ to control transaction demarcation.

JTA 1.2, ?3.2:

{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread?s transaction context.
{quote}

JTA 1.2, ?3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.

This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}

The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#getDelegate()]", may be retrieved using {{EntityManager.getDelegate()}}.

Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.

JTA 1.2 ?1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.

\[..]

A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}

JTA 1.2 ?2.1:

{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}

JTA 1.2 ?3.7:

{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}

The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.

I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.

It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?

Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.



was (Author: martin.andersson):
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..

The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.

EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

The EJB container use the _transaction manager_ to control transaction demarcation.

JTA 1.2, ?3.2:

{quote}
**For example**, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread?s transaction context.
{quote}

JTA 1.2, ?3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.

This interface is implemented by the application server as a stateless service object. The same object can be used **by any number of components** with complete thread safety.
{quote}

The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#getDelegate()]", may be retrieved using {{EntityManager.getDelegate()}}.

Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.

JTA 1.2 ?1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.

\[..]

A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}

JTA 1.2 ?2.1:

{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}

JTA 1.2 ?3.7:

{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}

The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.

I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.

It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?

Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.


> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Sun May  3 09:04:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 09:04:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-520) 3.6. Java EE components
In-Reply-To: <JIRA.12568875.1429551037000@Atlassian.JIRA>
References: <JIRA.12568875.1429551037000@Atlassian.JIRA>
	<JIRA.12568875.1429551037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568875.1429551037000.6065.1430658285872@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064800#comment-13064800 ] 

Martin Andersson edited comment on CDI-520 at 5/3/15 9:04 AM:
--------------------------------------------------------------

Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..

The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.

EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

The EJB container use the _transaction manager_ to control transaction demarcation.

JTA 1.2, ?3.2:

{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread?s transaction context.
{quote}

JTA 1.2, ?3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.

This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}

The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#getDelegate()]", may be retrieved using {{EntityManager.getDelegate()}}.

Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.

JTA 1.2 ?1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.

\[..]

A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}

JTA 1.2 ?2.1:

{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}

JTA 1.2 ?3.7:

{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on *CDI managed beans, as well as classes defined as managed beans* by the Java EE specification \[..].
{quote}

The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.

I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.

It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?

Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.



was (Author: martin.andersson):
Mark, I have a hard time trying to understand why you speak mostly about transactions. Also I think you are a bit off looking at the details. I'm a "standards guy" and I have no experience implementing a real Java EE server or containers within. So please correct me if I am wrong, but..

The {{TransactionSynchronizationRegistry}} interface is what you'd call a "facade" for the _transaction manager_; how to enlist transaction-aware resources. This interface has no ability to create an entity manager. The entity manager implementation is provided by the EJB container _or_ a third-party persistence provider.

EJB 3.2, section "11.10.4 Container Provider Responsibility":
{quote}
The EJB Container Provider is responsible for the following: \[..] Provide the implementation of the entity manager factory classes for the persistence units that are configured with the EJB container. The implementation of the entity manager factory classes may be provided by the container directly or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

EJB 3.2, section "11.11.4 Container Provider Responsibility":
{quote}
Provide the implementation of the entity manager classes for the persistence units that are configured with the EJB container. This implementation may be provided by the container directory or by the container in conjunction with a third-party persistence provider, as described in \[Java Persistence API, version 2.1].
{quote}

The EJB container use the _transaction manager_ to control transaction demarcation.

JTA 1.2, ?3.2:

{quote}
*For example*, the EJB container manages the transaction states for transactional EJB components; the container uses the TransactionManager interface mainly to demarcate transaction boundaries where operations affect the calling thread?s transaction context.
{quote}

JTA 1.2, ?3.6:
{quote}
The javax.transaction.TransactionSynchronizationRegistry interface is intended for use by system level application server components such as persistence managers. This provides the ability to register synchronization objects with special ordering semantics, associate resource objects with the current transaction, get the transaction context of the current transaction, get current transaction status, and mark the current transaction for rollback.

This interface is implemented by the application server as a stateless service object. The same object can be used *by any number of components* with complete thread safety.
{quote}

The entity manager delegate, "[if available|http://docs.oracle.com/javaee/7/api/javax/persistence/EntityManager.html#getDelegate()]", may be retrieved using {{EntityManager.getDelegate()}}.

Bean-managed transaction demarcation is semantics that applies to EJB:s only, meaning that the EJB component does not want the default container-managed semantics to apply. Container-managed transactions is semantics that used to apply for EJB:s only, but since Java EE 7 (JTA 1.2), even CDI- as well as managed beans may use this service if annotated {{@Transactional}}. This is the ultimate "proof" that transactions themselves are in no way limited to EJB:s only.

JTA 1.2 ?1.1:
{quote}
An application server (or TP monitor) provides the infrastructure required to support the application run-time environment which includes transaction state management. An example of such an application server is an EJB server.

\[..]

A component-based transactional application that is developed to operate in a modern application server environment relies on the application server to provide transaction management support through declarative transaction attribute settings. An example of this type of applications is an application developed using the industry standard Enterprise JavaBeans (EJB) component architecture. In addition, some other stand-alone Java client programs may wish to control their transaction boundaries using a high-level interface provided by the application server or the transaction manager.
{quote}

JTA 1.2 ?2.1:

{quote}
The UserTransaction interface is intended to be used by both the enterprise bean implementer (for beans with bean-managed transactions) and by the client programmer that wants to explicitly demarcate transaction boundaries within programs that are written in the Java programming language.
{quote}

JTA 1.2 ?3.7:

{quote}
The javax.transaction.Transactional annotation provides the application the ability to declaratively control transaction boundaries on **CDI managed beans, as well as classes defined as managed beans** by the Java EE specification \[..].
{quote}

The managed beans specification said that I can use **all resources listed in the umbrella specification chapter 5**. Among those resources is {{UserTransaction}} and {{TransactionSynchronizationRegistry}}, and of course the entity manager - whoever is the one providing the entity manager implementation. Transactions and the entity manager is two different things and both can be used outside the world of EJB:s. Application-managed entity managers are not even limited to JTA transactions only but could use resource-local transactions where the JDBC driver is the only transaction-aware resource.

I tried to find what it is you're referring to in the EJB specification. I think you're using an old specification, chapter 13 in EJB 3.2 is about the timer service. I read chapter 8 in EJB 3.2, and I still can't find that this specification forbid the use of transactions (or entity managers) outside EJB:s. And I still think that if the EJB specification limit transactions and/or entity managers to EJB:s only, then that is a serious issue which should be fixed.

It could very well be that given the history where JPA was entity beans defined in EJB, many containers still have a hard time providing entity managers that live well outside EJB components. It would be very useful for me if you know exactly which containers has this problem. Sooner or later, I think EJB:s should be pruned. All services they offer should be moved to standalone services a bean developer can explicitly use if he want to. Maybe the bean developer can use predefined CDI stereotypes if he want to apply a hole batch of services at once. In particular, I don't think it should be standardized which container has the responsibility to provide entity manager implementations other than then the "Java EE application server provider"?

Everything in the Java EE technology stack is a bit of a mess of course =) If you ask me, we should wipe them all out and start from scratch again.


> 3.6. Java EE components
> -----------------------
>
>                 Key: CDI-520
>                 URL: https://issues.jboss.org/browse/CDI-520
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Java EE integration
>    Affects Versions: 1.1.Final
>            Reporter: Martin Andersson
>             Fix For: TBD
>
>
> I don't understand this text:
> "The instance used by the container to service an invocation of a Java EE component will not be the same instance obtained when using @Inject, instantiated by the container to invoke a producer method, observer method or disposer method, or instantiated by the container to access the value of a producer field."
> More specifically, I am trying to understand how we can use CDI to put a scope on {{EntityManager}} whose life cycle is rather undefined by JPA. I see that the specification use an example of a {{@Disposes}} method to close a container-managed entity manager which throw {{IllegalStateException}} in the disposer (!). Anyways, trying to solve this puzzle has led me to the paragraph quoted previously, of which I understand nothing to be honest.
> My research about the "CDI managed container-managed entity manager" continues. As of now, the example is flawed and a container-managed entity manager remains open after the disposer method. Anyways, I might open up a separate ticket for that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


From issues at jboss.org  Sun May  3 09:09:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 09:09:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-524) Section "1.2.1. Relationship to
 the Java EE platform specification".
In-Reply-To: <JIRA.12570553.1430658556000@Atlassian.JIRA>
References: <JIRA.12570553.1430658556000@Atlassian.JIRA>
	<JIRA.12570553.1430658556100@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570553.1430658556000.6066.1430658585537@Atlassian.JIRA>

Martin Andersson created CDI-524:
------------------------------------

             Summary: Section "1.2.1. Relationship to the Java EE platform specification".
                 Key: CDI-524
                 URL: https://issues.jboss.org/browse/CDI-524
             Project: CDI Specification Issues
          Issue Type: Epic
    Affects Versions: 1.2.Final
            Reporter: Martin Andersson
            Priority: Minor


Section "1.2.1. Relationship to the Java EE platform specification" says:

{quote}
In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service.
{quote}

The reference should be made to EE 7?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Sun May  3 09:09:45 2015
From: issues at jboss.org (Martin Andersson (JIRA))
Date: Sun, 3 May 2015 09:09:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-524) CDI spec make reference to Java EE
	6.
In-Reply-To: <JIRA.12570553.1430658556000@Atlassian.JIRA>
References: <JIRA.12570553.1430658556000@Atlassian.JIRA>
	<JIRA.12570553.1430658556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570553.1430658556000.6067.1430658585707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Andersson updated CDI-524:
---------------------------------
    Summary: CDI spec make reference to Java EE 6.  (was: Section "1.2.1. Relationship to the Java EE platform specification".)


> CDI spec make reference to Java EE 6.
> -------------------------------------
>
>                 Key: CDI-524
>                 URL: https://issues.jboss.org/browse/CDI-524
>             Project: CDI Specification Issues
>          Issue Type: Epic
>    Affects Versions: 1.2.Final
>            Reporter: Martin Andersson
>            Priority: Minor
>
> Section "1.2.1. Relationship to the Java EE platform specification" says:
> {quote}
> In the Java EE 6 environment, all component classes supporting injection, as defined by the Java EE 6 platform specification, may inject beans via the dependency injection service.
> {quote}
> The reference should be made to EE 7?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From emijiang6 at googlemail.com  Sun May  3 16:44:41 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Sun, 3 May 2015 21:44:41 +0100
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
Message-ID: <CAECq3A-B0-Euk=q2UUGiLqCX6LFPdVPVzX_JimXS3C+_h-hbNA@mail.gmail.com>

I have a further thought on this. If we use section 5, a module is the unit
of bean archive. All jars on the module's classpath and web-inf\lib (for
war) are merged together to form a bean archive. This maintains backward
compatibility but implicit bean archives are not useful as the archives are
too coarse-grained.

If we use section 12, each jar is a bean archive. In this way, the implicit
bean archives are fully utilised. However, this breaks backward
compatibility with cdi 1.0. In a EE module, all classpath jars and
web-inf\lib jars are treated bean archives pending scanning. However, if
they don't have bean defining annotations, they are excluded from the bean
archives. Hence some injection may fail to resolve. This change needs to go
to CDI 2 as it introduces backward incompatible changes.

In light of this, section 5 should be used. Thougths?

On Sat, May 2, 2015 at 11:20 PM, Emily Jiang <emijiang6 at googlemail.com>
wrote:

> 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 at googlemail.com>
> Date: Sat, May 2, 2015 at 10:21 PM
> Subject: Re: [cdi-dev] bean archives
> To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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 at 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 at apache.org
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>



-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150503/30877474/attachment-0001.html 

From jharting at redhat.com  Mon May  4 03:07:36 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 04 May 2015 09:07:36 +0200
Subject: [cdi-dev] Fwd:  bean archives
In-Reply-To: <CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
Message-ID: <55471AB8.5020900@redhat.com>

Yes, chapter 5 is a bit confusing when it comes to composite Java EE 
modules. Comments inline:

On 05/03/2015 12:20 AM, Emily Jiang wrote:
> 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.
The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented. 
Therefore, implementing bean archive as defined in Chapter 12 is the 
right approach for a Weld integrator.
>
> 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 at googlemail.com 
> <mailto:emijiang6 at googlemail.com>>
> Date: Sat, May 2, 2015 at 10:21 PM
> Subject: Re: [cdi-dev] bean archives
> To: Mark Struberg <struberg at yahoo.de <mailto:struberg at 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 at yahoo.de 
> <mailto:struberg at 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 at sabot-durand.net <mailto:antoine at 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 at googlemail.com
>         <mailto:emijiang6 at 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 at apache.org <mailto:ejiang at apache.org>
>>         _______________________________________________
>>         cdi-dev mailing list
>>         cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at apache.org <mailto:ejiang at apache.org>
>
>
>
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/7ab68f97/attachment-0001.html 

From jharting at redhat.com  Mon May  4 03:14:58 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 04 May 2015 09:14:58 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A-B0-Euk=q2UUGiLqCX6LFPdVPVzX_JimXS3C+_h-hbNA@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<CAECq3A-B0-Euk=q2UUGiLqCX6LFPdVPVzX_JimXS3C+_h-hbNA@mail.gmail.com>
Message-ID: <55471C72.3000504@redhat.com>

On 05/03/2015 10:44 PM, Emily Jiang wrote:
>
> If we use section 12, each jar is a bean archive. In this way, the 
> implicit bean archives are fully utilised. However, this breaks 
> backward compatibility with cdi 1.0.
How does it break compatibility?

From struberg at yahoo.de  Mon May  4 03:59:30 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Mon, 4 May 2015 09:59:30 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <55471AB8.5020900@redhat.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
Message-ID: <B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>

The CDI-1.0 TCK initially did not check anything in that regard. A test got added in a _very_ late version. This was in fact released AFTER CDI-1.1 was published if I remember correctly. So this version is not even part of the EE6 TCK?

LieGrue,
strub

> Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting at redhat.com>:
> 
> Yes, chapter 5 is a bit confusing when it comes to composite Java EE modules. Comments inline:
> 
> On 05/03/2015 12:20 AM, Emily Jiang wrote:
>> 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.
> The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented. Therefore, implementing bean archive as defined in Chapter 12 is the right approach for a Weld integrator.
>> 
>> 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 at googlemail.com>
>> Date: Sat, May 2, 2015 at 10:21 PM
>> Subject: Re: [cdi-dev] bean archives
>> To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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 at 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 at apache.org
>> 
>> 
>> 
>> -- 
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang at apache.org
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> 
>> cdi-dev at 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 at 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.



From antoine at sabot-durand.net  Mon May  4 09:42:43 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Mon, 4 May 2015 15:42:43 +0200
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
Message-ID: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>

Hi all,

For this week meeting, I?d like to have a focus on SE boot and John PR : https://github.com/cdi-spec/cdi/pull/243 <https://github.com/cdi-spec/cdi/pull/243>

Take a moment to read his proposal and  make your comment if you have some.

If we have time left we?ll go back on Event ordering and Mark P. PR : https://github.com/cdi-spec/cdi/pull/242

Regards,

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/11dd71f8/attachment.html 
-------------- 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/20150504/11dd71f8/attachment.bin 

From mjremijan at yahoo.com  Mon May  4 10:33:11 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Mon, 4 May 2015 14:33:11 +0000 (UTC)
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
In-Reply-To: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>
References: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>
Message-ID: <845586883.1067552.1430749991999.JavaMail.yahoo@mail.yahoo.com>

What are the details of the meeting? ?I'd like to attend if possible.


     On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <antoine at sabot-durand.net> wrote:
   

 Hi all,
For this week meeting, I?d like to have a focus on SE boot and John PR : https://github.com/cdi-spec/cdi/pull/243
Take a moment to read his proposal and ?make your comment if you have some.
If we have time left we?ll go back on Event ordering and Mark P. PR :?https://github.com/cdi-spec/cdi/pull/242
Regards,
Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev at 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.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/8b78d8ab/attachment.html 

From mjremijan at yahoo.com  Mon May  4 11:49:56 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Mon, 4 May 2015 15:49:56 +0000 (UTC)
Subject: [cdi-dev] Observer ordering
Message-ID: <2006485403.1128053.1430754596690.JavaMail.yahoo@mail.yahoo.com>

Hi everyone,
Is Observer ordering available yet in the RI?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/d4d5f5d6/attachment.html 

From ggastald at redhat.com  Mon May  4 11:57:40 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Mon, 04 May 2015 12:57:40 -0300
Subject: [cdi-dev] Observer ordering
In-Reply-To: <2006485403.1128053.1430754596690.JavaMail.yahoo@mail.yahoo.com>
References: <2006485403.1128053.1430754596690.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <554796F4.2020907@redhat.com>

Hi Michael,

Yes, it is available using the org.jboss.weld.experimental.Priority 
annotation.
Eg:

    public void observeEvent(@Observes @Priority(1) String event)
    {
       System.out.println("OBSERVED: " + event);
    }

Best Regards,

George Gastaldi


On 05/04/2015 12:49 PM, Michael Remijan wrote:
> Hi everyone,
>
> Is Observer ordering available yet in the RI?
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/9da576b8/attachment.html 

From mjremijan at yahoo.com  Mon May  4 12:05:34 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Mon, 4 May 2015 16:05:34 +0000 (UTC)
Subject: [cdi-dev] Observer ordering
In-Reply-To: <554796F4.2020907@redhat.com>
References: <2006485403.1128053.1430754596690.JavaMail.yahoo@mail.yahoo.com>
	<554796F4.2020907@redhat.com>
Message-ID: <1465371623.1177161.1430755534470.JavaMail.yahoo@mail.yahoo.com>

Great, thanks. ?I going to plug that into my application this iteration. 


     On Monday, May 4, 2015 10:58 AM, George Gastaldi <ggastald at redhat.com> wrote:
   

  Hi Michael,
 
 Yes, it is available using the org.jboss.weld.experimental.Priority annotation.
 Eg: 
 
 ?? public void observeEvent(@Observes @Priority(1) String event)
 ?? {
 ????? System.out.println("OBSERVED: " + event);
 ?? }
 
 Best Regards,
 
 George Gastaldi
 
 
 On 05/04/2015 12:49 PM, Michael Remijan wrote:
  
  Hi everyone, 
  Is Observer ordering available yet in the RI?  
  
 _______________________________________________
cdi-dev mailing list
cdi-dev at 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 at 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.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/1270a6ba/attachment-0001.html 

From issues at jboss.org  Mon May  4 12:20:48 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Mon, 4 May 2015 12:20:48 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-129) Clarify behaviour of
 @ApplicationScoped in EARs
In-Reply-To: <JIRA.12437380.1305278142000@Atlassian.JIRA>
References: <JIRA.12437380.1305278142000@Atlassian.JIRA>
	<JIRA.12437380.1305278142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437380.1305278142000.8139.1430756448888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-129:
-------------------------------------
    Fix Version/s: 2.0 (discussion)
                       (was: TBD)


> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
>                 Key: CDI-129
>                 URL: https://issues.jboss.org/browse/CDI-129
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>          Components: Contexts
>    Affects Versions: 1.0
>            Reporter: Mark Struberg
>            Assignee: Pete Muir
>              Labels: application-scoped, visibility
>             Fix For: 2.0 (discussion)
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From emijiang6 at googlemail.com  Mon May  4 17:52:15 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Mon, 4 May 2015 22:52:15 +0100
Subject: [cdi-dev] bean archives
In-Reply-To: <B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
Message-ID: <CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>

ah. ok. For cdi 1.0, if all the implementor checks all jars having
beans.xml and then merge the classes to the module bean archive, this will
be fine. I think a spec issue will be raised to update section 5.

On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg at yahoo.de> wrote:

> The CDI-1.0 TCK initially did not check anything in that regard. A test
> got added in a _very_ late version. This was in fact released AFTER CDI-1.1
> was published if I remember correctly. So this version is not even part of
> the EE6 TCK?
>
> LieGrue,
> strub
>
> > Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting at redhat.com>:
> >
> > Yes, chapter 5 is a bit confusing when it comes to composite Java EE
> modules. Comments inline:
> >
> > On 05/03/2015 12:20 AM, Emily Jiang wrote:
> >> 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.
> > The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented.
> Therefore, implementing bean archive as defined in Chapter 12 is the right
> approach for a Weld integrator.
> >>
> >> 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 at googlemail.com>
> >> Date: Sat, May 2, 2015 at 10:21 PM
> >> Subject: Re: [cdi-dev] bean archives
> >> To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at 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 at 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 at apache.org
> >>
> >>
> >>
> >> --
> >> Thanks
> >> Emily
> >> =================
> >> Emily Jiang
> >> ejiang at apache.org
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >>
> >> cdi-dev at 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 at 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 at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/d333132b/attachment.html 

From john.d.ament at gmail.com  Mon May  4 19:58:03 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 04 May 2015 23:58:03 +0000
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
In-Reply-To: <845586883.1067552.1430749991999.JavaMail.yahoo@mail.yahoo.com>
References: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>
	<845586883.1067552.1430749991999.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAOqetn-x7=t46ioxZTGST=3yH_81NKe8H826LOrjctMxX=mFgg@mail.gmail.com>

It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.

On Mon, May 4, 2015 at 10:33 AM Michael Remijan <mjremijan at yahoo.com> wrote:

> What are the details of the meeting?  I'd like to attend if possible.
>
>
>
>   On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>
> Hi all,
>
> For this week meeting, I?d like to have a focus on SE boot and John PR :
> https://github.com/cdi-spec/cdi/pull/243
>
> Take a moment to read his proposal and  make your comment if you have some.
>
> If we have time left we?ll go back on Event ordering and Mark P. PR :
> https://github.com/cdi-spec/cdi/pull/242
>
> Regards,
>
> Antoine
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150504/29b4ad47/attachment.html 

From jharting at redhat.com  Tue May  5 01:06:27 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 05 May 2015 07:06:27 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>	<55471AB8.5020900@redhat.com>	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
Message-ID: <55484FD3.6000100@redhat.com>

No, it's not the case that "all CDI 1.0 implementor checks all jars 
having beans.xml and then merge the classes to the module bean archive". 
Some CDI 1.0 implementations implement the spec properly including the 
fine granularity of Chapter 12, some don't and since the TCK for CDI 1.0 
is does not test much in this area it allows both groups to pass. That 
was fixed in subsequent TCK releases.

On 05/04/2015 11:52 PM, Emily Jiang wrote:
> ah. ok. For cdi 1.0, if all the implementor checks all jars having 
> beans.xml and then merge the classes to the module bean archive, this 
> will be fine. I think a spec issue will be raised to update section 5.
>
> On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg at yahoo.de 
> <mailto:struberg at yahoo.de>> wrote:
>
>     The CDI-1.0 TCK initially did not check anything in that regard. A
>     test got added in a _very_ late version. This was in fact released
>     AFTER CDI-1.1 was published if I remember correctly. So this
>     version is not even part of the EE6 TCK?
>
>     LieGrue,
>     strub
>
>     > Am 04.05.2015 um 09:07 schrieb Jozef Hartinger
>     <jharting at redhat.com <mailto:jharting at redhat.com>>:
>     >
>     > Yes, chapter 5 is a bit confusing when it comes to composite
>     Java EE modules. Comments inline:
>     >
>     > On 05/03/2015 12:20 AM, Emily Jiang wrote:
>     >> 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.
>     > The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be
>     implemented. Therefore, implementing bean archive as defined in
>     Chapter 12 is the right approach for a Weld integrator.
>     >>
>     >> 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 at googlemail.com
>     <mailto:emijiang6 at googlemail.com>>
>     >> Date: Sat, May 2, 2015 at 10:21 PM
>     >> Subject: Re: [cdi-dev] bean archives
>     >> To: Mark Struberg <struberg at yahoo.de <mailto:struberg at 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 at yahoo.de <mailto:struberg at 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 at sabot-durand.net <mailto:antoine at 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 at googlemail.com
>     <mailto:emijiang6 at 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 at apache.org <mailto:ejiang at apache.org>
>     >>> _______________________________________________
>     >>> cdi-dev mailing list
>     >>> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at apache.org <mailto:ejiang at apache.org>
>     >>
>     >>
>     >>
>     >> --
>     >> Thanks
>     >> Emily
>     >> =================
>     >> Emily Jiang
>     >> ejiang at apache.org <mailto:ejiang at apache.org>
>     >>
>     >>
>     >> _______________________________________________
>     >> cdi-dev mailing list
>     >>
>     >> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at apache.org <mailto:ejiang at apache.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/c2231cc6/attachment-0001.html 

From antoine at sabot-durand.net  Tue May  5 01:55:14 2015
From: antoine at sabot-durand.net (antoine at sabot-durand.net)
Date: Tue, 05 May 2015 05:55:14 +0000
Subject: [cdi-dev] Updated Invitation: CDI weekly meeting @ Weekly from
 18:00 to 19:00 on Tuesday (ASD Perso)
Message-ID: <14dae9cc9c7286c24205154f52a0@google.com>

This event has been changed.

Title: CDI weekly meeting
Weekly meeting of the CDI EG and other community members discussing CDI 2.0  
specification. (changed)
When: Weekly from 18:00 to 19:00 on Tuesday Paris
Where: IRC #cdi-dev channel on freenode
Calendar: ASD Perso
Who:
     * Antoine Sabot-Durand - organizer
     * cdi-dev

Event details:  
https://www.google.com/calendar/event?action=VIEW&eid=XzcxMGpnZ3BrNjEwamliOXA2OHNrNGI5azY0cjM0YmExOGNzajBiOW02MTIzYWgxZzcwb2phZ2hsNm8gY2RpLWRldkBsaXN0cy5qYm9zcy5vcmc&tok=MjQjYW50b2luZUBzYWJvdC1kdXJhbmQubmV0Y2Q1YmEzMjU2NzNhZjM4MTFkMDQ5MWU4MjhiYzg2NWUyYjU4YWJhYg&ctz=Europe/Paris&hl=en

Invitation from Google Calendar: https://www.google.com/calendar/

You are receiving this courtesy email at the account  
cdi-dev at lists.jboss.org because you are an attendee of this event.

To stop receiving future updates for this event, decline this event.  
Alternatively you can sign up for a Google account at  
https://www.google.com/calendar/ and control your notification settings for  
your entire calendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/ca8ad14b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/calendar
Size: 1831 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/ca8ad14b/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: invite.ics
Type: application/ics
Size: 1887 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/ca8ad14b/attachment-0001.bin 

From antoine at sabot-durand.net  Tue May  5 01:57:13 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 5 May 2015 07:57:13 +0200
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
In-Reply-To: <CAOqetn-x7=t46ioxZTGST=3yH_81NKe8H826LOrjctMxX=mFgg@mail.gmail.com>
References: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>
	<845586883.1067552.1430749991999.JavaMail.yahoo@mail.yahoo.com>
	<CAOqetn-x7=t46ioxZTGST=3yH_81NKe8H826LOrjctMxX=mFgg@mail.gmail.com>
Message-ID: <BB5C00CC-06B0-49C4-B96C-D2DB86D6138D@sabot-durand.net>

I?ve just resen an invite to the list.


> Le 5 mai 2015 ? 01:58, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.
> 
> On Mon, May 4, 2015 at 10:33 AM Michael Remijan <mjremijan at yahoo.com <mailto:mjremijan at yahoo.com>> wrote:
> What are the details of the meeting?  I'd like to attend if possible.
> 
> 
> 
> On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
> 
> 
> Hi all,
> 
> For this week meeting, I?d like to have a focus on SE boot and John PR : https://github.com/cdi-spec/cdi/pull/243 <https://github.com/cdi-spec/cdi/pull/243>
> 
> Take a moment to read his proposal and  make your comment if you have some.
> 
> If we have time left we?ll go back on Event ordering and Mark P. PR : https://github.com/cdi-spec/cdi/pull/242 <https://github.com/cdi-spec/cdi/pull/242>
> 
> Regards,
> 
> Antoine
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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 at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/fb8b9bcb/attachment.html 
-------------- 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/20150505/fb8b9bcb/attachment.bin 

From emijiang6 at googlemail.com  Tue May  5 04:19:00 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Tue, 5 May 2015 09:19:00 +0100
Subject: [cdi-dev] bean archives
In-Reply-To: <55484FD3.6000100@redhat.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
	<55484FD3.6000100@redhat.com>
Message-ID: <CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>

In this case, the spec section 5 will just need to be updated then.

On Tue, May 5, 2015 at 6:06 AM, Jozef Hartinger <jharting at redhat.com> wrote:

>  No, it's not the case that "all CDI 1.0 implementor checks all jars
> having beans.xml and then merge the classes to the module bean archive".
> Some CDI 1.0 implementations implement the spec properly including the fine
> granularity of Chapter 12, some don't and since the TCK for CDI 1.0 is does
> not test much in this area it allows both groups to pass. That was fixed in
> subsequent TCK releases.
>
>
> On 05/04/2015 11:52 PM, Emily Jiang wrote:
>
> ah. ok. For cdi 1.0, if all the implementor checks all jars having
> beans.xml and then merge the classes to the module bean archive, this will
> be fine. I think a spec issue will be raised to update section 5.
>
> On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg at yahoo.de> wrote:
>
>> The CDI-1.0 TCK initially did not check anything in that regard. A test
>> got added in a _very_ late version. This was in fact released AFTER CDI-1.1
>> was published if I remember correctly. So this version is not even part of
>> the EE6 TCK?
>>
>> LieGrue,
>> strub
>>
>> > Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting at redhat.com>:
>> >
>> > Yes, chapter 5 is a bit confusing when it comes to composite Java EE
>> modules. Comments inline:
>> >
>> > On 05/03/2015 12:20 AM, Emily Jiang wrote:
>> >> 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.
>> > The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented.
>> Therefore, implementing bean archive as defined in Chapter 12 is the right
>> approach for a Weld integrator.
>> >>
>> >> 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 at googlemail.com>
>> >> Date: Sat, May 2, 2015 at 10:21 PM
>> >> Subject: Re: [cdi-dev] bean archives
>> >> To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
>> >>> _______________________________________________
>> >>> cdi-dev mailing list
>> >>> cdi-dev at 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 at 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 at apache.org
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks
>> >> Emily
>> >> =================
>> >> Emily Jiang
>> >> ejiang at apache.org
>> >>
>> >>
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >>
>> >> cdi-dev at 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 at 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 at apache.org
>
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/3aaf5eee/attachment-0001.html 

From struberg at yahoo.de  Tue May  5 05:38:53 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Tue, 5 May 2015 11:38:53 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
	<55484FD3.6000100@redhat.com>
	<CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>
Message-ID: <BB0DD0C4-0FBD-4434-BA45-C2EFEB18BDF5@yahoo.de>

> Some CDI 1.0 implementations implement the spec properly including the fine granularity of 
> Chapter 12, some don?t and since the TCK for CDI 1.0 is does not test much in this area it 
> allows both groups to pass.

That?s factually wrong. Section 5 defines BDA different than Section 12. This is an unresolved issue until today. 


> In this case, the spec section 5 will just need to be updated then.

Or section 12. 

Both ways are perfectly backward incompatible. If you drop BDA in section 5 then you break EE modularity and compatibility to EE6 servers (incuding RI). If you drop BDA in section 12 then you break scanning.

We really need to handle this carefully.

Imo we should finally accept that there are 2 different ?BDA? use cases and they both need a different Term. What about using the term BDA for section 12 and only for scanning. And the term ?EE module? for section 5 (visibility) + interceptors, alternatives and decorators. That is basically how the EE6 RI behaved and what is the best for users. It also allows for _much_ better performance! And also please acknowledge the Alternatives-per-JAR is a major PITA in _real_ projects.

LieGrue,
strub


> Am 05.05.2015 um 10:19 schrieb Emily Jiang <emijiang6 at googlemail.com>:
> 
> In this case, the spec section 5 will just need to be updated then.
> 
> On Tue, May 5, 2015 at 6:06 AM, Jozef Hartinger <jharting at redhat.com> wrote:
> No, it's not the case that "all CDI 1.0 implementor checks all jars having beans.xml and then merge the classes to the module bean archive". Some CDI 1.0 implementations implement the spec properly including the fine granularity of Chapter 12, some don't and since the TCK for CDI 1.0 is does not test much in this area it allows both groups to pass. That was fixed in subsequent TCK releases.
> 
> 
> On 05/04/2015 11:52 PM, Emily Jiang wrote:
>> ah. ok. For cdi 1.0, if all the implementor checks all jars having beans.xml and then merge the classes to the module bean archive, this will be fine. I think a spec issue will be raised to update section 5.
>> 
>> On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg at yahoo.de> wrote:
>> The CDI-1.0 TCK initially did not check anything in that regard. A test got added in a _very_ late version. This was in fact released AFTER CDI-1.1 was published if I remember correctly. So this version is not even part of the EE6 TCK?
>> 
>> LieGrue,
>> strub
>> 
>> > Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting at redhat.com>:
>> >
>> > Yes, chapter 5 is a bit confusing when it comes to composite Java EE modules. Comments inline:
>> >
>> > On 05/03/2015 12:20 AM, Emily Jiang wrote:
>> >> 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.
>> > The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented. Therefore, implementing bean archive as defined in Chapter 12 is the right approach for a Weld integrator.
>> >>
>> >> 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 at googlemail.com>
>> >> Date: Sat, May 2, 2015 at 10:21 PM
>> >> Subject: Re: [cdi-dev] bean archives
>> >> To: Mark Struberg <struberg at 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 at 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 at 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 at 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 at apache.org
>> >>> _______________________________________________
>> >>> cdi-dev mailing list
>> >>> cdi-dev at 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 at 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 at apache.org
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks
>> >> Emily
>> >> =================
>> >> Emily Jiang
>> >> ejiang at apache.org
>> >>
>> >>
>> >> _______________________________________________
>> >> cdi-dev mailing list
>> >>
>> >> cdi-dev at 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 at 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 at apache.org
> 
> 
> 
> 
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org



From issues at jboss.org  Tue May  5 07:16:45 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 5 May 2015 07:16:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow
 the inferring rules from the JavaBean spec
In-Reply-To: <JIRA.12570710.1430824574000@Atlassian.JIRA>
References: <JIRA.12570710.1430824574000@Atlassian.JIRA>
	<JIRA.12570710.1430824574912@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570710.1430824574000.10085.1430824605495@Atlassian.JIRA>

Martin Kouba created CDI-525:
--------------------------------

             Summary: Default names should maybe follow the inferring rules from the JavaBean spec
                 Key: CDI-525
                 URL: https://issues.jboss.org/browse/CDI-525
             Project: CDI Specification Issues
          Issue Type: Clarification
    Affects Versions: 1.2.Final
            Reporter: Martin Kouba


*3.1.5. Default bean name for a managed bean*:
{quote}
The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case.
{quote}

As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*:
{quote}
However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.
{quote}

I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}.

Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May  5 07:30:46 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 5 May 2015 07:30:46 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow
 the inferring rules from the JavaBean spec
In-Reply-To: <JIRA.12570710.1430824574000@Atlassian.JIRA>
References: <JIRA.12570710.1430824574000@Atlassian.JIRA>
	<JIRA.12570710.1430824574000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570710.1430824574000.10138.1430825446399@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065411#comment-13065411 ] 

Martin Kouba commented on CDI-525:
----------------------------------

It seems that OWB follows the current spec wording - see also [WebBeansUtil.getManagedBeanDefaultName()|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openwebbeans/openwebbeans-impl/1.2.7/org/apache/webbeans/util/WebBeansUtil.java#WebBeansUtil.getManagedBeanDefaultName%28java.lang.String%29]. Given that the change would be backwards incompatible and not all implementations behave in the same way I'm not so sure it's a good idea anymore.

> Default names should maybe follow the inferring rules from the JavaBean spec
> ----------------------------------------------------------------------------
>
>                 Key: CDI-525
>                 URL: https://issues.jboss.org/browse/CDI-525
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>
> *3.1.5. Default bean name for a managed bean*:
> {quote}
> The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case.
> {quote}
> As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*:
> {quote}
> However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.
> {quote}
> I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}.
> Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From jharting at redhat.com  Tue May  5 07:39:30 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 05 May 2015 13:39:30 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <BB0DD0C4-0FBD-4434-BA45-C2EFEB18BDF5@yahoo.de>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>	<55471AB8.5020900@redhat.com>	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>	<55484FD3.6000100@redhat.com>	<CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>
	<BB0DD0C4-0FBD-4434-BA45-C2EFEB18BDF5@yahoo.de>
Message-ID: <5548ABF2.3030107@redhat.com>

On 05/05/2015 11:38 AM, Mark Struberg wrote:
> Or section 12.
>
> Both ways are perfectly backward incompatible. If you drop BDA in section 5 then you break EE modularity and compatibility to EE6 servers (incuding RI). If you drop BDA in section 12 then you break scanning.
They are not incompatible. The only problem with Chapter 5 is that the 
way it is written gives some room for a wrong interpretation that is 
seemingly inconsistent with Chapter 12. The only open issue here 
therefore is how to rephrase the chapter to make it easier to read 
correctly the first time.
>
> We really need to handle this carefully.
>
> Imo we should finally accept that there are 2 different ?BDA? use cases and they both need a different Term. What about using the term BDA for section 12 and only for scanning.
There is a behavior defined in the spec, implemented in the EE7 RI (and 
all other compliant implementations) and tested in the TCK. We are not 
going to redefine the behavior. What we should do is to update the spec 
wording to be more easily understood.
>   And the term ?EE module? for section 5 (visibility) + interceptors, alternatives and decorators. That is basically how the EE6 RI behaved and what is the best for users.
Wrong. The EE6 RI implements bean archive isolation correctly (I just 
checked).
>   It also allows for_much_  better performance! And also please acknowledge the Alternatives-per-JAR is a major PITA in_real_  projects.


From rmannibucau at gmail.com  Tue May  5 07:56:44 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Tue, 5 May 2015 13:56:44 +0200
Subject: [cdi-dev] bean archives
In-Reply-To: <5548ABF2.3030107@redhat.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
	<55484FD3.6000100@redhat.com>
	<CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>
	<BB0DD0C4-0FBD-4434-BA45-C2EFEB18BDF5@yahoo.de>
	<5548ABF2.3030107@redhat.com>
Message-ID: <CACLE=7MhMbpdF0+nbj7vxy5u+6W3D0DD1uuRgRTdpFR3kKTWuw@mail.gmail.com>

2015-05-05 13:39 GMT+02:00 Jozef Hartinger <jharting at redhat.com>:

> On 05/05/2015 11:38 AM, Mark Struberg wrote:
> > Or section 12.
> >
> > Both ways are perfectly backward incompatible. If you drop BDA in
> section 5 then you break EE modularity and compatibility to EE6 servers
> (incuding RI). If you drop BDA in section 12 then you break scanning.
> They are not incompatible. The only problem with Chapter 5 is that the
> way it is written gives some room for a wrong interpretation that is
> seemingly inconsistent with Chapter 12. The only open issue here
> therefore is how to rephrase the chapter to make it easier to read
> correctly the first time.
> >
> > We really need to handle this carefully.
> >
> > Imo we should finally accept that there are 2 different ?BDA? use cases
> and they both need a different Term. What about using the term BDA for
> section 12 and only for scanning.
> There is a behavior defined in the spec, implemented in the EE7 RI (and
> all other compliant implementations) and tested in the TCK. We are not
> going to redefine the behavior. What we should do is to update the spec
> wording to be more easily understood.
> >   And the term ?EE module? for section 5 (visibility) + interceptors,
> alternatives and decorators. That is basically how the EE6 RI behaved and
> what is the best for users.
> Wrong. The EE6 RI implements bean archive isolation correctly (I just
> checked).
>

Didn't check glassfish but most of EE 6 servers didn't respect it cause it
was just impossible to write an application using a CDI library with such a
rule. I think it should be taken into account anyway because it is an
important feedback to the spec.


> >   It also allows for_much_  better performance! And also please
> acknowledge the Alternatives-per-JAR is a major PITA in_real_  projects.
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d19272f4/attachment.html 

From john.d.ament at gmail.com  Tue May  5 10:58:58 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Tue, 05 May 2015 14:58:58 +0000
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
In-Reply-To: <BB5C00CC-06B0-49C4-B96C-D2DB86D6138D@sabot-durand.net>
References: <7B63F35D-F5A5-4EED-9DF6-DA1499748B13@sabot-durand.net>
	<845586883.1067552.1430749991999.JavaMail.yahoo@mail.yahoo.com>
	<CAOqetn-x7=t46ioxZTGST=3yH_81NKe8H826LOrjctMxX=mFgg@mail.gmail.com>
	<BB5C00CC-06B0-49C4-B96C-D2DB86D6138D@sabot-durand.net>
Message-ID: <CAOqetn-zCCcS5HCrZQeQmLx9_N6MjXvFF7qRH3CF9v7jeNS7kg@mail.gmail.com>

Unfortunately, I'm not going to be able to make today's meeting after all.

Is it possible to schedule for a different day of the week?  I know we
moved from Wednesdays to Tuesdays for the Brno folks, but Tuesdays are
generally hard for me.  I don't recall a discussion thread on the change.

John

On Tue, May 5, 2015 at 1:57 AM Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> I?ve just resen an invite to the list.
>
>
> Le 5 mai 2015 ? 01:58, John D. Ament <john.d.ament at gmail.com> a ?crit :
>
> It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.
>
> On Mon, May 4, 2015 at 10:33 AM Michael Remijan <mjremijan at yahoo.com>
> wrote:
>
>> What are the details of the meeting?  I'd like to attend if possible.
>>
>>
>>
>>   On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <
>> antoine at sabot-durand.net> wrote:
>>
>>
>> Hi all,
>>
>> For this week meeting, I?d like to have a focus on SE boot and John PR :
>> https://github.com/cdi-spec/cdi/pull/243
>>
>> Take a moment to read his proposal and  make your comment if you have
>> some.
>>
>> If we have time left we?ll go back on Event ordering and Mark P. PR :
>> https://github.com/cdi-spec/cdi/pull/242
>>
>> Regards,
>>
>> Antoine
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d93abccb/attachment-0001.html 

From werner.keil at gmail.com  Tue May  5 12:07:02 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Tue, 5 May 2015 18:07:02 +0200
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
Message-ID: <CAAGawe3nEkarLNPEVFXcLiPpFQ1nOPK2jCaB5zO99EP=K=nd7g@mail.gmail.com>

Similar here.

Almost every Tue I join the Portlet 3 call (till around 5:30 CET) and as
mentioned unlike free or local German conf calls, IRC is blocked by the
firewall. Wed would be more flexible, e.g. being able to dial in from
hotel, but not today if I had other calls before that.

Werner

On Tue, May 5, 2015 at 4:59 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at 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:
>
>    1. Re: bean archives (Mark Struberg)
>    2. [JBoss JIRA] (CDI-525) Default names should maybe follow the
>       inferring rules from the JavaBean spec (Martin Kouba (JIRA))
>    3. [JBoss JIRA] (CDI-525) Default names should maybe follow the
>       inferring rules from the JavaBean spec (Martin Kouba (JIRA))
>    4. Re: bean archives (Jozef Hartinger)
>    5. Re: bean archives (Romain Manni-Bucau)
>    6. Re: Tomorrow's meeting focused on SE boot (John D. Ament)
>
>
> ----------------------------------------------------------------------
>
>
> Message: 6
> Date: Tue, 05 May 2015 14:58:58 +0000
> From: "John D. Ament" <john.d.ament at gmail.com>
> Subject: Re: [cdi-dev] Tomorrow's meeting focused on SE boot
> To: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <
> CAOqetn-zCCcS5HCrZQeQmLx9_N6MjXvFF7qRH3CF9v7jeNS7kg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Unfortunately, I'm not going to be able to make today's meeting after all.
>
> Is it possible to schedule for a different day of the week?  I know we
> moved from Wednesdays to Tuesdays for the Brno folks, but Tuesdays are
> generally hard for me.  I don't recall a discussion thread on the change.
>
> John
>
> On Tue, May 5, 2015 at 1:57 AM Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
> > I?ve just resen an invite to the list.
> >
> >
> > Le 5 mai 2015 ? 01:58, John D. Ament <john.d.ament at gmail.com> a ?crit :
> >
> > It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.
> >
> > On Mon, May 4, 2015 at 10:33 AM Michael Remijan <mjremijan at yahoo.com>
> > wrote:
> >
> >> What are the details of the meeting?  I'd like to attend if possible.
> >>
> >>
> >>
> >>   On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <
> >> antoine at sabot-durand.net> wrote:
> >>
> >>
> >> Hi all,
> >>
> >> For this week meeting, I?d like to have a focus on SE boot and John PR :
> >> https://github.com/cdi-spec/cdi/pull/243
> >>
> >> Take a moment to read his proposal and  make your comment if you have
> >> some.
> >>
> >> If we have time left we?ll go back on Event ordering and Mark P. PR :
> >> https://github.com/cdi-spec/cdi/pull/242
> >>
> >> Regards,
> >>
> >> Antoine
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at 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 at 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.
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d93abccb/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 54, Issue 10
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/9a9e6fdf/attachment.html 

From ggastald at redhat.com  Tue May  5 12:08:23 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Tue, 05 May 2015 13:08:23 -0300
Subject: [cdi-dev] Tomorrow's meeting focused on SE boot
In-Reply-To: <CAAGawe3nEkarLNPEVFXcLiPpFQ1nOPK2jCaB5zO99EP=K=nd7g@mail.gmail.com>
References: <CAAGawe3nEkarLNPEVFXcLiPpFQ1nOPK2jCaB5zO99EP=K=nd7g@mail.gmail.com>
Message-ID: <5548EAF7.5030407@redhat.com>

Wednesday would work for me too, same time.

On 05/05/2015 01:07 PM, Werner Keil wrote:
> Similar here.
>
> Almost every Tue I join the Portlet 3 call (till around 5:30 CET) and 
> as mentioned unlike free or local German conf calls, IRC is blocked by 
> the firewall. Wed would be more flexible, e.g. being able to dial in 
> from hotel, but not today if I had other calls before that.
>
> Werner
>
> On Tue, May 5, 2015 at 4:59 PM, <cdi-dev-request at lists.jboss.org 
> <mailto:cdi-dev-request at lists.jboss.org>> wrote:
>
>     Send cdi-dev mailing list submissions to
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org
>     <mailto:cdi-dev-request at lists.jboss.org>
>
>     You can reach the person managing the list at
>     cdi-dev-owner at lists.jboss.org <mailto:cdi-dev-owner at 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:
>
>        1. Re: bean archives (Mark Struberg)
>        2. [JBoss JIRA] (CDI-525) Default names should maybe follow the
>           inferring rules from the JavaBean spec (Martin Kouba (JIRA))
>        3. [JBoss JIRA] (CDI-525) Default names should maybe follow the
>           inferring rules from the JavaBean spec (Martin Kouba (JIRA))
>        4. Re: bean archives (Jozef Hartinger)
>        5. Re: bean archives (Romain Manni-Bucau)
>        6. Re: Tomorrow's meeting focused on SE boot (John D. Ament)
>
>
>     ----------------------------------------------------------------------
>
>
>     Message: 6
>     Date: Tue, 05 May 2015 14:58:58 +0000
>     From: "John D. Ament" <john.d.ament at gmail.com
>     <mailto:john.d.ament at gmail.com>>
>     Subject: Re: [cdi-dev] Tomorrow's meeting focused on SE boot
>     To: Antoine Sabot-Durand <antoine at sabot-durand.net
>     <mailto:antoine at sabot-durand.net>>
>     Cc: cdi-dev <cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
>     Message-ID:
>            
>     <CAOqetn-zCCcS5HCrZQeQmLx9_N6MjXvFF7qRH3CF9v7jeNS7kg at mail.gmail.com <mailto:CAOqetn-zCCcS5HCrZQeQmLx9_N6MjXvFF7qRH3CF9v7jeNS7kg at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>
>     Unfortunately, I'm not going to be able to make today's meeting
>     after all.
>
>     Is it possible to schedule for a different day of the week?  I know we
>     moved from Wednesdays to Tuesdays for the Brno folks, but Tuesdays are
>     generally hard for me.  I don't recall a discussion thread on the
>     change.
>
>     John
>
>     On Tue, May 5, 2015 at 1:57 AM Antoine Sabot-Durand <
>     antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>
>     > I?ve just resen an invite to the list.
>     >
>     >
>     > Le 5 mai 2015 ? 01:58, John D. Ament <john.d.ament at gmail.com
>     <mailto:john.d.ament at gmail.com>> a ?crit :
>     >
>     > It's on IRC, #cdi-dev on freenode, noon eastern time/5 pm GMT.
>     >
>     > On Mon, May 4, 2015 at 10:33 AM Michael Remijan
>     <mjremijan at yahoo.com <mailto:mjremijan at yahoo.com>>
>     > wrote:
>     >
>     >> What are the details of the meeting?  I'd like to attend if
>     possible.
>     >>
>     >>
>     >>
>     >>   On Monday, May 4, 2015 8:43 AM, Antoine Sabot-Durand <
>     >> antoine at sabot-durand.net <mailto:antoine at sabot-durand.net>> wrote:
>     >>
>     >>
>     >> Hi all,
>     >>
>     >> For this week meeting, I?d like to have a focus on SE boot and
>     John PR :
>     >> https://github.com/cdi-spec/cdi/pull/243
>     >>
>     >> Take a moment to read his proposal and  make your comment if
>     you have
>     >> some.
>     >>
>     >> If we have time left we?ll go back on Event ordering and Mark
>     P. PR :
>     >> https://github.com/cdi-spec/cdi/pull/242
>     >>
>     >> Regards,
>     >>
>     >> Antoine
>     >>
>     >> _______________________________________________
>     >> cdi-dev mailing list
>     >> cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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.
>     >
>     >
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/d93abccb/attachment.html
>
>     ------------------------------
>
>     _______________________________________________
>     cdi-dev mailing list
>     cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 54, Issue 10
>     ***************************************
>
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150505/df642915/attachment-0001.html 

From emijiang6 at googlemail.com  Wed May  6 17:27:02 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Wed, 6 May 2015 22:27:02 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe
 follow the inferring rules from the JavaBean spec
In-Reply-To: <JIRA.12570710.1430824574000.10138.1430825446399@Atlassian.JIRA>
References: <JIRA.12570710.1430824574000@jira02.app.mwc.hst.phx2.redhat.com>
	<JIRA.12570710.1430824574000@Atlassian.JIRA>
	<JIRA.12570710.1430824574000.10138.1430825446399@Atlassian.JIRA>
Message-ID: <CAECq3A8LeMfTrV3TRvJj8sgQ_nOJ3bE3MmHXz_em2X2f1HggGA@mail.gmail.com>

Agreed! I think Weld should be changed to comply with what CDI Spec says.

On Tue, May 5, 2015 at 12:30 PM, Martin Kouba (JIRA) <issues at jboss.org>
wrote:

>
>     [
> https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065411#comment-13065411
> ]
>
> Martin Kouba commented on CDI-525:
> ----------------------------------
>
> It seems that OWB follows the current spec wording - see also
> [WebBeansUtil.getManagedBeanDefaultName()|
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openwebbeans/openwebbeans-impl/1.2.7/org/apache/webbeans/util/WebBeansUtil.java#WebBeansUtil.getManagedBeanDefaultName%28java.lang.String%29].
> Given that the change would be backwards incompatible and not all
> implementations behave in the same way I'm not so sure it's a good idea
> anymore.
>
> > Default names should maybe follow the inferring rules from the JavaBean
> spec
> >
> ----------------------------------------------------------------------------
> >
> >                 Key: CDI-525
> >                 URL: https://issues.jboss.org/browse/CDI-525
> >             Project: CDI Specification Issues
> >          Issue Type: Clarification
> >    Affects Versions: 1.2.Final
> >            Reporter: Martin Kouba
> >
> > *3.1.5. Default bean name for a managed bean*:
> > {quote}
> > The default name for a managed bean is the unqualified class name of the
> bean class, after converting the first character to lower case.
> > {quote}
> > As a result, the default name for a bean class {{URLMatcher}} should be
> {{uRLMatcher}}. On the other hand the JavaBean spec is using different
> rules when inferring property names, *8.8 Capitalization of inferred names*:
> > {quote}
> > However to support the occasional use of all upper-case names, we check
> if the first two characters of the name are both upper case and if so leave
> it alone.
> > {quote}
> > I.e. the property name for getter {{getURLMatcher()}} woud be
> {{URLMatcher}}.
> > Note that there is no TCK test for this and so implementations may
> differ (issue is already filed: CDITCK-473). Weld is using
> {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean
> spec even now. I'm not sure about OpenWebBeans.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150506/674a73bf/attachment.html 

From issues at jboss.org  Wed May  6 17:27:45 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Wed, 6 May 2015 17:27:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-525) Default names should maybe follow
 the inferring rules from the JavaBean spec
In-Reply-To: <JIRA.12570710.1430824574000@Atlassian.JIRA>
References: <JIRA.12570710.1430824574000@Atlassian.JIRA>
	<JIRA.12570710.1430824574000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570710.1430824574000.14785.1430947665600@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emily Jiang updated CDI-525:
----------------------------

Agreed! I think Weld should be changed to comply with what CDI Spec says.

On Tue, May 5, 2015 at 12:30 PM, Martin Kouba (JIRA) <issues at jboss.org>




-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org


> Default names should maybe follow the inferring rules from the JavaBean spec
> ----------------------------------------------------------------------------
>
>                 Key: CDI-525
>                 URL: https://issues.jboss.org/browse/CDI-525
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>    Affects Versions: 1.2.Final
>            Reporter: Martin Kouba
>
> *3.1.5. Default bean name for a managed bean*:
> {quote}
> The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case.
> {quote}
> As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*:
> {quote}
> However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.
> {quote}
> I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}.
> Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From ant.elder at gmail.com  Fri May  8 05:37:11 2015
From: ant.elder at gmail.com (ant elder)
Date: Fri, 8 May 2015 10:37:11 +0100
Subject: [cdi-dev] Injecting classes with final package private methods
Message-ID: <CAJO+Ubt2PMFq_RdaTCeqqAMdnk=GTzu0R-17g0yKJtS+DhOVmA@mail.gmail.com>

Hi CDI spec people,

I've an application that uses CDI which breaks when moving from Java 1.6 to
Java 1.7. The problem is that the application injects a
java.util.Hashtable, and in Java 1.7 a new method, initHashSeedAsNeeded,
was added to Hashtable and its a final method, so now the inject fails with:

javax.enterprise.inject.UnproxyableResolutionException: WebBeans with api
type with normal scope must be proxiable to inject. java.util.Hashtable has
final method final boolean java.util.Hashtable.initHashSeedAsNeeded(int)
CDI doesn't allow that.

Why i'm asking about this here is because initHashSeedAsNeeded has default
(package private) visibility, so i wondered if there was any chance that
the change in CDI-159 could be interpreted as also allowing injecting
classes with final package private visibility methods into classes in a
different package?

   ...ant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150508/643ba17b/attachment.html 

From issues at jboss.org  Sat May  9 09:04:45 2015
From: issues at jboss.org (Mark Paluch (JIRA))
Date: Sat, 9 May 2015 09:04:45 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-521) Create a Prioritized Interface for
 SPI element that have a priority
In-Reply-To: <JIRA.12570182.1430299501000@Atlassian.JIRA>
References: <JIRA.12570182.1430299501000@Atlassian.JIRA>
	<JIRA.12570182.1430299501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570182.1430299501000.19424.1431176685725@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066669#comment-13066669 ] 

Mark Paluch commented on CDI-521:
---------------------------------

Submitted code proposal together with PR https://github.com/cdi-spec/cdi/pull/242

> Create a Prioritized Interface for SPI element that have a priority 
> --------------------------------------------------------------------
>
>                 Key: CDI-521
>                 URL: https://issues.jboss.org/browse/CDI-521
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0 (discussion)
>
>
> With the addition of ordering in Observer (CDI-4), we have a collection of element in SPI that could benefit having a {{getPriority()}} method:
> * {{ObserverMethod}}
> * {{Bean}} to be able to read alternative priority and give priority for {{Decorator}} and {{Interceptor}}
> Any other place?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Mon May 11 06:42:20 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 11 May 2015 06:42:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters
In-Reply-To: <JIRA.12571259.1431340923000@Atlassian.JIRA>
References: <JIRA.12571259.1431340923000@Atlassian.JIRA>
	<JIRA.12571259.1431340923432@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571259.1431340923000.1013.1431340940040@Atlassian.JIRA>

Jozef Hartinger created CDI-526:
-----------------------------------

             Summary: 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)

From issues at jboss.org  Mon May 11 06:49:20 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Mon, 11 May 2015 06:49:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters
In-Reply-To: <JIRA.12571259.1431340923000@Atlassian.JIRA>
References: <JIRA.12571259.1431340923000@Atlassian.JIRA>
	<JIRA.12571259.1431340923000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571259.1431340923000.1044.1431341360083@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066821#comment-13066821 ] 

Romain Manni-Bucau commented on CDI-526:
----------------------------------------

+1, would be far easier than excluding all the container and breaking the app each time you add a not CDi friendly dependency.

> 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)

From emijiang6 at googlemail.com  Mon May 11 08:43:01 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Mon, 11 May 2015 13:43:01 +0100
Subject: [cdi-dev] bean archives
In-Reply-To: <CACLE=7MhMbpdF0+nbj7vxy5u+6W3D0DD1uuRgRTdpFR3kKTWuw@mail.gmail.com>
References: <A1ADACC9-F25B-4584-84AD-DE0665DF0B3B@sabot-durand.net>
	<1509721659.189390.1430578024398.JavaMail.yahoo@mail.yahoo.com>
	<CAECq3A9Z6eHONHMscDEmR6R5vTD0aogv3YFy-uQktmtXH0SAhg@mail.gmail.com>
	<CAECq3A-n7df56cFySX1miHiK8=Z5sB=sCDqi0REHdJvyG-0nZA@mail.gmail.com>
	<55471AB8.5020900@redhat.com>
	<B8E66451-7D6A-48AE-8C70-47071C0C03D3@yahoo.de>
	<CAECq3A-ZFehat8NHUp-9TZUtBKT4zd1pj4yfscx+uTYGsX5Gvg@mail.gmail.com>
	<55484FD3.6000100@redhat.com>
	<CAECq3A_0hForWTarbPAwktyMEn=WKA1R3Ft7cemLt3peykkJFQ@mail.gmail.com>
	<BB0DD0C4-0FBD-4434-BA45-C2EFEB18BDF5@yahoo.de>
	<5548ABF2.3030107@redhat.com>
	<CACLE=7MhMbpdF0+nbj7vxy5u+6W3D0DD1uuRgRTdpFR3kKTWuw@mail.gmail.com>
Message-ID: <CAECq3A_dX93PHDS9LSKgqBiPAjLbHPtBAw916i0LtO3g2VY2XQ@mail.gmail.com>

Has anyone created a cdi spec jira for this or I should create one?

On Tue, May 5, 2015 at 12:56 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> 2015-05-05 13:39 GMT+02:00 Jozef Hartinger <jharting at redhat.com>:
>
>> On 05/05/2015 11:38 AM, Mark Struberg wrote:
>> > Or section 12.
>> >
>> > Both ways are perfectly backward incompatible. If you drop BDA in
>> section 5 then you break EE modularity and compatibility to EE6 servers
>> (incuding RI). If you drop BDA in section 12 then you break scanning.
>> They are not incompatible. The only problem with Chapter 5 is that the
>> way it is written gives some room for a wrong interpretation that is
>> seemingly inconsistent with Chapter 12. The only open issue here
>> therefore is how to rephrase the chapter to make it easier to read
>> correctly the first time.
>> >
>> > We really need to handle this carefully.
>> >
>> > Imo we should finally accept that there are 2 different ?BDA? use cases
>> and they both need a different Term. What about using the term BDA for
>> section 12 and only for scanning.
>> There is a behavior defined in the spec, implemented in the EE7 RI (and
>> all other compliant implementations) and tested in the TCK. We are not
>> going to redefine the behavior. What we should do is to update the spec
>> wording to be more easily understood.
>> >   And the term ?EE module? for section 5 (visibility) + interceptors,
>> alternatives and decorators. That is basically how the EE6 RI behaved and
>> what is the best for users.
>> Wrong. The EE6 RI implements bean archive isolation correctly (I just
>> checked).
>>
>
> Didn't check glassfish but most of EE 6 servers didn't respect it cause it
> was just impossible to write an application using a CDI library with such a
> rule. I think it should be taken into account anyway because it is an
> important feedback to the spec.
>
>
>> >   It also allows for_much_  better performance! And also please
>> acknowledge the Alternatives-per-JAR is a major PITA in_real_  projects.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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 at 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 at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150511/bd249692/attachment-0001.html 

From emijiang6 at googlemail.com  Mon May 11 09:51:35 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Mon, 11 May 2015 14:51:35 +0100
Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters
In-Reply-To: <JIRA.12571259.1431340923000.1044.1431341360083@Atlassian.JIRA>
References: <JIRA.12571259.1431340923000@jira02.app.mwc.hst.phx2.redhat.com>
	<JIRA.12571259.1431340923000@Atlassian.JIRA>
	<JIRA.12571259.1431340923000.1044.1431341360083@Atlassian.JIRA>
Message-ID: <CAECq3A9Pi1a0G4B0-MZmetcpOn_84rag0tyRDeDU6d5_Ps+hpA@mail.gmail.com>

+1. I was going to raise a jira myself for this.

On Mon, May 11, 2015 at 11:49 AM, Romain Manni-Bucau (JIRA) <
issues at jboss.org> wrote:

>
>     [
> https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066821#comment-13066821
> ]
>
> Romain Manni-Bucau commented on CDI-526:
> ----------------------------------------
>
> +1, would be far easier than excluding all the container and breaking the
> app each time you add a not CDi friendly dependency.
>
> > 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)
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150511/d3b89860/attachment.html 

From issues at jboss.org  Mon May 11 09:52:20 2015
From: issues at jboss.org (Emily Jiang (JIRA))
Date: Mon, 11 May 2015 09:52:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters
In-Reply-To: <JIRA.12571259.1431340923000@Atlassian.JIRA>
References: <JIRA.12571259.1431340923000@Atlassian.JIRA>
	<JIRA.12571259.1431340923000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571259.1431340923000.1609.1431352340064@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emily Jiang updated CDI-526:
----------------------------

+1. I was going to raise a jira myself for this.

On Mon, May 11, 2015 at 11:49 AM, Romain Manni-Bucau (JIRA) <




-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org


> 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)

From issues at jboss.org  Wed May 13 08:09:20 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 13 May 2015 08:09:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-526) Include filters
In-Reply-To: <JIRA.12571259.1431340923000@Atlassian.JIRA>
References: <JIRA.12571259.1431340923000@Atlassian.JIRA>
	<JIRA.12571259.1431340923000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571259.1431340923000.6888.1431518960212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067640#comment-13067640 ] 

Martin Kouba commented on CDI-526:
----------------------------------

Maybe we should be more explicit that exclude filters (and possibly include filters) are *only applied to the types found in a specific bean archive*. E.g. users might be tempted to use include filters to "add" types from the classpath.

> 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)

From mjremijan at yahoo.com  Wed May 13 08:18:18 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Wed, 13 May 2015 12:18:18 +0000 (UTC)
Subject: [cdi-dev] Successfully using @Priority
Message-ID: <666378591.1189009.1431519498646.JavaMail.yahoo@mail.yahoo.com>

I wanted to let te team know that I've successfully incorporated the new @Priority annotation into my application and it seems to be working great. My application needs to startup in a particular order and prior to the @Priority annotation I had to create a class whose only job was this prioritization. ?I never liked this solution. ?The @Priority annotation is a lot nicer. ?
Something I'd like to see in the documentation. The event the application is observing is my StartupConfigurationEvent class. ?Along side this class I created a StartupConfigurationPriorty class with a public static final int values in it which define the priority of the event processing. ?It's then very easy to find not only the classes observing that event but it also self documents the priorty without having to dig into each class.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150513/392f9529/attachment.html 

From issues at jboss.org  Wed May 13 11:50:19 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 11:50:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in
	API JAR
In-Reply-To: <JIRA.12564530.1425217548000@Atlassian.JIRA>
References: <JIRA.12564530.1425217548000@Atlassian.JIRA>
	<JIRA.12564530.1425217548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564530.1425217548000.7789.1431532219942@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-509:
-------------------------------------
    Affects Version/s: 1.2.Final


> Upgrade to latest felix plugin in API JAR
> -----------------------------------------
>
>                 Key: CDI-509
>                 URL: https://issues.jboss.org/browse/CDI-509
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>    Affects Versions: 1.2.Final
>            Reporter: John Ament
>            Assignee: John Ament
>
> Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 13 11:50:20 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 11:50:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in
	API JAR
In-Reply-To: <JIRA.12564530.1425217548000@Atlassian.JIRA>
References: <JIRA.12564530.1425217548000@Atlassian.JIRA>
	<JIRA.12564530.1425217548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564530.1425217548000.7793.1431532220315@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-509:
-------------------------------------
    Component/s: Javadoc and API


> Upgrade to latest felix plugin in API JAR
> -----------------------------------------
>
>                 Key: CDI-509
>                 URL: https://issues.jboss.org/browse/CDI-509
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: John Ament
>            Assignee: John Ament
>
> Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 13 11:54:19 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 11:54:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in
	API JAR
In-Reply-To: <JIRA.12564530.1425217548000@Atlassian.JIRA>
References: <JIRA.12564530.1425217548000@Atlassian.JIRA>
	<JIRA.12564530.1425217548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564530.1425217548000.7812.1431532459449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-509:
-------------------------------------
    Fix Version/s: 2.0-EDR1


> Upgrade to latest felix plugin in API JAR
> -----------------------------------------
>
>                 Key: CDI-509
>                 URL: https://issues.jboss.org/browse/CDI-509
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: John Ament
>            Assignee: John Ament
>             Fix For: 2.0-EDR1
>
>
> Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 13 12:47:20 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 12:47:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.7919.1431535640431@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-26:
------------------------------------
    Fix Version/s: 2.0-EDR1


> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0, 1.1.PFD, 1.2.Final
>            Reporter: Pete Muir
>             Fix For: 2.0 (discussion), 2.0-EDR1
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 13 12:48:20 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 12:48:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.7933.1431535700938@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand resolved CDI-26.
-------------------------------------
         Assignee: John Ament
    Fix Version/s:     (was: 2.0 (discussion))
       Resolution: Done


Class scanning and context control will be addressed in other tickets

> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0, 1.1.PFD, 1.2.Final
>            Reporter: Pete Muir
>            Assignee: John Ament
>             Fix For: 2.0-EDR1
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 13 12:51:19 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 13 May 2015 12:51:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in
	API JAR
In-Reply-To: <JIRA.12564530.1425217548000@Atlassian.JIRA>
References: <JIRA.12564530.1425217548000@Atlassian.JIRA>
	<JIRA.12564530.1425217548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564530.1425217548000.7948.1431535879400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand closed CDI-509.
------------------------------------
    Resolution: Done


Merged in EDR1 branch

> Upgrade to latest felix plugin in API JAR
> -----------------------------------------
>
>                 Key: CDI-509
>                 URL: https://issues.jboss.org/browse/CDI-509
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: John Ament
>            Assignee: John Ament
>             Fix For: 2.0-EDR1
>
>
> Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Wed May 13 13:02:12 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 13 May 2015 19:02:12 +0200
Subject: [cdi-dev] Java SE bootstrap added to CDI-EDR1 branch.
Message-ID: <515C4FBE-3D4E-4BAD-8E73-6B20CF570DCF@sabot-durand.net>

Hi all,

After a bit of cleaning, I merged John PR in the new 2.0-EDR1 branch.

This PR close CDI-509 (related to felix bundle plugin version) and CDI-26.

Thanks Again John for this nice (and first) contribution to CDI 2.0-EDR1

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/20150513/61530399/attachment.bin 

From antoine at sabot-durand.net  Wed May 13 13:08:56 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 13 May 2015 19:08:56 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
Message-ID: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>

Hi all,

While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.

While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?

I thought of 2 simple solutions for EDR1:

1) make getCDI() return the last CDI object initialized by the CDIProvider
2) Forbid getCDI() in SE

Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?

Wdyt,

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/20150513/621392a8/attachment.bin 

From mkouba at redhat.com  Thu May 14 02:11:17 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 14 May 2015 08:11:17 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
Message-ID: <55543C85.3050006@redhat.com>

Hi Antoine,

Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent 
Weld instances) has a special CDIProvider implementation [2]:

* if there's exactly one container running, return this container
* if there are multiple containers running, log an INFO message and 
attempt to identify the container by the calling class:
** if there is only one container aware of the class, return this container
** otherwise return the first container initialized

Martin

[1]
http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/

[2]
https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java


Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>
> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>
> I thought of 2 simple solutions for EDR1:
>
> 1) make getCDI() return the last CDI object initialized by the CDIProvider
> 2) Forbid getCDI() in SE
>
> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>
> Wdyt,
>
> Antoine
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Thu May 14 03:12:48 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 14 May 2015 09:12:48 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <55543C85.3050006@redhat.com>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
Message-ID: <86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>

I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
What?s the use case? 

LieGrue,
strub


> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Hi Antoine,
> 
> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent 
> Weld instances) has a special CDIProvider implementation [2]:
> 
> * if there's exactly one container running, return this container
> * if there are multiple containers running, log an INFO message and 
> attempt to identify the container by the calling class:
> ** if there is only one container aware of the class, return this container
> ** otherwise return the first container initialized
> 
> Martin
> 
> [1]
> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
> 
> [2]
> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
> 
> 
> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>> Hi all,
>> 
>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>> 
>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>> 
>> I thought of 2 simple solutions for EDR1:
>> 
>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>> 2) Forbid getCDI() in SE
>> 
>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>> 
>> Wdyt,
>> 
>> Antoine
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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.
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.



From mkouba at redhat.com  Thu May 14 03:23:56 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 14 May 2015 09:23:56 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
Message-ID: <55544D8C.1040306@redhat.com>

Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:

"One possible use-case this enables is for a library or framework (e.g. 
a testing framework) to use an embedded instance of Weld internally for 
its own needs (dependency injection, events, extensibility). This 
instance would not interfere with the Weld instance used by the 
application."

I think the fact that there's no specific use case doesn't mean we 
should forbid this.

Martin

Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
> What?s the use case?
>
> LieGrue,
> strub
>
>
>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
>>
>> Hi Antoine,
>>
>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
>> Weld instances) has a special CDIProvider implementation [2]:
>>
>> * if there's exactly one container running, return this container
>> * if there are multiple containers running, log an INFO message and
>> attempt to identify the container by the calling class:
>> ** if there is only one container aware of the class, return this container
>> ** otherwise return the first container initialized
>>
>> Martin
>>
>> [1]
>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>>
>> [2]
>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
>>
>>
>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>>> Hi all,
>>>
>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>>>
>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>>>
>>> I thought of 2 simple solutions for EDR1:
>>>
>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>>> 2) Forbid getCDI() in SE
>>>
>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>>>
>>> Wdyt,
>>>
>>> Antoine
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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.
>>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Thu May 14 04:36:24 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 14 May 2015 10:36:24 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <55544D8C.1040306@redhat.com>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
Message-ID: <3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>

That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice. 


>  think the fact that there?s no specific use case doesn?t mean we should forbid this.
If it requires the impls to do all kind of mad stuff then we at least should not require it. 



LieGrue,
strub


> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
> 
> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
> 
> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application."
> 
> I think the fact that there's no specific use case doesn't mean we should forbid this.
> 
> Martin
> 
> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
>> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
>> What?s the use case?
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
>>> 
>>> Hi Antoine,
>>> 
>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
>>> Weld instances) has a special CDIProvider implementation [2]:
>>> 
>>> * if there's exactly one container running, return this container
>>> * if there are multiple containers running, log an INFO message and
>>> attempt to identify the container by the calling class:
>>> ** if there is only one container aware of the class, return this container
>>> ** otherwise return the first container initialized
>>> 
>>> Martin
>>> 
>>> [1]
>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>>> 
>>> [2]
>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
>>> 
>>> 
>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>>>> Hi all,
>>>> 
>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>>>> 
>>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>>>> 
>>>> I thought of 2 simple solutions for EDR1:
>>>> 
>>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>>>> 2) Forbid getCDI() in SE
>>>> 
>>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>>>> 
>>>> Wdyt,
>>>> 
>>>> Antoine
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at 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.
>>>> 
>>> 
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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.
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic



From antoine at sabot-durand.net  Thu May 14 04:44:33 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 14 May 2015 10:44:33 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
	<3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
Message-ID: <BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>

Mark,

My question wasn?t about the feature which have been discussed for more than 2 months. This feature is now going to EDR1 since there wasn?t voice against it. And again EDR1 is not final spec. You?ll be able to discuss it with the community when it?ll be proposed.

Antoine



> Le 14 mai 2015 ? 10:36, Mark Struberg <struberg at yahoo.de> a ?crit :
> 
> That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice.
> 
> 
>> think the fact that there?s no specific use case doesn?t mean we should forbid this.
> If it requires the impls to do all kind of mad stuff then we at least should not require it.
> 
> 
> 
> LieGrue,
> strub
> 
> 
>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
>> 
>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
>> 
>> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application."
>> 
>> I think the fact that there's no specific use case doesn't mean we should forbid this.
>> 
>> Martin
>> 
>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
>>> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
>>> What?s the use case?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
>>>> 
>>>> Hi Antoine,
>>>> 
>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
>>>> Weld instances) has a special CDIProvider implementation [2]:
>>>> 
>>>> * if there's exactly one container running, return this container
>>>> * if there are multiple containers running, log an INFO message and
>>>> attempt to identify the container by the calling class:
>>>> ** if there is only one container aware of the class, return this container
>>>> ** otherwise return the first container initialized
>>>> 
>>>> Martin
>>>> 
>>>> [1]
>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>>>> 
>>>> [2]
>>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
>>>> 
>>>> 
>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>>>>> Hi all,
>>>>> 
>>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>>>>> 
>>>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>>>>> 
>>>>> I thought of 2 simple solutions for EDR1:
>>>>> 
>>>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>>>>> 2) Forbid getCDI() in SE
>>>>> 
>>>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>>>>> 
>>>>> Wdyt,
>>>>> 
>>>>> Antoine
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at 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.
>>>>> 
>>>> 
>>>> --
>>>> Martin Kouba
>>>> Software Engineer
>>>> Red Hat, Czech Republic
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev at 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.
>>> 
>> 
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
> 

-------------- 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/20150514/01a54a5b/attachment.bin 

From john.d.ament at gmail.com  Thu May 14 07:26:36 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Thu, 14 May 2015 07:26:36 -0400
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
Message-ID: <CAOqetn8R2C1eyfVWi6d_vwuNj9svTQmLrRGTL+ev2A9ZTb-iew@mail.gmail.com>

At some point, I had this issue noted somewhere.  I guess I never brought
it up on the ML.

The behavior of the RI makes no sense IMHO.  If someone else calls
initialize of the CDIProvider I'm working on, now my state is all messed
up.  Not good behavior.

Anyways, if we do #1 it's clear that this initialization doesn't belong in
CDIProvider.

If we do #2, it'll be bad experience for whoever's using the provider.

I'd prefer a third option.  Revert the change that allows you to call
initialize() multiple times, and instead add a CDIProviderFactory (or
equivalent) that creates new CDIProviders.  You may call initialize on
those instances to get new containers.  Oh then shutdown can go back on the
CDIProvider as well.

John

On Wed, May 13, 2015 at 1:08 PM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi all,
>
> While cleaning Javadoc in CDIProvider, I realized that getCDI() method
> description is not compatible with the multiple container initialization we
> allowed in the API.
>
> While running in Java EE getCDI() retuns the current container which is
> fine since there?s only one, but what do we expect from it when running in
> SE?
>
> I thought of 2 simple solutions for EDR1:
>
> 1) make getCDI() return the last CDI object initialized by the CDIProvider
> 2) Forbid getCDI() in SE
>
> Of course there?s always the solution of moving the code outside
> CDIProvider, but it?s less simple?
>
> Wdyt,
>
> Antoine
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150514/f0588272/attachment.html 

From struberg at yahoo.de  Thu May 14 09:22:27 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 14 May 2015 15:22:27 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
	<3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
	<BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>
Message-ID: <6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>

I DID voice against multiple CDI impls both on the mailing list and on EG meetings?

> Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
> 
> Mark,
> 
> My question wasn?t about the feature which have been discussed for more than 2 months. This feature is now going to EDR1 since there wasn?t voice against it. And again EDR1 is not final spec. You?ll be able to discuss it with the community when it?ll be proposed.
> 
> Antoine
> 
> 
> 
>> Le 14 mai 2015 ? 10:36, Mark Struberg <struberg at yahoo.de> a ?crit :
>> 
>> That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice.
>> 
>> 
>>> think the fact that there?s no specific use case doesn?t mean we should forbid this.
>> If it requires the impls to do all kind of mad stuff then we at least should not require it.
>> 
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
>>> 
>>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
>>> 
>>> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application."
>>> 
>>> I think the fact that there's no specific use case doesn't mean we should forbid this.
>>> 
>>> Martin
>>> 
>>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
>>>> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
>>>> What?s the use case?
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
>>>>> 
>>>>> Hi Antoine,
>>>>> 
>>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
>>>>> Weld instances) has a special CDIProvider implementation [2]:
>>>>> 
>>>>> * if there's exactly one container running, return this container
>>>>> * if there are multiple containers running, log an INFO message and
>>>>> attempt to identify the container by the calling class:
>>>>> ** if there is only one container aware of the class, return this container
>>>>> ** otherwise return the first container initialized
>>>>> 
>>>>> Martin
>>>>> 
>>>>> [1]
>>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>>>>> 
>>>>> [2]
>>>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
>>>>> 
>>>>> 
>>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>>>>>> Hi all,
>>>>>> 
>>>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>>>>>> 
>>>>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>>>>>> 
>>>>>> I thought of 2 simple solutions for EDR1:
>>>>>> 
>>>>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>>>>>> 2) Forbid getCDI() in SE
>>>>>> 
>>>>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>>>>>> 
>>>>>> Wdyt,
>>>>>> 
>>>>>> Antoine
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at 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.
>>>>>> 
>>>>> 
>>>>> --
>>>>> Martin Kouba
>>>>> Software Engineer
>>>>> Red Hat, Czech Republic
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at 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.
>>>> 
>>> 
>>> --
>>> Martin Kouba
>>> Software Engineer
>>> Red Hat, Czech Republic
>> 
> 



From rmannibucau at gmail.com  Thu May 14 09:45:56 2015
From: rmannibucau at gmail.com (Romain Manni-Bucau)
Date: Thu, 14 May 2015 15:45:56 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
	<3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
	<BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>
	<6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>
Message-ID: <CACLE=7Nr1LVCwU2c7ef+JxbTi2MM-m5kPU_x31YT=kct4XyRWQ@mail.gmail.com>

This is a good feature but not in lazy mode. It implies to forbid all
contextuality like serialization etc...

Agree weld impl will lead to more issues than solutions.
Le 14 mai 2015 15:22, "Mark Struberg" <struberg at yahoo.de> a ?crit :

> I DID voice against multiple CDI impls both on the mailing list and on EG
> meetings?
>
> > Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> >
> > Mark,
> >
> > My question wasn?t about the feature which have been discussed for more
> than 2 months. This feature is now going to EDR1 since there wasn?t voice
> against it. And again EDR1 is not final spec. You?ll be able to discuss it
> with the community when it?ll be proposed.
> >
> > Antoine
> >
> >
> >
> >> Le 14 mai 2015 ? 10:36, Mark Struberg <struberg at yahoo.de> a ?crit :
> >>
> >> That usecase is imo not really valid. Such a testing framework would
> need a ClassLoader isolation to work. Just create a child UrlClassLoader
> with your test project in and be done. Otherwise you would get into a total
> mess with static fields etc. It simply makes no sense in my opinion and
> propagates bad practice.
> >>
> >>
> >>> think the fact that there?s no specific use case doesn?t mean we
> should forbid this.
> >> If it requires the impls to do all kind of mad stuff then we at least
> should not require it.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>
> >>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
> >>>
> >>> "One possible use-case this enables is for a library or framework
> (e.g. a testing framework) to use an embedded instance of Weld internally
> for its own needs (dependency injection, events, extensibility). This
> instance would not interfere with the Weld instance used by the
> application."
> >>>
> >>> I think the fact that there's no specific use case doesn't mean we
> should forbid this.
> >>>
> >>> Martin
> >>>
> >>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
> >>>> I still don?t get it what running multiple CDI container on the SAME
> ClassLoader/Thread should be for?
> >>>> What?s the use case?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>>>
> >>>>> Hi Antoine,
> >>>>>
> >>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
> >>>>> Weld instances) has a special CDIProvider implementation [2]:
> >>>>>
> >>>>> * if there's exactly one container running, return this container
> >>>>> * if there are multiple containers running, log an INFO message and
> >>>>> attempt to identify the container by the calling class:
> >>>>> ** if there is only one container aware of the class, return this
> container
> >>>>> ** otherwise return the first container initialized
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> [1]
> >>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
> >>>>>
> >>>>> [2]
> >>>>>
> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
> >>>>>
> >>>>>
> >>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
> >>>>>> Hi all,
> >>>>>>
> >>>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI()
> method description is not compatible with the multiple container
> initialization we allowed in the API.
> >>>>>>
> >>>>>> While running in Java EE getCDI() retuns the current container
> which is fine since there?s only one, but what do we expect from it when
> running in SE?
> >>>>>>
> >>>>>> I thought of 2 simple solutions for EDR1:
> >>>>>>
> >>>>>> 1) make getCDI() return the last CDI object initialized by the
> CDIProvider
> >>>>>> 2) Forbid getCDI() in SE
> >>>>>>
> >>>>>> Of course there?s always the solution of moving the code outside
> CDIProvider, but it?s less simple?
> >>>>>>
> >>>>>> Wdyt,
> >>>>>>
> >>>>>> Antoine
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> cdi-dev mailing list
> >>>>>> cdi-dev at 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.
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Martin Kouba
> >>>>> Software Engineer
> >>>>> Red Hat, Czech Republic
> >>>>> _______________________________________________
> >>>>> cdi-dev mailing list
> >>>>> cdi-dev at 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.
> >>>>
> >>>
> >>> --
> >>> Martin Kouba
> >>> Software Engineer
> >>> Red Hat, Czech Republic
> >>
> >
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150514/1f84e6f8/attachment-0001.html 

From antoine at sabot-durand.net  Thu May 14 09:48:47 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 14 May 2015 13:48:47 +0000
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
	<3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
	<BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>
	<6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>
Message-ID: <CABu-YBRSzSwp4kxmji2w2v-ZLaVeKTk=a0J0GsRpU=RHsj5E+A@mail.gmail.com>

Yes Mark I know, but it others voiced for it... Now let's the users give
their opinion.
Le jeu. 14 mai 2015 ? 15:22, Mark Struberg <struberg at yahoo.de> a ?crit :

> I DID voice against multiple CDI impls both on the mailing list and on EG
> meetings?
>
> > Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> >
> > Mark,
> >
> > My question wasn?t about the feature which have been discussed for more
> than 2 months. This feature is now going to EDR1 since there wasn?t voice
> against it. And again EDR1 is not final spec. You?ll be able to discuss it
> with the community when it?ll be proposed.
> >
> > Antoine
> >
> >
> >
> >> Le 14 mai 2015 ? 10:36, Mark Struberg <struberg at yahoo.de> a ?crit :
> >>
> >> That usecase is imo not really valid. Such a testing framework would
> need a ClassLoader isolation to work. Just create a child UrlClassLoader
> with your test project in and be done. Otherwise you would get into a total
> mess with static fields etc. It simply makes no sense in my opinion and
> propagates bad practice.
> >>
> >>
> >>> think the fact that there?s no specific use case doesn?t mean we
> should forbid this.
> >> If it requires the impls to do all kind of mad stuff then we at least
> should not require it.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>
> >>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
> >>>
> >>> "One possible use-case this enables is for a library or framework
> (e.g. a testing framework) to use an embedded instance of Weld internally
> for its own needs (dependency injection, events, extensibility). This
> instance would not interfere with the Weld instance used by the
> application."
> >>>
> >>> I think the fact that there's no specific use case doesn't mean we
> should forbid this.
> >>>
> >>> Martin
> >>>
> >>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
> >>>> I still don?t get it what running multiple CDI container on the SAME
> ClassLoader/Thread should be for?
> >>>> What?s the use case?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>>>
> >>>>> Hi Antoine,
> >>>>>
> >>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
> >>>>> Weld instances) has a special CDIProvider implementation [2]:
> >>>>>
> >>>>> * if there's exactly one container running, return this container
> >>>>> * if there are multiple containers running, log an INFO message and
> >>>>> attempt to identify the container by the calling class:
> >>>>> ** if there is only one container aware of the class, return this
> container
> >>>>> ** otherwise return the first container initialized
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> [1]
> >>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
> >>>>>
> >>>>> [2]
> >>>>>
> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
> >>>>>
> >>>>>
> >>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
> >>>>>> Hi all,
> >>>>>>
> >>>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI()
> method description is not compatible with the multiple container
> initialization we allowed in the API.
> >>>>>>
> >>>>>> While running in Java EE getCDI() retuns the current container
> which is fine since there?s only one, but what do we expect from it when
> running in SE?
> >>>>>>
> >>>>>> I thought of 2 simple solutions for EDR1:
> >>>>>>
> >>>>>> 1) make getCDI() return the last CDI object initialized by the
> CDIProvider
> >>>>>> 2) Forbid getCDI() in SE
> >>>>>>
> >>>>>> Of course there?s always the solution of moving the code outside
> CDIProvider, but it?s less simple?
> >>>>>>
> >>>>>> Wdyt,
> >>>>>>
> >>>>>> Antoine
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> cdi-dev mailing list
> >>>>>> cdi-dev at 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.
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Martin Kouba
> >>>>> Software Engineer
> >>>>> Red Hat, Czech Republic
> >>>>> _______________________________________________
> >>>>> cdi-dev mailing list
> >>>>> cdi-dev at 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.
> >>>>
> >>>
> >>> --
> >>> Martin Kouba
> >>> Software Engineer
> >>> Red Hat, Czech Republic
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150514/46f241b6/attachment.html 

From struberg at yahoo.de  Thu May 14 15:53:11 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Thu, 14 May 2015 21:53:11 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <CABu-YBRSzSwp4kxmji2w2v-ZLaVeKTk=a0J0GsRpU=RHsj5E+A@mail.gmail.com>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
	<55544D8C.1040306@redhat.com>
	<3B1502E6-8EF2-43F2-9F4F-BA3AC5B8DC18@yahoo.de>
	<BAB375D0-2222-41A4-9EAC-B8FD844390F4@sabot-durand.net>
	<6F230485-196F-4164-9C2D-EA3C0906F609@yahoo.de>
	<CABu-YBRSzSwp4kxmji2w2v-ZLaVeKTk=a0J0GsRpU=RHsj5E+A@mail.gmail.com>
Message-ID: <84985A3B-4953-40FE-9AF2-03FF15605B90@yahoo.de>

Sure, I just hope that users will try it good enough to pinpoint the same issues Romain and I are thinking about.

At a single point in time for a given Thread and ClassLoader you really need to know which container you should take. 
What happens if you take a Bean<T> from CdiContainer1 and use it in a getReference for CdiContainer2? What about Serialization? What about JNDI? What about resources? Who destroys what? How to deal with Extensions? Tons of questions and I personally don?t have much answers yet.

Again: optionally supporting multiple CDI containers at the same time is fine. But my gut feeling tells me that we should not make this a hard requirement. 

IF we go down that route, then we must really explicitly define an ?id? of the BeanManager during boot.

CDIProvider#getBeanManager(String beanManagerIdentifier).
Otherwise we will have _tons_ of issues on clusters etc.

LieGrue,
strub

> Am 14.05.2015 um 15:48 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
> 
> Yes Mark I know, but it others voiced for it... Now let's the users give their opinion. 
> Le jeu. 14 mai 2015 ? 15:22, Mark Struberg <struberg at yahoo.de> a ?crit :
> I DID voice against multiple CDI impls both on the mailing list and on EG meetings?
> 
> > Am 14.05.2015 um 10:44 schrieb Antoine Sabot-Durand <antoine at sabot-durand.net>:
> >
> > Mark,
> >
> > My question wasn?t about the feature which have been discussed for more than 2 months. This feature is now going to EDR1 since there wasn?t voice against it. And again EDR1 is not final spec. You?ll be able to discuss it with the community when it?ll be proposed.
> >
> > Antoine
> >
> >
> >
> >> Le 14 mai 2015 ? 10:36, Mark Struberg <struberg at yahoo.de> a ?crit :
> >>
> >> That usecase is imo not really valid. Such a testing framework would need a ClassLoader isolation to work. Just create a child UrlClassLoader with your test project in and be done. Otherwise you would get into a total mess with static fields etc. It simply makes no sense in my opinion and propagates bad practice.
> >>
> >>
> >>> think the fact that there?s no specific use case doesn?t mean we should forbid this.
> >> If it requires the impls to do all kind of mad stuff then we at least should not require it.
> >>
> >>
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 14.05.2015 um 09:23 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>
> >>> Just quoting Jozef from the referenced Weld 3.0.0.Alpha8 announcement:
> >>>
> >>> "One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility). This instance would not interfere with the Weld instance used by the application."
> >>>
> >>> I think the fact that there's no specific use case doesn't mean we should forbid this.
> >>>
> >>> Martin
> >>>
> >>> Dne 14.5.2015 v 09:12 Mark Struberg napsal(a):
> >>>> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
> >>>> What?s the use case?
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
> >>>>>
> >>>>> Hi Antoine,
> >>>>>
> >>>>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
> >>>>> Weld instances) has a special CDIProvider implementation [2]:
> >>>>>
> >>>>> * if there's exactly one container running, return this container
> >>>>> * if there are multiple containers running, log an INFO message and
> >>>>> attempt to identify the container by the calling class:
> >>>>> ** if there is only one container aware of the class, return this container
> >>>>> ** otherwise return the first container initialized
> >>>>>
> >>>>> Martin
> >>>>>
> >>>>> [1]
> >>>>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
> >>>>>
> >>>>> [2]
> >>>>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
> >>>>>
> >>>>>
> >>>>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
> >>>>>> Hi all,
> >>>>>>
> >>>>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
> >>>>>>
> >>>>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
> >>>>>>
> >>>>>> I thought of 2 simple solutions for EDR1:
> >>>>>>
> >>>>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
> >>>>>> 2) Forbid getCDI() in SE
> >>>>>>
> >>>>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
> >>>>>>
> >>>>>> Wdyt,
> >>>>>>
> >>>>>> Antoine
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> cdi-dev mailing list
> >>>>>> cdi-dev at 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.
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Martin Kouba
> >>>>> Software Engineer
> >>>>> Red Hat, Czech Republic
> >>>>> _______________________________________________
> >>>>> cdi-dev mailing list
> >>>>> cdi-dev at 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.
> >>>>
> >>>
> >>> --
> >>> Martin Kouba
> >>> Software Engineer
> >>> Red Hat, Czech Republic
> >>
> >
> 



From antoine at sabot-durand.net  Fri May 15 08:23:11 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Fri, 15 May 2015 12:23:11 +0000
Subject: [cdi-dev] Need review for Core/ SE / EE split
Message-ID: <CABu-YBQ02_E=Ni4H27ba3pOibyX4o2MKpTDFfRMiGSDA94ji9Q@mail.gmail.com>

Hi all,

I just finished a complete review of my splitting work integrating all your
remarks.
The core part doesn't have any more references to Java EE, the "bean"
generalization and "Java component" were reverted.
Java SE is an empty part right now (I didn't want to add  new content
before going further). It will contain SE boot chapter and a specific
chapter for context and lifecycle.
Java EE part contains all references to EJB, Java EE components, EL,
servlet, JSF and JSP.
There are probably language standardization work an possible mistakes, so a
deep review of each of view is most welcome:
https://github.com/cdi-spec/cdi/pull/241

Thanks for your help.

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150515/436837cd/attachment.html 

From emijiang6 at googlemail.com  Mon May 18 03:23:56 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Mon, 18 May 2015 08:23:56 +0100
Subject: [cdi-dev] Java EE component class injection point validation
Message-ID: <CAECq3A9jUch3CKRL+R6t5gk4y1Z9BHHiUNu2xWGAqXVOCkVJHQ@mail.gmail.com>

In CDI1.2 spec, section 5.5.7
If a Java EE component class supporting injection that is not a bean has an
injection point of
type InjectionPoint and qualifier @Default, the container automatically
detects the problem
and treats it as a definition error.

How can I plugin this validation? Is there a callback spi I can use to
validate the injection point on JavaEE component? This exception needs to
be thrown during the application deployment.

-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150518/0ea10f48/attachment-0001.html 

From mkouba at redhat.com  Mon May 18 03:48:08 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 18 May 2015 09:48:08 +0200
Subject: [cdi-dev] Java EE component class injection point validation
In-Reply-To: <CAECq3A9jUch3CKRL+R6t5gk4y1Z9BHHiUNu2xWGAqXVOCkVJHQ@mail.gmail.com>
References: <CAECq3A9jUch3CKRL+R6t5gk4y1Z9BHHiUNu2xWGAqXVOCkVJHQ@mail.gmail.com>
Message-ID: <55599938.2050500@redhat.com>

Emily,

I believe this one belongs rather to the weld-dev ML.

Martin

Dne 18.5.2015 v 09:23 Emily Jiang napsal(a):
>
> In CDI1.2 spec, section 5.5.7
> If a Java EE component class supporting injection that is not a bean has
> an injection point of
> type InjectionPoint and qualifier @Default, the container automatically
> detects the problem
> and treats it as a definition error.
>
> How can I plugin this validation? Is there a callback spi I can use to
> validate the injection point on JavaEE component? This exception needs
> to be thrown during the application deployment.
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>


From antoine at sabot-durand.net  Tue May 19 05:33:02 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 19 May 2015 11:33:02 +0200
Subject: [cdi-dev] Today's meeting
Message-ID: <AE065FAB-5B62-460A-9513-91AB0B1788B2@sabot-durand.net>

Hi all,

Today, I propose we discuss the following points :

1) Face to face meeting date, place and content
2) Event ordering PR : https://github.com/cdi-spec/cdi/pull/242 <https://github.com/cdi-spec/cdi/pull/242>
3) issue on CDIProvider and multiple container we overlooked : http://cdi-development-mailing-list.1064426.n5.nabble.com/It-seems-we-missed-a-point-in-CDIProvider-enhancement-td5711451.html <http://cdi-development-mailing-list.1064426.n5.nabble.com/It-seems-we-missed-a-point-in-CDIProvider-enhancement-td5711451.html>
4) If you have feedback on API split they are welcome

Antoine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150519/24ff4807/attachment.html 
-------------- 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/20150519/24ff4807/attachment.bin 

From issues at jboss.org  Tue May 19 13:05:19 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 19 May 2015 13:05:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089125@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.18958.1432055119260@Atlassian.JIRA>

Mark Struberg created CDI-527:
---------------------------------

             Summary: allow proxying of classes with non-private final methods
                 Key: CDI-527
                 URL: https://issues.jboss.org/browse/CDI-527
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Beans
            Reporter: Mark Struberg


Currently we explicitly disallow proxying of classes with non-private final methods. 

EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.

We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May 19 13:07:19 2015
From: issues at jboss.org (George Gastaldi (JIRA))
Date: Tue, 19 May 2015 13:07:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.18962.1432055239251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Gastaldi updated CDI-527:
--------------------------------
    Affects Version/s: 2.0 (discussion)


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 2.0 (discussion)
>            Reporter: Mark Struberg
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May 19 13:29:19 2015
From: issues at jboss.org (Jens Schumann (JIRA))
Date: Tue, 19 May 2015 13:29:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.18979.1432056559201@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069360#comment-13069360 ] 

Jens Schumann commented on CDI-527:
-----------------------------------

+1.

This would simplify CDI integration in a lot of cases. Do we have the same issue with / should talk about interceptors too?



> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 2.0 (discussion)
>            Reporter: Mark Struberg
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May 19 13:42:19 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Tue, 19 May 2015 13:42:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.19005.1432057339376@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069365#comment-13069365 ] 

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

+1 without any new API, this was just a technical constraint I guess which doesnt have real any sense in practise

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 2.0 (discussion)
>            Reporter: Mark Struberg
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May 19 15:02:19 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Tue, 19 May 2015 15:02:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.19080.1432062139486@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069375#comment-13069375 ] 

Mark Struberg commented on CDI-527:
-----------------------------------

I personally like the restriction in many cases. People should really be aware that they need to be careful when they proxy such classes. Although the people writing the producer might not be the people who consume it...

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 2.0 (discussion)
>            Reporter: Mark Struberg
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 20 02:52:20 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 20 May 2015 02:52:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.19632.1432104740677@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-527:
-------------------------------------
    Fix Version/s: 2.0 (discussion)


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 20 02:52:21 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 20 May 2015 02:52:21 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.19639.1432104741183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-527:
-------------------------------------
    Affects Version/s: 1.2.Final
                           (was: 2.0 (discussion))


> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Wed May 20 11:31:56 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 20 May 2015 17:31:56 +0200
Subject: [cdi-dev] F2F city and date choice
Message-ID: <670DFE3A-A316-4A45-8F49-508F5DBB1E26@sabot-durand.net>

Hi Guys,

As we decided yesterday, I created a Doodle to choose the city of the meeting. Keep in mind that this vote is non binding ;) as there are other parameters on the Red Hat side.
Please vote here:

http://doodle.com/v6kn89dfr6vev4as <http://doodle.com/v6kn89dfr6vev4as>


Antoine Sabot-Durand
???????????????
Twitter : @antoine_sd
CDI co-spec lead & eco-system development
Agorava tech lead

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150520/96ef5db0/attachment-0001.html 
-------------- 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/20150520/96ef5db0/attachment-0001.bin 

From j.j.snyder at oracle.com  Wed May 20 13:32:42 2015
From: j.j.snyder at oracle.com (JJ Snyder)
Date: Wed, 20 May 2015 13:32:42 -0400
Subject: [cdi-dev] Spring beans.xml
Message-ID: <555CC53A.8080200@oracle.com>

Does anyone know how to tell Spring to use a different file and not 
"beans.xml"?

Thanks,
JJ

From struberg at yahoo.de  Thu May 21 01:18:59 2015
From: struberg at yahoo.de (Mark Struberg)
Date: Wed, 20 May 2015 22:18:59 -0700
Subject: [cdi-dev] F2F city and date choice
In-Reply-To: <670DFE3A-A316-4A45-8F49-508F5DBB1E26@sabot-durand.net>
Message-ID: <1432185539.62932.YahooMailIosMobile@web121605.mail.ne1.yahoo.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150520/892640eb/attachment.html 

From antoine at sabot-durand.net  Thu May 21 01:24:56 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Thu, 21 May 2015 05:24:56 +0000
Subject: [cdi-dev] F2F city and date choice
In-Reply-To: <1432185539.62932.YahooMailIosMobile@web121605.mail.ne1.yahoo.com>
References: <670DFE3A-A316-4A45-8F49-508F5DBB1E26@sabot-durand.net>
	<1432185539.62932.YahooMailIosMobile@web121605.mail.ne1.yahoo.com>
Message-ID: <CABu-YBQjpRqyR7M8t2dpjsHJ4TKwru0Zrmg+fj9=aeGr_00WJg@mail.gmail.com>

Done,

Thorben and Mark P.. If you want to add a second choice you can do too. But
let's try to keep it 2.

Antoine
Le jeu. 21 mai 2015 ? 07:19, Mark Struberg <struberg at yahoo.de> a ?crit :

> Can you allow multi options? Would like to check Brno and Munich.
>
> Lg,
> Strub
>
>
> Gesendet von Yahoo Mail f?r iPad <https://yho.com/footer0>
>
> Um 20.05.2015 17:31:56 schrieb Antoine Sabot-Durand<'
> antoine at sabot-durand.net'>:
> Hi Guys,
>
> As we decided yesterday, I created a Doodle to choose the city of the
> meeting. Keep in mind that this vote is non binding ;) as there are other
> parameters on the Red Hat side.
> Please vote here:
>
> http://doodle.com/v6kn89dfr6vev4as
>
>
> Antoine Sabot-Durand
> ???????????????
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150521/2e6856cd/attachment.html 

From issues at jboss.org  Thu May 21 08:23:19 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 21 May 2015 08:23:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean
 instance from a proxy
In-Reply-To: <JIRA.12416142.1281270392000@Atlassian.JIRA>
References: <JIRA.12416142.1281270392000@Atlassian.JIRA>
	<JIRA.12416142.1281270392000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12416142.1281270392000.23153.1432210999908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reopened CDI-10:
-----------------------------


I believe this issue is valid and should be reopened. Recently, we've run into problems with two integration scenarios where having this portable way to detect a client proxy and access the bean instance would allow to implement portable "workarounds".

h3. Bean Validation

The spec does not forbid the *field access strategy* to be used for normal-scoped CDI beans. However, this doesn't work because injectable references for normal-scoped beans are client proxies and not direct references to contextual instances. See also https://forum.hibernate.org/viewtopic.php?f=26&t=1039523.

h3. JAX-RS

Weld client proxies lose generic type information which screws up injection of generic params into RESTEasy resource methods. See also WELD-1539.


> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
>                 Key: CDI-10
>                 URL: https://issues.jboss.org/browse/CDI-10
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.0
>            Reporter: Stuart Douglas
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. 
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 08:42:19 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 21 May 2015 08:42:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.23228.1432212139513@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069974#comment-13069974 ] 

Jozef Hartinger commented on CDI-527:
-------------------------------------

{quote}EJB does allow this.{quote}

Can you elaborate on how EJB allows that? Based on the following:

{quote}Only private methods of the bean class and any superclasses except java.lang.Object
may be declared final{quote}

I interpret the EJB spec as explicitly prohibiting this.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 08:53:19 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Thu, 21 May 2015 08:53:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.23301.1432212799527@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069981#comment-13069981 ] 

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

it does

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 09:02:19 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 09:02:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.23310.1432213339810@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069983#comment-13069983 ] 

Mark Struberg commented on CDI-527:
-----------------------------------

I remember a discussion back then with Marina and Linda. And what what I remember the outcome was that it is depending on the term 'Business Method' where final is forbidden. And a 'Business Method' in EJBs must be public. See EJB spec 4.6.5.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 09:13:20 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 09:13:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.23393.1432214000064@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069996#comment-13069996 ] 

Mark Struberg commented on CDI-527:
-----------------------------------

[~jharting] I digged a bit deeper. Seems EJB-3.2 introduced this (non backward compat) restriction. But *only* for NIVs! 
Previously this restriction was only for 'Business Methods'. Which always have been only public methods (this is what is different to CDI).

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From werner.keil at gmail.com  Thu May 21 09:28:40 2015
From: werner.keil at gmail.com (Werner Keil)
Date: Thu, 21 May 2015 15:28:40 +0200
Subject: [cdi-dev] F2F city and date choice
Message-ID: <CAAGawe0LjbqwBM1GX9fHcQ+npaRXNhe6b0Q5R1-uDuYHXXgrSQ@mail.gmail.com>

As London is not in the list, I guess the F2F would take place either
before or after DevoXX UK, but not then.

I voted on the two cities closest to where I expect to be for the next few
months. With enough time and notice, I guess I could also get to the other
two if selected in the end (or another city, as long as it's not too far;-)

Werner

On Thu, May 21, 2015 at 3:13 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at 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:
>
>    1. Spring beans.xml (JJ Snyder)
>    2. Re: F2F city and date choice (Mark Struberg)
>    3. Re: F2F city and date choice (Antoine Sabot-Durand)
>    4. [JBoss JIRA] (CDI-10) Add ability to access a bean instance
>       from a proxy (Martin Kouba (JIRA))
>    5. [JBoss JIRA] (CDI-527) allow proxying of classes with
>       non-private final methods (Jozef Hartinger (JIRA))
>    6. [JBoss JIRA] (CDI-527) allow proxying of classes with
>       non-private final methods (Romain Manni-Bucau (JIRA))
>    7. [JBoss JIRA] (CDI-527) allow proxying of classes with
>       non-private final methods (Mark Struberg (JIRA))
>    8. [JBoss JIRA] (CDI-527) allow proxying of classes with
>       non-private final methods (Mark Struberg (JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 May 2015 13:32:42 -0400
> From: JJ Snyder <j.j.snyder at oracle.com>
> Subject: [cdi-dev] Spring beans.xml
> To: cdi-dev at lists.jboss.org
> Message-ID: <555CC53A.8080200 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Does anyone know how to tell Spring to use a different file and not
> "beans.xml"?
>
> Thanks,
> JJ
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 20 May 2015 22:18:59 -0700
> From: Mark Struberg <struberg at yahoo.de>
> Subject: Re: [cdi-dev] F2F city and date choice
> To: "antoine at sabot-durand.net" <antoine at sabot-durand.net>,
>         "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> Message-ID:
>         <1432185539.62932.YahooMailIosMobile at web121605.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150520/892640eb/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 May 2015 05:24:56 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: Re: [cdi-dev] F2F city and date choice
> To: Mark Struberg <struberg at yahoo.de>,  "cdi-dev at lists.jboss.org"
>         <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBQjpRqyR7M8t2dpjsHJ4TKwru0Zrmg+fj9=
> aeGr_00WJg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Done,
>
> Thorben and Mark P.. If you want to add a second choice you can do too. But
> let's try to keep it 2.
>
> Antoine
> Le jeu. 21 mai 2015 ? 07:19, Mark Struberg <struberg at yahoo.de> a ?crit :
>
> > Can you allow multi options? Would like to check Brno and Munich.
> >
> > Lg,
> > Strub
> >
> >
> > Gesendet von Yahoo Mail f?r iPad <https://yho.com/footer0>
> >
> > Um 20.05.2015 17:31:56 schrieb Antoine Sabot-Durand<'
> > antoine at sabot-durand.net'>:
> > Hi Guys,
> >
> > As we decided yesterday, I created a Doodle to choose the city of the
> > meeting. Keep in mind that this vote is non binding ;) as there are other
> > parameters on the Red Hat side.
> > Please vote here:
> >
> > http://doodle.com/v6kn89dfr6vev4as
> >
> >
> > Antoine Sabot-Durand
> > ???????????????
> > Twitter : @antoine_sd
> > CDI co-spec lead & eco-system development
> > Agorava tech lead
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20150521/2e6856cd/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 May 2015 08:23:19 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-10) Add ability to access a bean
>         instance from a proxy
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12416142.1281270392000.23153.1432210999908 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>      [
> https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Martin Kouba reopened CDI-10:
> -----------------------------
>
>
> I believe this issue is valid and should be reopened. Recently, we've run
> into problems with two integration scenarios where having this portable way
> to detect a client proxy and access the bean instance would allow to
> implement portable "workarounds".
>
> h3. Bean Validation
>
> The spec does not forbid the *field access strategy* to be used for
> normal-scoped CDI beans. However, this doesn't work because injectable
> references for normal-scoped beans are client proxies and not direct
> references to contextual instances. See also
> https://forum.hibernate.org/viewtopic.php?f=26&t=1039523.
>
> h3. JAX-RS
>
> Weld client proxies lose generic type information which screws up
> injection of generic params into RESTEasy resource methods. See also
> WELD-1539.
>
>
> > Add ability to access a bean instance from a proxy
> > --------------------------------------------------
> >
> >                 Key: CDI-10
> >                 URL: https://issues.jboss.org/browse/CDI-10
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans
> >    Affects Versions: 1.0
> >            Reporter: Stuart Douglas
> >
> > There are occasions when it would be useful to access a bean instance
> directly from a proxy. This could be achieved by making all proxies
> assignable to an interface (say BeanProxy) that provides a
> getBeanInstance() method.
> > Client code that needs access to the actual instance can check if the
> object is assignable to the BeanProxy interface and then call
> getBeanInstance() to get the actual instance if required.
> > This is something that is probably more useful to extension writers than
> the end user, but there have already been a few requests on the weld forum
> about this so it is probably worth considering.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 May 2015 08:42:19 -0400 (EDT)
> From: "Jozef Hartinger (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
>         with non-private final methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12572138.1432055089000.23228.1432212139513 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069974#comment-13069974
> ]
>
> Jozef Hartinger commented on CDI-527:
> -------------------------------------
>
> {quote}EJB does allow this.{quote}
>
> Can you elaborate on how EJB allows that? Based on the following:
>
> {quote}Only private methods of the bean class and any superclasses except
> java.lang.Object
> may be declared final{quote}
>
> I interpret the EJB spec as explicitly prohibiting this.
>
> > allow proxying of classes with non-private final methods
> > --------------------------------------------------------
> >
> >                 Key: CDI-527
> >                 URL: https://issues.jboss.org/browse/CDI-527
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans
> >    Affects Versions: 1.2.Final
> >            Reporter: Mark Struberg
> >             Fix For: 2.0 (discussion)
> >
> >
> > Currently we explicitly disallow proxying of classes with non-private
> final methods.
> > EJB _does_ allow this. And there are a few final methods in the JDK and
> other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a
> producer method for it.
> > We might rethink our decision and allow it. Probably with an own
> annotation like @AllowProxying which disables this check for certain cases
> (subclass managed-beans or producers).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 May 2015 08:53:19 -0400 (EDT)
> From: "Romain Manni-Bucau (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
>         with non-private final methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12572138.1432055089000.23301.1432212799527 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069981#comment-13069981
> ]
>
> Romain Manni-Bucau commented on CDI-527:
> ----------------------------------------
>
> it does
>
> > allow proxying of classes with non-private final methods
> > --------------------------------------------------------
> >
> >                 Key: CDI-527
> >                 URL: https://issues.jboss.org/browse/CDI-527
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans
> >    Affects Versions: 1.2.Final
> >            Reporter: Mark Struberg
> >             Fix For: 2.0 (discussion)
> >
> >
> > Currently we explicitly disallow proxying of classes with non-private
> final methods.
> > EJB _does_ allow this. And there are a few final methods in the JDK and
> other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a
> producer method for it.
> > We might rethink our decision and allow it. Probably with an own
> annotation like @AllowProxying which disables this check for certain cases
> (subclass managed-beans or producers).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 May 2015 09:02:19 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
>         with non-private final methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12572138.1432055089000.23310.1432213339810 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069983#comment-13069983
> ]
>
> Mark Struberg commented on CDI-527:
> -----------------------------------
>
> I remember a discussion back then with Marina and Linda. And what what I
> remember the outcome was that it is depending on the term 'Business Method'
> where final is forbidden. And a 'Business Method' in EJBs must be public.
> See EJB spec 4.6.5.
>
> > allow proxying of classes with non-private final methods
> > --------------------------------------------------------
> >
> >                 Key: CDI-527
> >                 URL: https://issues.jboss.org/browse/CDI-527
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans
> >    Affects Versions: 1.2.Final
> >            Reporter: Mark Struberg
> >             Fix For: 2.0 (discussion)
> >
> >
> > Currently we explicitly disallow proxying of classes with non-private
> final methods.
> > EJB _does_ allow this. And there are a few final methods in the JDK and
> other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a
> producer method for it.
> > We might rethink our decision and allow it. Probably with an own
> annotation like @AllowProxying which disables this check for certain cases
> (subclass managed-beans or producers).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 21 May 2015 09:13:20 -0400 (EDT)
> From: "Mark Struberg (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes
>         with non-private final methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12572138.1432055089000.23393.1432214000064 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069996#comment-13069996
> ]
>
> Mark Struberg commented on CDI-527:
> -----------------------------------
>
> [~jharting] I digged a bit deeper. Seems EJB-3.2 introduced this (non
> backward compat) restriction. But *only* for NIVs!
> Previously this restriction was only for 'Business Methods'. Which always
> have been only public methods (this is what is different to CDI).
>
> > allow proxying of classes with non-private final methods
> > --------------------------------------------------------
> >
> >                 Key: CDI-527
> >                 URL: https://issues.jboss.org/browse/CDI-527
> >             Project: CDI Specification Issues
> >          Issue Type: Feature Request
> >          Components: Beans
> >    Affects Versions: 1.2.Final
> >            Reporter: Mark Struberg
> >             Fix For: 2.0 (discussion)
> >
> >
> > Currently we explicitly disallow proxying of classes with non-private
> final methods.
> > EJB _does_ allow this. And there are a few final methods in the JDK and
> other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a
> producer method for it.
> > We might rethink our decision and allow it. Probably with an own
> annotation like @AllowProxying which disables this check for certain cases
> (subclass managed-beans or producers).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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 54, Issue 18
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150521/00375e60/attachment-0001.html 

From antonio.goncalves at gmail.com  Thu May 21 09:49:18 2015
From: antonio.goncalves at gmail.com (Antonio Goncalves)
Date: Thu, 21 May 2015 15:49:18 +0200
Subject: [cdi-dev] F2F city and date choice
In-Reply-To: <670DFE3A-A316-4A45-8F49-508F5DBB1E26@sabot-durand.net>
References: <670DFE3A-A316-4A45-8F49-508F5DBB1E26@sabot-durand.net>
Message-ID: <CA+ZZq9-cPWz0mTyUmH-XeLE=UQr7BBHNKbH612wi73_ptRDVWA@mail.gmail.com>

Voted !

BTW, and what about London ?

On Wed, May 20, 2015 at 5:31 PM, Antoine Sabot-Durand <
antoine at sabot-durand.net> wrote:

> Hi Guys,
>
> As we decided yesterday, I created a Doodle to choose the city of the
> meeting. Keep in mind that this vote is non binding ;) as there are other
> parameters on the Red Hat side.
> Please vote here:
>
> http://doodle.com/v6kn89dfr6vev4as
>
>
> Antoine Sabot-Durand
> ???????????????
> Twitter : @antoine_sd
> CDI co-spec lead & eco-system development
> Agorava tech lead
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150521/b1c82900/attachment.html 

From issues at jboss.org  Thu May 21 10:39:19 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 21 May 2015 10:39:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.24043.1432219159670@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070081#comment-13070081 ] 

Jozef Hartinger commented on CDI-527:
-------------------------------------

OK, so EJB does not allow it either, correct?

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From jharting at redhat.com  Thu May 21 10:49:09 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 21 May 2015 16:49:09 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <CAOqetn8R2C1eyfVWi6d_vwuNj9svTQmLrRGTL+ev2A9ZTb-iew@mail.gmail.com>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>
	<CAOqetn8R2C1eyfVWi6d_vwuNj9svTQmLrRGTL+ev2A9ZTb-iew@mail.gmail.com>
Message-ID: <555DF065.60804@redhat.com>

What RI behavior are we talking about? The RI does not implement 
CDIProvider.initialize()

On 05/14/2015 01:26 PM, John D. Ament wrote:
> The behavior of the RI makes no sense IMHO.  If someone else calls 
> initialize of the CDIProvider I'm working on, now my state is all 
> messed up.  Not good behavior.


From jharting at redhat.com  Thu May 21 10:58:48 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 21 May 2015 16:58:48 +0200
Subject: [cdi-dev] It seems we missed a point in CDIProvider enhancement
In-Reply-To: <86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
References: <66D6DBB6-154E-482C-82EA-B57D8E57AC75@sabot-durand.net>	<55543C85.3050006@redhat.com>
	<86B80377-4BAF-4FC7-A69C-5DBEA5AC7785@yahoo.de>
Message-ID: <555DF2A8.6010608@redhat.com>

Basically any library/framework that has some state (e.g. web service 
client, BMPS, etc...) could use embedded CDI instance internally for 
dependency injection and extensibility (events) purposes. This embedded 
container should not interfere with the application beans anyhow.

On 05/14/2015 09:12 AM, Mark Struberg wrote:
> I still don?t get it what running multiple CDI container on the SAME ClassLoader/Thread should be for?
> What?s the use case?
>
> LieGrue,
> strub
>
>
>> Am 14.05.2015 um 08:11 schrieb Martin Kouba <mkouba at redhat.com>:
>>
>> Hi Antoine,
>>
>> Weld SE 3.0.0.Alpha8 [1] (which allows to start multiple independent
>> Weld instances) has a special CDIProvider implementation [2]:
>>
>> * if there's exactly one container running, return this container
>> * if there are multiple containers running, log an INFO message and
>> attempt to identify the container by the calling class:
>> ** if there is only one container aware of the class, return this container
>> ** otherwise return the first container initialized
>>
>> Martin
>>
>> [1]
>> http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/
>>
>> [2]
>> https://github.com/weld/core/blob/master/environments/se/core/src/main/java/org/jboss/weld/environment/se/WeldSEProvider.java
>>
>>
>> Dne 13.5.2015 v 19:08 Antoine Sabot-Durand napsal(a):
>>> Hi all,
>>>
>>> While cleaning Javadoc in CDIProvider, I realized that getCDI() method description is not compatible with the multiple container initialization we allowed in the API.
>>>
>>> While running in Java EE getCDI() retuns the current container which is fine since there?s only one, but what do we expect from it when running in SE?
>>>
>>> I thought of 2 simple solutions for EDR1:
>>>
>>> 1) make getCDI() return the last CDI object initialized by the CDIProvider
>>> 2) Forbid getCDI() in SE
>>>
>>> Of course there?s always the solution of moving the code outside CDIProvider, but it?s less simple?
>>>
>>> Wdyt,
>>>
>>> Antoine
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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.
>>>
>> -- 
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at 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 at 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.


From issues at jboss.org  Thu May 21 12:32:19 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 12:32:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.24300.1432225939983@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070126#comment-13070126 ] 

Mark Struberg commented on CDI-527:
-----------------------------------

No, rather the oposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.

F

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 12:32:20 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 12:32:20 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.24308.1432225940944@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070126#comment-13070126 ] 

Mark Struberg edited comment on CDI-527 at 5/21/15 12:31 PM:
-------------------------------------------------------------

No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.

F


was (Author: struberg):
No, rather the oposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.

F

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 12:32:21 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 12:32:21 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.24314.1432225941265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070126#comment-13070126 ] 

Mark Struberg edited comment on CDI-527 at 5/21/15 12:32 PM:
-------------------------------------------------------------

No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.


was (Author: struberg):
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.

F

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Thu May 21 12:33:21 2015
From: issues at jboss.org (Mark Struberg (JIRA))
Date: Thu, 21 May 2015 12:33:21 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.24329.1432226001354@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070126#comment-13070126 ] 

Mark Struberg edited comment on CDI-527 at 5/21/15 12:33 PM:
-------------------------------------------------------------

No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API (and the final public method in question is not in that set of API methods)! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.


was (Author: struberg):
No, rather the opposite. EJB allows it. But most probably purely as side effect. Up to and including EJB-3.1 all non 'Business Methods' can be final. That includes package and protected methods for @Local and NIVs or even public methods if you have an EJB API! EJB really did only care about the proxying of their 'Business Methods'. From this pov CDI is really the same, BUT there is one huge difference: In CDI we treat much more methods as 'Business Methods'. E.g. it is perfectly fine to do a @Inject SelfClass self and invoke a protected or package scoped method on it. So for CDI all non-private, non-static methods are 'Business Methods' and can get intercepted, decorated, and proxied.

Only in EJB-3.2 the NIV case was 'fixed'. Or rather got broken in hindsight of backward compat... I already had a talk with one from the EJB EG who agreed that this was most likely an unintentional backward incompatible change. It also makes zero sense for NIV EJBs as they _explicitely_ declare that still only public methods are 'Business Methods'.

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri May 22 05:53:19 2015
From: issues at jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 22 May 2015 05:53:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.25512.1432288399661@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070298#comment-13070298 ] 

Jozef Hartinger commented on CDI-527:
-------------------------------------

I still fail to see how EJB "allows this". Can you provide a code sample of a session bean with non-private final method that is valid according to EJB 3.2?

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri May 22 06:33:19 2015
From: issues at jboss.org (Romain Manni-Bucau (JIRA))
Date: Fri, 22 May 2015 06:33:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-527) allow proxying of classes with
 non-private final methods
In-Reply-To: <JIRA.12572138.1432055089000@Atlassian.JIRA>
References: <JIRA.12572138.1432055089000@Atlassian.JIRA>
	<JIRA.12572138.1432055089000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572138.1432055089000.25604.1432290799609@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070311#comment-13070311 ] 

Romain Manni-Bucau commented on CDI-527:
----------------------------------------

@Jozef: just use a parent class with a protected final method. This is not forbidden. That said 3.2 should remove this constraint since that's a regression from 3.1.

last point: why do we care about EJB at all? CDi just allow an integration with EJB but EJB shouldn't be the first model (in particular because it defines this contract definition which is not the case in CDI where internal methods are seen as well).

> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
>                 Key: CDI-527
>                 URL: https://issues.jboss.org/browse/CDI-527
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Beans
>    Affects Versions: 1.2.Final
>            Reporter: Mark Struberg
>             Fix For: 2.0 (discussion)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods. 
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Tue May 26 05:33:19 2015
From: issues at jboss.org (Tomas Remes (JIRA))
Date: Tue, 26 May 2015 05:33:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-528) Minor inconsistency in Built-in
 qualifiers chapter
In-Reply-To: <JIRA.12572666.1432632750000@Atlassian.JIRA>
References: <JIRA.12572666.1432632750000@Atlassian.JIRA>
	<JIRA.12572666.1432632750303@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572666.1432632750000.29525.1432632799381@Atlassian.JIRA>

Tomas Remes created CDI-528:
-------------------------------

             Summary: Minor inconsistency in Built-in qualifiers chapter
                 Key: CDI-528
                 URL: https://issues.jboss.org/browse/CDI-528
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Tomas Remes
            Priority: Minor


2.3.1. Built-in qualifier types states:
{quote}
If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default .
{quote}

This means that following bean has @Named, @Default, @Any qualifiers:
{code}
@Named
public class Dog {}
{code}
 but this one is not required to have @Default qualifier:
{code}
@Named
@Any
public class Dog {}
{code}
It doesn't make much sense IMHO. 





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From antoine at sabot-durand.net  Tue May 26 06:24:15 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Tue, 26 May 2015 12:24:15 +0200
Subject: [cdi-dev] No meeting today
Message-ID: <98F27BD0-AE2D-4F1D-BA7F-382847295864@sabot-durand.net>

Hi all,

I won?t be available for the meeting tonight. Feedback on https://github.com/cdi-spec/cdi/pull/241 <https://github.com/cdi-spec/cdi/pull/241> is always welcome.

Antoine


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150526/b7c8d5a6/attachment.html 
-------------- 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/20150526/b7c8d5a6/attachment.bin 

From issues at jboss.org  Tue May 26 06:33:19 2015
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 26 May 2015 06:33:19 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-528) Minor inconsistency in Built-in
 qualifiers chapter
In-Reply-To: <JIRA.12572666.1432632750000@Atlassian.JIRA>
References: <JIRA.12572666.1432632750000@Atlassian.JIRA>
	<JIRA.12572666.1432632750000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572666.1432632750000.29662.1432636399543@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070946#comment-13070946 ] 

Martin Kouba commented on CDI-528:
----------------------------------

In fact, this one:
{code:java}
@Any
class Dog {}
{code}
is not required to have the additional @Default qualifier either.

> Minor inconsistency in Built-in qualifiers chapter
> --------------------------------------------------
>
>                 Key: CDI-528
>                 URL: https://issues.jboss.org/browse/CDI-528
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Tomas Remes
>            Priority: Minor
>
> 2.3.1. Built-in qualifier types states:
> {quote}
> If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default .
> {quote}
> This means that following bean has @Named, @Default, @Any qualifiers:
> {code}
> @Named
> public class Dog {}
> {code}
>  but this one is not required to have @Default qualifier:
> {code}
> @Named
> @Any
> public class Dog {}
> {code}
> It doesn't make much sense IMHO. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 27 04:20:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 27 May 2015 04:20:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-509) Upgrade to latest felix plugin in
	API JAR
In-Reply-To: <JIRA.12564530.1425217548000@Atlassian.JIRA>
References: <JIRA.12564530.1425217548000@Atlassian.JIRA>
	<JIRA.12564530.1425217548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564530.1425217548000.2838.1432714802297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reopened CDI-509:
--------------------------------------
      Assignee: Antoine Sabot-Durand  (was: John Ament)


re-open to link the right PR

> Upgrade to latest felix plugin in API JAR
> -----------------------------------------
>
>                 Key: CDI-509
>                 URL: https://issues.jboss.org/browse/CDI-509
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Javadoc and API
>    Affects Versions: 1.2.Final
>            Reporter: John Ament
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR1
>
>
> Upgrade to the latest felix plugin in the API JAR to allow the API to include lambdas (version 2.5.3)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 27 05:19:03 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 27 May 2015 05:19:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.2999.1432718343364@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand reopened CDI-26:
-------------------------------------


We have overlooked an issue regarding multiple container support.
http://cdi-development-mailing-list.1064426.n5.nabble.com/It-seems-we-missed-a-point-in-CDIProvider-enhancement-tt5711451.html.
Correction for EDR1 or enhance proposal should be done to address this point.

> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0, 1.1.PFD, 1.2.Final
>            Reporter: Pete Muir
>            Assignee: John Ament
>             Fix For: 2.0-EDR1
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From jharting at redhat.com  Wed May 27 05:20:50 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 27 May 2015 11:20:50 +0200
Subject: [cdi-dev] CDI-26 feedback
Message-ID: <55658C72.4040305@redhat.com>

Hi all,

I'd like to raise several concerns with the CDI-26 resolution that I 
either forgot to raise before or were lost in the process.

1) Bean discovery in SE

I was under the impression that the task to define bean discovery for SE 
was postponed post EDR1 yet the PR for CDI-26 that has been merged 
defines bean discovery in SE explicitly 
https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44

I am concerned about the way it is defined currently as it requires that 
the CDI implementation eagerly loads/scans each and every class found on 
the classpath during initialization. Due to performance implications of 
this I am convinced that this is not the desired behavior. It may be 
useful to support this for some use-cases with e.g. a special container 
mode but I doubt this should be the default behavior for CDI in SE. 
Let's not forget to fix this.

2) CDIProvider.isInitialized()

First of all, good job on removing the constraints, preventing multiple 
parallel container support, from the API. One missing piece seems to be 
CDIProvider.isInitialized(). The JavaDoc says: " Determines whether or 
not this CDIProvider has been initialized or not"

My understanding is that it is supposed to indicate whether a CDI object 
is in initialized state yet or whether it has been shut down. If my 
understanding is correct then this method should probably be moved to 
the CDI class instead. Due to the possible 1-to-n mapping between CDI 
and CDIProvider it's not correct to have this method on CDIProvider

Jozef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/e0f9ac33/attachment-0001.html 

From john.d.ament at gmail.com  Wed May 27 07:40:31 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 27 May 2015 11:40:31 +0000
Subject: [cdi-dev] Bootstrap API - remove requirement for concurrent CDIs
Message-ID: <CAOqetn9D5wrixbJEpJadYjyQz4O8HdCzW+TpMiGkrYX_vuLnKg@mail.gmail.com>

All,

I've raised a pull request to explicitly not require an implementation to
support concurrent CDI instances.

https://github.com/cdi-spec/cdi/pull/247

Please let me know your thoughts.  I would have done it last week, but ran
into some issues at the end.  Sorry for the delay.

In addition, I won't be able to attend next Tuesday's meeting.  Please let
me know if you were planning to discuss the change at the meeting.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/07bec9ef/attachment.html 

From issues at jboss.org  Wed May 27 08:53:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 27 May 2015 08:53:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-529) Define bean discovery rules when
 CDI in Java SE
In-Reply-To: <JIRA.12572959.1432731138000@Atlassian.JIRA>
References: <JIRA.12572959.1432731138000@Atlassian.JIRA>
	<JIRA.12572959.1432731138730@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572959.1432731138000.3935.1432731182264@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-529:
----------------------------------------

             Summary: 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)

From john.d.ament at gmail.com  Wed May 27 08:57:29 2015
From: john.d.ament at gmail.com (John D. Ament)
Date: Wed, 27 May 2015 12:57:29 +0000
Subject: [cdi-dev] CDI-26 feedback
In-Reply-To: <55658C72.4040305@redhat.com>
References: <55658C72.4040305@redhat.com>
Message-ID: <CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>

Jozef,

Neither was lost, just not in scope for us to get EDR1 out the door.

1. Antoine just now raised a separate issue.

2. EDR1 infers that only a single CDI instance is associated to a
CDIProvider (so they're 1:1).  We can move this after EDR1.

John

On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting at redhat.com> wrote:

>  Hi all,
>
> I'd like to raise several concerns with the CDI-26 resolution that I
> either forgot to raise before or were lost in the process.
>
> 1) Bean discovery in SE
>
> I was under the impression that the task to define bean discovery for SE
> was postponed post EDR1 yet the PR for CDI-26 that has been merged defines
> bean discovery in SE explicitly
> https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44
>
> I am concerned about the way it is defined currently as it requires that
> the CDI implementation eagerly loads/scans each and every class found on
> the classpath during initialization. Due to performance implications of
> this I am convinced that this is not the desired behavior. It may be useful
> to support this for some use-cases with e.g. a special container mode but I
> doubt this should be the default behavior for CDI in SE. Let's not forget
> to fix this.
>
> 2) CDIProvider.isInitialized()
>
> First of all, good job on removing the constraints, preventing multiple
> parallel container support, from the API. One missing piece seems to be
> CDIProvider.isInitialized(). The JavaDoc says: " Determines whether or not
> this CDIProvider has been initialized or not"
>
> My understanding is that it is supposed to indicate whether a CDI object
> is in initialized state yet or whether it has been shut down. If my
> understanding is correct then this method should probably be moved to the
> CDI class instead. Due to the possible 1-to-n mapping between CDI and
> CDIProvider it's not correct to have this method on CDIProvider
>
> Jozef
>  _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/f0d226d8/attachment.html 

From issues at jboss.org  Wed May 27 09:09:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 27 May 2015 09:09:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-530) Specify context control and
 built-in context behavior in Java SE
In-Reply-To: <JIRA.12572967.1432732116000@Atlassian.JIRA>
References: <JIRA.12572967.1432732116000@Atlassian.JIRA>
	<JIRA.12572967.1432732116420@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12572967.1432732116000.4055.1432732142222@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-530:
----------------------------------------

             Summary: Specify context control and built-in context behavior in Java SE
                 Key: CDI-530
                 URL: https://issues.jboss.org/browse/CDI-530
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Java SE Integration
    Affects Versions: 1.2.Final
            Reporter: Antoine Sabot-Durand


We should define how built-in context behave and provide a mean to start and stop contexts when CDI is used in Java SE 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Wed May 27 09:23:03 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Wed, 27 May 2015 09:23:03 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-26) Bootstrap API for CDI
In-Reply-To: <JIRA.12427722.1294674288000@Atlassian.JIRA>
References: <JIRA.12427722.1294674288000@Atlassian.JIRA>
	<JIRA.12427722.1294674288000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12427722.1294674288000.4207.1432732983736@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067794#comment-13067794 ] 

Antoine Sabot-Durand edited comment on CDI-26 at 5/27/15 9:22 AM:
------------------------------------------------------------------

Class scanning and context control will be addressed in other tickets : CDI-529 and CDI-530


was (Author: antoinesabot-durand):
Class scanning and context control will be addressed in other tickets

> Bootstrap API for CDI
> ---------------------
>
>                 Key: CDI-26
>                 URL: https://issues.jboss.org/browse/CDI-26
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Packaging and Deployment
>    Affects Versions: 1.0, 1.1.PFD, 1.2.Final
>            Reporter: Pete Muir
>            Assignee: John Ament
>             Fix For: 2.0-EDR1
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5417 for example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From mjremijan at yahoo.com  Wed May 27 09:23:23 2015
From: mjremijan at yahoo.com (Michael Remijan)
Date: Wed, 27 May 2015 13:23:23 +0000 (UTC)
Subject: [cdi-dev] Stopping priority event handling?
Message-ID: <805942373.259274.1432733003794.JavaMail.yahoo@mail.yahoo.com>

If this question has already been discussed, I apologize. ?I want to know if there was any talk about stopping event processing for @Priority events? ?The use case I'm thinking of is 1st verifying user data then 2nd performing whatever action the user wanted. ?I thought the UI layer (desktop application) can published an event where observers use the @Priority annotation so you get the correct ordering of verification then performing the user's action. If verification fails, event process should stop. ?Is there a way to do this or has something like this been discussed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/6c636c6b/attachment.html 

From antoine at sabot-durand.net  Wed May 27 09:34:11 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 27 May 2015 15:34:11 +0200
Subject: [cdi-dev] CDI-26 feedback
In-Reply-To: <CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
References: <55658C72.4040305@redhat.com>
	<CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
Message-ID: <1C903501-7D3B-4164-BEF1-689CBD5ACBA7@sabot-durand.net>


> Le 27 mai 2015 ? 14:57, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> Jozef,
> 
> Neither was lost, just not in scope for us to get EDR1 out the door.
> 
> 1. Antoine just now raised a separate issue.

Perhaps we should state in EDR (in a side note) that it will be addressed later and ask for user input. Wdyt?

Now if there are real issues in producing a EDR1 simple with all discovery mode we could restrict the bean discovery mode by supporting only ?none? for the EDR1 (side note again).

I understand that it?s not totally satisfying to not be able to release all the feature at once, but let?s face it, CDI-26 has been around for 4,5 years so splitting it in smaller part to resolve them one by one seems the best solution to get out Java SE support.

> 
> 2. EDR1 infers that only a single CDI instance is associated to a CDIProvider (so they're 1:1).  We can move this after EDR1.

Unless Jozef has a proposal to solve the issue for getCdi() and that we all agree on.

In the other case I will add a ticket for the multiple container support in SE. That could even be wise since it?s a controversial feature (Mark is against it), so having a specific place to discuss it could be a better solution.

Jozef, any thought about this ?

Antoine


> John
> 
> On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>> wrote:
> Hi all,
> 
> I'd like to raise several concerns with the CDI-26 resolution that I either forgot to raise before or were lost in the process.
> 
> 1) Bean discovery in SE
> 
> I was under the impression that the task to define bean discovery for SE was postponed post EDR1 yet the PR for CDI-26 that has been merged defines bean discovery in SE explicitly https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44 <https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44>
> 
> I am concerned about the way it is defined currently as it requires that the CDI implementation eagerly loads/scans each and every class found on the classpath during initialization. Due to performance implications of this I am convinced that this is not the desired behavior. It may be useful to support this for some use-cases with e.g. a special container mode but I doubt this should be the default behavior for CDI in SE. Let's not forget to fix this.
> 
> 2) CDIProvider.isInitialized()
> 
> First of all, good job on removing the constraints, preventing multiple parallel container support, from the API. One missing piece seems to be CDIProvider.isInitialized(). The JavaDoc says: " Determines whether or not this CDIProvider has been initialized or not"
> 
> My understanding is that it is supposed to indicate whether a CDI object is in initialized state yet or whether it has been shut down. If my understanding is correct then this method should probably be moved to the CDI class instead. Due to the possible 1-to-n mapping between CDI and CDIProvider it's not correct to have this method on CDIProvider
> 
> Jozef
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/acd01023/attachment-0001.html 
-------------- 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/20150527/acd01023/attachment-0001.bin 

From antoine at sabot-durand.net  Wed May 27 09:38:35 2015
From: antoine at sabot-durand.net (Antoine Sabot-Durand)
Date: Wed, 27 May 2015 15:38:35 +0200
Subject: [cdi-dev] CDI-26 feedback
In-Reply-To: <CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
References: <55658C72.4040305@redhat.com>
	<CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
Message-ID: <5B1D479D-CD27-46C4-B22B-3F8BAC7E517B@sabot-durand.net>

Forgot to say that I removed CDI-26 from EDR1 for the moment (until we agree on what?s is done now and what will be done after and how we notice that in the draft).
So John?s work is in CDI-26 branch of the repo. It?s more convenient to work on other EDR feature like this.

Antoine


> Le 27 mai 2015 ? 14:57, John D. Ament <john.d.ament at gmail.com> a ?crit :
> 
> Jozef,
> 
> Neither was lost, just not in scope for us to get EDR1 out the door.
> 
> 1. Antoine just now raised a separate issue.
> 
> 2. EDR1 infers that only a single CDI instance is associated to a CDIProvider (so they're 1:1).  We can move this after EDR1.
> 
> John
> 
> On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting at redhat.com <mailto:jharting at redhat.com>> wrote:
> Hi all,
> 
> I'd like to raise several concerns with the CDI-26 resolution that I either forgot to raise before or were lost in the process.
> 
> 1) Bean discovery in SE
> 
> I was under the impression that the task to define bean discovery for SE was postponed post EDR1 yet the PR for CDI-26 that has been merged defines bean discovery in SE explicitly https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44 <https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44>
> 
> I am concerned about the way it is defined currently as it requires that the CDI implementation eagerly loads/scans each and every class found on the classpath during initialization. Due to performance implications of this I am convinced that this is not the desired behavior. It may be useful to support this for some use-cases with e.g. a special container mode but I doubt this should be the default behavior for CDI in SE. Let's not forget to fix this.
> 
> 2) CDIProvider.isInitialized()
> 
> First of all, good job on removing the constraints, preventing multiple parallel container support, from the API. One missing piece seems to be CDIProvider.isInitialized(). The JavaDoc says: " Determines whether or not this CDIProvider has been initialized or not"
> 
> My understanding is that it is supposed to indicate whether a CDI object is in initialized state yet or whether it has been shut down. If my understanding is correct then this method should probably be moved to the CDI class instead. Due to the possible 1-to-n mapping between CDI and CDIProvider it's not correct to have this method on CDIProvider
> 
> Jozef
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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 at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/5828c060/attachment.html 
-------------- 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/20150527/5828c060/attachment.bin 

From jharting at redhat.com  Thu May 28 02:18:21 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 28 May 2015 08:18:21 +0200
Subject: [cdi-dev] CDI-26 feedback
In-Reply-To: <CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
References: <55658C72.4040305@redhat.com>
	<CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
Message-ID: <5566B32D.6050701@redhat.com>

The fact that the spec does not require parallel container support does 
not imply there is always a 1:1 relationship. An implementation or a 
future version of the spec are free to support this. I am OK with 
dealing with this post EDR1.

On 05/27/2015 02:57 PM, John D. Ament wrote:
> 2. EDR1 infers that only a single CDI instance is associated to a 
> CDIProvider (so they're 1:1).  We can move this after EDR1.


From jharting at redhat.com  Thu May 28 02:21:14 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 28 May 2015 08:21:14 +0200
Subject: [cdi-dev] CDI-26 feedback
In-Reply-To: <1C903501-7D3B-4164-BEF1-689CBD5ACBA7@sabot-durand.net>
References: <55658C72.4040305@redhat.com>
	<CAOqetn-rYLqGEYaMDjQgFJ_nfQxbZ64-TBvg1BM6SQYSoGrYOQ@mail.gmail.com>
	<1C903501-7D3B-4164-BEF1-689CBD5ACBA7@sabot-durand.net>
Message-ID: <5566B3DA.20809@redhat.com>



On 05/27/2015 03:34 PM, Antoine Sabot-Durand wrote:
>
>> Le 27 mai 2015 ? 14:57, John D. Ament <john.d.ament at gmail.com 
>> <mailto:john.d.ament at gmail.com>> a ?crit :
>>
>> Jozef,
>>
>> Neither was lost, just not in scope for us to get EDR1 out the door.
>>
>> 1. Antoine just now raised a separate issue.
>
> Perhaps we should state in EDR (in a side note) that it will be 
> addressed later and ask for user input. Wdyt?
>
> Now if there are real issues in producing a EDR1 simple with all 
> discovery mode we could restrict the bean discovery mode by supporting 
> only ?none? for the EDR1 (side note again).
It's neither "all" nor "none" discovery modes that I am concerned about. 
It' implicit bean archives with no beans.xml that are problematic.
>
> I understand that it?s not totally satisfying to not be able to 
> release all the feature at once, but let?s face it, CDI-26 has been 
> around for 4,5 years so splitting it in smaller part to resolve them 
> one by one seems the best solution to get out Java SE support.
>
>>
>> 2. EDR1 infers that only a single CDI instance is associated to a 
>> CDIProvider (so they're 1:1).  We can move this after EDR1.
>
> Unless Jozef has a proposal to solve the issue for getCdi() and that 
> we all agree on.
>
> In the other case I will add a ticket for the multiple container 
> support in SE. That could even be wise since it?s a controversial 
> feature (Mark is against it), so having a specific place to discuss it 
> could be a better solution.
>
> Jozef, any thought about this ?
Sounds good to me.
>
> Antoine
>
>
>> John
>>
>> On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting at redhat.com 
>> <mailto:jharting at redhat.com>> wrote:
>>
>>     Hi all,
>>
>>     I'd like to raise several concerns with the CDI-26 resolution
>>     that I either forgot to raise before or were lost in the process.
>>
>>     1) Bean discovery in SE
>>
>>     I was under the impression that the task to define bean discovery
>>     for SE was postponed post EDR1 yet the PR for CDI-26 that has
>>     been merged defines bean discovery in SE explicitly
>>     https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44
>>
>>     I am concerned about the way it is defined currently as it
>>     requires that the CDI implementation eagerly loads/scans each and
>>     every class found on the classpath during initialization. Due to
>>     performance implications of this I am convinced that this is not
>>     the desired behavior. It may be useful to support this for some
>>     use-cases with e.g. a special container mode but I doubt this
>>     should be the default behavior for CDI in SE. Let's not forget to
>>     fix this.
>>
>>     2) CDIProvider.isInitialized()
>>
>>     First of all, good job on removing the constraints, preventing
>>     multiple parallel container support, from the API. One missing
>>     piece seems to be CDIProvider.isInitialized(). The JavaDoc says:
>>     " Determines whether or not this CDIProvider has been initialized
>>     or not"
>>
>>     My understanding is that it is supposed to indicate whether a CDI
>>     object is in initialized state yet or whether it has been shut
>>     down. If my understanding is correct then this method should
>>     probably be moved to the CDI class instead. Due to the possible
>>     1-to-n mapping between CDI and CDIProvider it's not correct to
>>     have this method on CDIProvider
>>
>>     Jozef
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150528/0248f5a7/attachment-0001.html 

From issues at jboss.org  Thu May 28 15:25:02 2015
From: issues at jboss.org (Joseph Snyder (JIRA))
Date: Thu, 28 May 2015 15:25:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-531) CDI JavaDocs link to Extension
 Architecture broken
In-Reply-To: <JIRA.12573211.1432841067000@Atlassian.JIRA>
References: <JIRA.12573211.1432841067000@Atlassian.JIRA>
	<JIRA.12573211.1432841067662@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573211.1432841067000.8047.1432841102111@Atlassian.JIRA>

Joseph Snyder created CDI-531:
---------------------------------

             Summary: CDI JavaDocs link to Extension Architecture broken
                 Key: CDI-531
                 URL: https://issues.jboss.org/browse/CDI-531
             Project: CDI Specification Issues
          Issue Type: Bug
            Reporter: Joseph Snyder


It appears that the Java SE team have moved their "Extension Architecture" documentation. This invalidates the link in the CDI JavaDocs we publish as follows:
In the file:
cdi-api-1.2-sources\javax\enterprise\inject\Vetoed.java
Is a link in the meta data for JavaDoc:
<a href="http://download.java.net/jdk8/docs/technotes/guides/extensions/spec.html#sealing">
Which returns <404>, file not found.

I suspect this is now moved to:
https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html

But I can't be sure because there's no Anchor titled "sealing" in that moved document.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri May 29 05:46:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 29 May 2015 05:46:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-521) Create a Prioritized Interface for
 SPI element that have a priority
In-Reply-To: <JIRA.12570182.1430299501000@Atlassian.JIRA>
References: <JIRA.12570182.1430299501000@Atlassian.JIRA>
	<JIRA.12570182.1430299501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12570182.1430299501000.8937.1432892762145@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-521:
-------------------------------------
    Fix Version/s: 2.0-EDR1
                       (was: 2.0 (discussion))


> Create a Prioritized Interface for SPI element that have a priority 
> --------------------------------------------------------------------
>
>                 Key: CDI-521
>                 URL: https://issues.jboss.org/browse/CDI-521
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Concepts
>    Affects Versions: 1.2.Final
>            Reporter: Antoine Sabot-Durand
>             Fix For: 2.0-EDR1
>
>
> With the addition of ordering in Observer (CDI-4), we have a collection of element in SPI that could benefit having a {{getPriority()}} method:
> * {{ObserverMethod}}
> * {{Bean}} to be able to read alternative priority and give priority for {{Decorator}} and {{Interceptor}}
> Any other place?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri May 29 05:49:04 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 29 May 2015 05:49:04 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-4) Need a way to provide ordering for
 Event observers
In-Reply-To: <JIRA.12415300.1280185626000@Atlassian.JIRA>
References: <JIRA.12415300.1280185626000@Atlassian.JIRA>
	<JIRA.12415300.1280185626000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12415300.1280185626000.8966.1432892944324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antoine Sabot-Durand updated CDI-4:
-----------------------------------
    Fix Version/s: 2.0-EDR1
                       (was: 2.0 (discussion))


> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
>                 Key: CDI-4
>                 URL: https://issues.jboss.org/browse/CDI-4
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Events, Portable Extensions
>    Affects Versions: 1.0
>         Environment: All
>            Reporter: Lincoln Baxter III
>            Assignee: Antoine Sabot-Durand
>             Fix For: 2.0-EDR1
>
>
> There needs to be a way to specify some kind of ordering for Event observers. 
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From issues at jboss.org  Fri May 29 12:25:02 2015
From: issues at jboss.org (Antoine Sabot-Durand (JIRA))
Date: Fri, 29 May 2015 12:25:02 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-532) Support multiple container in Java
	SE
In-Reply-To: <JIRA.12573324.1432916671000@Atlassian.JIRA>
References: <JIRA.12573324.1432916671000@Atlassian.JIRA>
	<JIRA.12573324.1432916671132@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12573324.1432916671000.10946.1432916702083@Atlassian.JIRA>

Antoine Sabot-Durand created CDI-532:
----------------------------------------

             Summary: Support multiple container in Java SE
                 Key: CDI-532
                 URL: https://issues.jboss.org/browse/CDI-532
             Project: CDI Specification Issues
          Issue Type: Feature Request
          Components: Java SE Integration
    Affects Versions: 1.2.Final
            Reporter: Antoine Sabot-Durand


We should propose a solution to support multiple container in Java SE.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

From rahul.dev.83 at gmail.com  Wed May 20 14:16:58 2015
From: rahul.dev.83 at gmail.com (Dev)
Date: Wed, 20 May 2015 18:16:58 -0000
Subject: [cdi-dev] Deploy failing due to WELD-000071: Managed bean class
 org.apache.cxf.jaxrs.provider.DataBindingJSONProvider must be @Dependent
Message-ID: <1432145817057-5711473.post@n5.nabble.com>

It seems it is failing as i am using an external jar file in which
javax.Inject is used. 
When my war is deployed with this jar file it fails.

I tried to exclude the packages in jar file by declaring them in
WEB-INF/beans.xml i.e.
<?xml version="1.0" encoding="UTF-8"?>

<beans bean-discovery-mode="all" version="1.1"
 xmlns="http://xmlns.jcp.org/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="        
http://xmlns.jcp.org/xml/ns/javaee        
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd">
 
 <scan>
  <exclude name="com.xyz.*"/>
  <exclude name="com.shipment.**"/>
 </scan>
</beans>

CDI version is 1.2
Server is WILDFLY 8.2.0


Error that i am getting :
###############

Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071:
Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider
must be @Dependent
        at org.jboss.weld.bean.ManagedBean.checkType(ManagedBean.java:198)
        at
org.jboss.weld.bean.AbstractBean.initializeAfterBeanDiscovery(AbstractBean.java:105)
        at
org.jboss.weld.bean.ManagedBean.initializeAfterBeanDiscovery(ManagedBean.java:113)
        at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
        at
org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
        at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
        at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_25]
        ... 3 more

23:23:19,370 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address:
([("deployment" => "CaseManagementSystem.war")]) - failure description:
{"JBAS014671: Failed services" =>
{"jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"CaseManagementSystem.war\".WeldStartService: Failed
to start service
    Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000071:
Managed bean class org.apache.cxf.jaxrs.provider.DataBindingJSONProvider
must be @Dependent"}}
23:23:19,437 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 31)
JBAS018559: Deployed "CaseManagementSystem.war" (runtime-name :
"CaseManagementSystem.war")
23:23:19,466 INFO  [org.jboss.as.controller] (Controller Boot Thread)
JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service
jboss.deployment.unit."CaseManagementSystem.war".WeldStartService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."CaseManagementSystem.war".WeldStartService: Failed to
start service

23:23:19,822 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service
thread 1-3) JBAS010418: Stopped Driver service with driver-name =
CaseManagementSystem.war_com.mysql.jdbc.Driver_5_1
23:23:19,832 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 6)
JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service
'CaseManagementSystem.war#hsn18cms'
23:23:19,842 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 17)
JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service
'CaseManagementSystem.war#hsn18cmsaspect'
23:23:19,842 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service
thread 1-4) JBAS010418: Stopped Driver service with driver-name =
CaseManagementSystem.war_org.h2.Driver_1_4
23:23:19,852 INFO  [org.jboss.weld.deployer] (MSC service thread 1-7)
JBAS016009: Stopping weld service for deployment CaseManagementSystem.war
23:23:19,972 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 17)
JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service
'CaseManagementSystem.war#hsn18cmsaspect'
23:23:19,972 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 6)
JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service
'CaseManagementSystem.war#hsn18cms'
23:23:21,872 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8)
JBAS015877: Stopped deployment CaseManagementSystem.war (runtime-name:
CaseManagementSystem.war) in 2076ms
23:23:21,872 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http
management interface listening on http://127.0.0.1:9990/management
23:23:21,872 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin
console listening on http://127.0.0.1:9990
23:23:21,872 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874:
WildFly 8.2.0.Final "Tweek" started in 134751ms - Started 241 of 290
services (95 services are lazy, passive or on-demand)
23:23:22,152 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2)
JBAS018558: Undeployed "CaseManagementSystem.war" (runtime-name:
"CaseManagementSystem.war")
23:23:22,162 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2)
JBAS014774: Service status report

######################

Kindly help and let me know how i can exclude the jar files in CDI.

Thanks,
Dev




--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/Deploy-failing-due-to-WELD-000071-Managed-bean-class-org-apache-cxf-jaxrs-provider-DataBindingJSONPrt-tp5711473.html
Sent from the CDI Development mailing list mailing list archive at Nabble.com.