cdi-dev September 2011

cdi-dev@lists.jboss.org

14 participants
154 discussions

[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet commented on CDI-87: ------------------------------------- I've extracted "a beans.xml file should explicitly define its beans.xml dependencies" into a separate issue CDI-150, because it's probably a different issue then this: Even with CDI-150 fixed, you'd still need to be able to exclude specific beans from any of the dependent beans.xml files, but you 'd just need it a lot less and the problems described above would be already solved. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (CDI-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet edited comment on CDI-87 at 9/5/11 7:59 AM: ------------------------------------------------------------- CDI is opt-out by default, which breaks transitive reuse of CDI jars. Presume this reuse scenario: seam-solder has solderBeans.xml seam-security depends on seam-solder and has securityBeans.xml guvnor depends on seam-security (but not directly on seam-solder) and has guvnorBeans.xml. Transitively, seam-solder appears in the classpath. So when guvnorBeans.xml does: <weld:scan><weld:include>securityBeans.xml</weld:include></weld:scan> it fails, because solderBeans.xml isn't activated, because securityBeans.xml doesn't define it's dependent beans.xml explicitly. The hack of specifying to include solderBeans.xml in guvnorBeans.xml, is bad: - guvnor doesn't want to know about solder. It's transitive: let seam-security take the heat for it. - the next version of seam-security might no longer use solderBeans.xml (or instead need extra Beans.xml) => upgrading becomes hard Possible solution: a beans.xml file should explicitly define its beans.xml dependencies. was (Author: ge0ffrey): CDI remains is opt-out by default, which breaks transitive reuse of CDI jars. Presume this reuse scenario: seam-solder has solderBeans.xml seam-security depends on seam-solder and has securityBeans.xml guvnor depends on seam-security (but not directly on seam-solder) and has guvnorBeans.xml. Transitively, seam-solder appears in the classpath. So when guvnorBeans.xml does: <weld:scan><weld:include>securityBeans.xml</weld:include></weld:scan> it fails, because solderBeans.xml isn't activated, because securityBeans.xml doesn't define it's dependent beans.xml explicitly. The hack of specifying to include solderBeans.xml in guvnorBeans.xml, is bad: - guvnor doesn't want to know about solder. It's transitive: let seam-security take the heat for it. - the next version of seam-security might no longer use solderBeans.xml (or instead need extra Beans.xml) => upgrading becomes hard Possible solution: a beans.xml file should explicitly define its beans.xml dependencies. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet commented on CDI-87: ------------------------------------- CDI remains is opt-out by default, which breaks transitive reuse of CDI jars. Presume this reuse scenario: seam-solder has solderBeans.xml seam-security depends on seam-solder and has securityBeans.xml guvnor depends on seam-security (but not directly on seam-solder) and has guvnorBeans.xml. Transitively, seam-solder appears in the classpath. So when guvnorBeans.xml does: <weld:scan><weld:include>securityBeans.xml</weld:include></weld:scan> it fails, because solderBeans.xml isn't activated, because securityBeans.xml doesn't define it's dependent beans.xml explicitly. The hack of specifying to include solderBeans.xml in guvnorBeans.xml, is bad: - guvnor doesn't want to know about solder. It's transitive: let seam-security take the heat for it. - the next version of seam-security might no longer use solderBeans.xml (or instead need extra Beans.xml) => upgrading becomes hard Possible solution: a beans.xml file should explicitly define its beans.xml dependencies. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ] Geoffrey De Smet commented on CDI-87: ------------------------------------- Presume this embedding scenario: Project A does not use weld or CDI directly. It depends on B and C. Project B has CDI and weld use as optional: it does not use weld by default, but includes a beans.xml in it's classpath in case you want to take advantage of that Project C uses CDI and weld. It doesn't depend on B. It knows nothing of B (so it wouldn't presume excluding it). It has no intention of being any influence on anything B related. Result: Because C fires up weld, which as a side-effect fires up the beans.xml of B. That shouldn't happen. > Declarative control over classes including in bean archive scanning > ------------------------------------------------------------------- > > Key: CDI-87 > URL: https://issues.jboss.org/browse/CDI-87 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Weld introduced a XML syntax for this -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

← Newer
1
...
13
14
15
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2011