From issues at jboss.org Mon Jan 14 16:41:00 2019 From: issues at jboss.org (Harald Wellmann (Jira)) Date: Mon, 14 Jan 2019 16:41:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-741) Clarify: "archive which contains an extension" In-Reply-To: References: Message-ID: Harald Wellmann created CDI-741: ----------------------------------- Summary: Clarify: "archive which contains an extension" Key: CDI-741 URL: https://issues.jboss.org/browse/CDI-741 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 2.0 .Final Reporter: Harald Wellmann According to Section 12.1, {quote}An archive which contains an extension and no beans.xml file is not a bean archive. {quote} According to Section 11.5, {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services {quote} Conclusion: An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an `Extension` class, regardless of the service registration. Side note: It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Mon Jan 14 16:42:02 2019 From: issues at jboss.org (Harald Wellmann (Jira)) Date: Mon, 14 Jan 2019 16:42:02 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-741) Clarify: "archive which contains an extension" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Wellmann updated CDI-741: -------------------------------- Description: According to Section 12.1, {quote}An archive which contains an extension and no beans.xml file is not a bean archive. {quote} According to Section 11.5, {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services {quote} Conclusion: An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an {{Extension}} class, regardless of the service registration. Side note: It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. was: According to Section 12.1, {quote}An archive which contains an extension and no beans.xml file is not a bean archive. {quote} According to Section 11.5, {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services {quote} Conclusion: An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an `Extension` class, regardless of the service registration. Side note: It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. > Clarify: "archive which contains an extension" > ---------------------------------------------- > > Key: CDI-741 > URL: https://issues.jboss.org/browse/CDI-741 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Harald Wellmann > Priority: Major > > According to Section 12.1, > {quote}An archive which contains an extension and no beans.xml file is not a bean archive. > {quote} > According to Section 11.5, > {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services > {quote} > Conclusion: > An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. > So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. > The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. > If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an {{Extension}} class, regardless of the service registration. > Side note: > It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. -- This message was sent by Atlassian Jira (v7.12.1#712002) From werner.keil at gmail.com Wed Jan 16 10:04:33 2019 From: werner.keil at gmail.com (Werner Keil) Date: Wed, 16 Jan 2019 16:04:33 +0100 Subject: [cdi-dev] Jakarta EE CDI? In-Reply-To: References: Message-ID: Hi, I saw there's a jakarta.enterprise update of CDI2. It seems, that CDI therefore also left the JCP and decided to work under the Jakarta EE umbrella, but to what extent? Another IBM led Java EE JSR, Batch was recently moved to EE4J. Any plans for CDI in the near future? Thanks, Werner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20190116/5d152c87/attachment.html From issues at jboss.org Wed Jan 16 10:51:28 2019 From: issues at jboss.org (Matej Novotny (Jira)) Date: Wed, 16 Jan 2019 10:51:28 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-741) Clarify: "archive which contains an extension" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13683083#comment-13683083 ] Matej Novotny commented on CDI-741: ----------------------------------- That's a bit of a corner case and i would say TCK might not have it on purpose as implementations (or even just integrators) might differ on how they handle this. I am not defending or deferring either way here but... * The sole sentence in Section 12.1 doesn't really say anything about having extension registered. * Also note that in most EE containers, you will have discovered the extension even without using ServiceLoader mechanics (in WFLY you could simply leverage Jandex for this). So the registration might not be required to decline that archive as bean archive. * Just out of curiosity, what's the use case for an actual archive to have an extension that isn't registered? > Clarify: "archive which contains an extension" > ---------------------------------------------- > > Key: CDI-741 > URL: https://issues.jboss.org/browse/CDI-741 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Harald Wellmann > Priority: Major > > According to Section 12.1, > {quote}An archive which contains an extension and no beans.xml file is not a bean archive. > {quote} > According to Section 11.5, > {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services > {quote} > Conclusion: > An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. > So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. > The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. > If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an {{Extension}} class, regardless of the service registration. > Side note: > It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. -- This message was sent by Atlassian Jira (v7.12.1#712002) From issues at jboss.org Sat Jan 19 11:37:00 2019 From: issues at jboss.org (Harald Wellmann (Jira)) Date: Sat, 19 Jan 2019 11:37:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-741) Clarify: "archive which contains an extension" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684420#comment-13684420 ] Harald Wellmann commented on CDI-741: ------------------------------------- Oh, it's not exactly a use case, but I was working on a CDI library, I copied a Java package from a third-party library to my project, and then was surprised to see that the beans from my own library were no longer being discovered. It turned out that the package contained an {{Extension}} class, which I had copied, without the {{META-INF/services}} registration. > Clarify: "archive which contains an extension" > ---------------------------------------------- > > Key: CDI-741 > URL: https://issues.jboss.org/browse/CDI-741 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Harald Wellmann > Priority: Major > > According to Section 12.1, > {quote}An archive which contains an extension and no beans.xml file is not a bean archive. > {quote} > According to Section 11.5, > {quote} An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services > {quote} > Conclusion: > An archive containing a class implementing {{javax.enterprise.inject.spi.Extension}} but not declaring this class in {{META-INF/services}} does not contain an extension. > So if this archive contains a class with a bean-defining annotation and no {{beans.xml}}, then it is a bean archive. > The TCK is missing a test for this scenario (archive with extension class but no service registration), it only has a test for the more obvious case of an archive with extension class *and* service registration. > If my interpretation is correct, then WildFly 15 has a bug, since it disqualifies any archive containing an {{Extension}} class, regardless of the service registration. > Side note: > It would be helpful for readers looking for the exact definition of extensions to move the sentence quoted above from Section 11.5 to the introductory paragraph of Section 11. -- This message was sent by Atlassian Jira (v7.12.1#712002)