September 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-402) Clarify ProcessAnnotatedType for implicit bean archives

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-402?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger edited comment on CDI-402 at 9/17/13 6:31 AM: -------------------------------------------------------------- No, PAT is not necessarily fired for all classes in an implicit bean archive - only for those discovered which is defined as: {quote} First the container must discover types. The container discovers: • each Java class, interface or enum deployed in an explicit bean archive, and • each Java class with a bean defining annotation in an implicit bean archive. • each session bean that is not excluded from discovery. Then, for every type discovered the container must create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, as defined in Section 11.5.6. {quote} was (Author: jharting): No, PAT is not fired for all classes in an implicit bean archive - only those discovered which is defined as: {quote} First the container must discover types. The container discovers: • each Java class, interface or enum deployed in an explicit bean archive, and • each Java class with a bean defining annotation in an implicit bean archive. • each session bean that is not excluded from discovery. Then, for every type discovered the container must create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, as defined in Section 11.5.6. {quote} > Clarify ProcessAnnotatedType for implicit bean archives > ------------------------------------------------------- > > Key: CDI-402 > URL: https://issues.jboss.org/browse/CDI-402 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > > There is a sentence in the spec which might be heavy to implement correctly in a non-expensive way: "An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation, or one or more session beans." > This means that we _first_ need to scan all classes whether one of them has a scope, and then do it all over again and fire ProcessAnnotatedType events for all of them if we find one? > And to go one step further: is the assumption correct that we must not fire any PAT if no class with a scope has been found in that ClassPath entry? > This might be pretty expensive to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-402) Clarify ProcessAnnotatedType for implicit bean archives

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-402?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-402: ------------------------------------- No, PAT is not fired for all classes in an implicit bean archive - only those discovered which is defined as: {quote} First the container must discover types. The container discovers: • each Java class, interface or enum deployed in an explicit bean archive, and • each Java class with a bean defining annotation in an implicit bean archive. • each session bean that is not excluded from discovery. Then, for every type discovered the container must create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType, as defined in Section 11.5.6. {quote} > Clarify ProcessAnnotatedType for implicit bean archives > ------------------------------------------------------- > > Key: CDI-402 > URL: https://issues.jboss.org/browse/CDI-402 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Mark Struberg > > There is a sentence in the spec which might be heavy to implement correctly in a non-expensive way: "An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation, or one or more session beans." > This means that we _first_ need to scan all classes whether one of them has a scope, and then do it all over again and fire ProcessAnnotatedType events for all of them if we find one? > And to go one step further: is the assumption correct that we must not fire any PAT if no class with a scope has been found in that ClassPath entry? > This might be pretty expensive to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-402) Clarify ProcessAnnotatedType for implicit bean archives

by Mark Struberg (JIRA)

Mark Struberg created CDI-402: --------------------------------- Summary: Clarify ProcessAnnotatedType for implicit bean archives Key: CDI-402 URL: https://issues.jboss.org/browse/CDI-402 Project: CDI Specification Issues Issue Type: Bug Reporter: Mark Struberg There is a sentence in the spec which might be heavy to implement correctly in a non-expensive way: "An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation, or one or more session beans." This means that we _first_ need to scan all classes whether one of them has a scope, and then do it all over again and fire ProcessAnnotatedType events for all of them if we find one? And to go one step further: is the assumption correct that we must not fire any PAT if no class with a scope has been found in that ClassPath entry? This might be pretty expensive to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-377: ----------------------------------- and to be even more specific: 2.5 defines 'Any scope type is a bean defining annotation'. This means also JSR-330 @Scopes will trigger this. The other part which might cause this issue is the Extension scanning. Because in CDI-1.1 this will not only get fired for all those beans with bean defining annotation but for all classes in all JARs, right? It would have been helpful if Weld would catch those ClassNotFound and NoClassFoundDef stuff and log the Bean which currently gets processed. That way we would have better info about what really happens. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI, guava, guice > Fix For: 1.1.PFD > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-377: ------------------------------------- Just to make this more accurate it's not @Inject itself that causes problems but rather @Inject on a class with explicit scope definition. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI, guava, guice > Fix For: 1.1.PFD > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-377 at 9/17/13 4:14 AM: ------------------------------------------------------------ I think there are actually 2 parts in the game which are both kind of broken: a.) CDI should not pickup any @Inject from everywhere. This breaks all kind of projects which use other JSR-330 containers like Spring, guice, etc. b.) maven-3.1 now exposes internal plugins via JSR-330 annotations (and the atinject API as well). That will not only break CDI containers but actually _all_ other projects which contain any JSR-330 code as well. We should have remained with our highly proprietary plexus injection container instead of leaking standard JSR-330 stuff into projects. Discussing over in Maven how to deal with it. was (Author: struberg): I think there are actually 2 parts in the game which are both kind of broken: a.) CDI should not pickup any @Inject from anywhere. This breaks all kind of projects which use other JSR-330 containers like Spring, guice, etc. b.) maven-3.1 now exposes internal plugins via JSR-330 annotations (and the atinject API as well). That will not only break CDI containers but actually _all_ other projects which contain any JSR-330 code as well. We should have remained with our highly proprietary plexus injection container. Discussing over in Maven how to deal with it. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI, guava, guice > Fix For: 1.1.PFD > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-377: ----------------------------------- I think there are actually 2 parts in the game which are both kind of broken: a.) CDI should not pickup any @Inject from anywhere. This breaks all kind of projects which use other JSR-330 containers like Spring, guice, etc. b.) maven-3.1 now exposes internal plugins via JSR-330 annotations (and the atinject API as well). That will not only break CDI containers but actually _all_ other projects which contain any JSR-330 code as well. We should have remained with our highly proprietary plexus injection container. Discussing over in Maven how to deal with it. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI, guava, guice > Fix For: 1.1.PFD > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-401) Clarify the meaning of "bean class local view"

by Martin Kouba (JIRA)

Martin Kouba created CDI-401: -------------------------------- Summary: Clarify the meaning of "bean class local view" Key: CDI-401 URL: https://issues.jboss.org/browse/CDI-401 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba 3.2.2 Bean types of a session bean: {quote} The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a *bean class local view*, the unrestricted set of bean types contains the bean class and all superclasses. ... {quote} AFAIK the EJB spec does not define anything like "bean class local view". I believe the CDI spec is referencing *No-Interface View* here (a variation of the local view that exposes the non-static public methods of the bean class without the use of a separate business interface). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

JavaOne CDI 2.0 BOF

by Andrew Lee Rubinger

Hello, Expert Group (and community members): As our fearless Specification Lead, Pete Muir, is unable to join us at JavaOne this year, I've taken the liberty of blocking off a Birds of a Feather (BOF) session for us to sync with the community, answer questions, and address general concerns. I'd like to invite all EG members to sit on the panel; in turn I'll be happy to draw up a rough agenda with Pete outlining topics to cover and will generally moderate what I hope will be an engaging, free-form (with some direction) discussion. If you're able to make it, please reply to the Thread and I'll look forward to seeing you there! Session Details: http://lanyrd.com/2013/javaone/scmzbz/ Tuesday 24th September, 2013 4:30pm to 5:15pm (PST) Parc 55 - Cyril Magnin II/III S, ALR Andrew Lee Rubinger Senior Software Engineer JBoss by Red Hat @ALRubinger

11 years, 3 months

2
1
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by John Ament (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-377: -------------------------------- This is probably the same issue that occurs when running maven 3.1 using the glassfish 4 embedded plugin. It looks like CDI's assumption is that if it finds any JSR-330 annotations on the classpath, it's the runtime for them. > automatic JSR-330 annotation processing problematic > --------------------------------------------------- > > Key: CDI-377 > URL: https://issues.jboss.org/browse/CDI-377 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.PFD > Environment: glassfish-4 > Reporter: Reuben Pasquini > Labels: CDI, guava, guice > Fix For: 1.1.PFD > > > The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice. > Adding a dependency on a jar that uses guice or whatever in a javase environment > to a war deployed to a jee7 container > results in CDI processing annotated classes intended for > app-managed injection. See this ticket filed with guava for a concrete example: > https://code.google.com/p/guava-libraries/issues/detail?id=1433 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2013