November 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Vinicius Carvalho (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Vinicius Carvalho commented on CDI-50: -------------------------------------- Having something like @Optional would be great. We have a scenario where we package our apps in modules, but generally there's a jar with the API and all interfaces. So for example, we have a CacheService interface that will be shipped with all apps, it does not mean all apps will have an implementation (through an extension) of that (say ehcache,infinispan,gemfire). So imagine now we have another service: public class MyService { @Inject @Optional CacheService cache; private Map noCachefallback; } so now, if the caching service is not available I could fallback to the local hashmap for instance. To overcome that I'm accessing BeanManager directly and querying for the service, checking if it's present or not. But I found a problem when I need to use the bean during initialization. Any chances we can see this @Optinal (maybe at Solder) one day? Regards > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-99: ---------------------------------- while chatting with jozef and ales, we had the following idea: What about just allowing to inject Extensions at bootup (as we already do with BeanManager)? public doThaTrick(@Observes BeforeBeanDiscovery bbd, MyOtherExtension otherExtension) {...}; or even: public doThaTrick(@Observes BeforeBeanDiscovery bbd, Instance<Extension> allExtensions) {...}; We would need to clarify 6.7.3 that Extensions, BeanManager, Event, ...(what else being @ApplicationScoped and available at bootup?) must be available for injection into SystemEvent methods. > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-99: ---------------------------------- Don't we fear about security issues? Giving an end-user access to all runtime Extensions might be a bit too much... > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-185) BeanAttributes - incompatible changes in the API

by Jozef Hartinger (Created) (JIRA)

BeanAttributes - incompatible changes in the API ------------------------------------------------ Key: CDI-185 URL: https://issues.jboss.org/browse/CDI-185 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Environment: CDI API 1.1.EDR1 Reporter: Jozef Hartinger Priority: Blocker Fix For: 1.1 (Proposed) The CDI SPI is not backwards-compatible after CDI-96. For example: * InjectionPoint.getBean() now returns BeanAttributes instead of Bean * AfterBeanDiscovery.addBean() now accepts BeanAttributes instead of Bean The spec, Javadoc for the given methods as well as the fact that these changes cause backward incompatibility indicate that they are a result of accidental batch modification and not intentional. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
4
0 / 0

[JBoss JIRA] Created: (CDI-114) Allow registration of beans at runtime

by Vincent Massol (JIRA)

Allow registration of beans at runtime -------------------------------------- Key: CDI-114 URL: https://issues.jboss.org/browse/CDI-114 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 1.0 Reporter: Vincent Massol I have use cases where I need to register a bean dynamically at runtime (see the forum reference link for a detailed description of the use case). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

8
13
0 / 0

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Jozef Hartinger (Updated) (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger updated CDI-99: ------------------------------- Fix Version/s: 1.1.EDR2 (was: 1.1.EDR1) Forum Reference: http://www.seamframework.org/Weld/PortableExtensionWishlist#H-ObtainTtExt... (was: http://www.seamframework.org/Weld/PortableExtensionWishlist#H-ObtainTtExt...) > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-99) Obtain Extension instances from BeanManager

by Jozef Hartinger (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-99?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-99: -------------------------------- The spec covers what happens if there is no instance for a given class but the result may as well be ambiguous. Should we specify what happens in that case? > Obtain Extension instances from BeanManager > ------------------------------------------- > > Key: CDI-99 > URL: https://issues.jboss.org/browse/CDI-99 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Ales Justin (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Ales Justin commented on CDI-18: -------------------------------- >> Although, I could see how enabling ext alternative would be useful globally -- e.g. testing, where you add mocks. > Yes, but this isn't what the spec says. Big thing to fix for 1.1 somehow. >> Otoh, this might lead to some nasty surprises in original bean archive ... >> ... but then again, @Specializes does exactly that, hence, imo, both things should work the same. Perhaps @Alternative could have scope? * @Alternative(AlternativeScope.LOCAL) or @Alternative(AlternativeScope.GLOBAL) (same with interceptors and decorators) > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml. > Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Pete Muir (Updated) (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-50: ------------------------- Fix Version/s: 1.1.EDR2 (was: 1.1.EDR1) Git Pull Request: https://github.com/jboss/cdi/pull/52 (was: https://github.com/jboss/cdi/pull/52) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2009-December/002029.html (was: http://lists.jboss.org/pipermail/weld-dev/2009-December/002029.html) Oops! > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR2 > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Pete Muir (Updated) (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-83: ------------------------- Fix Version/s: 1.1.EDR2 (was: 1.1.EDR1) Forum Reference: http://lists.jboss.org/pipermail/weld-dev/2010-May/002499.html (was: http://lists.jboss.org/pipermail/weld-dev/2010-May/002499.html) This won't work as is, because we have multiple annotated types per class. Maybe better to make this return the vanilla annotated type, and introduce a new method to get all of the actual annotated types such as Collection<AnnotatedType> getAnnotatedType(Class c); > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1.EDR2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2011