[cdi-dev] [JBoss JIRA] Issue Comment Edited: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.

[Pete Muir (JIRA)]

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

Pete Muir edited comment on CDI-113 at 3/30/11 8:38 AM:
--------------------------------------------------------

bq. Nothing limits CDI container to have a few implementation in class path but use the only one (at least at once).
bq. For runtime it's not a problem. You know that you must provide a BeanManager and you provide it. But what if the developer added the following class in the classpath (I don't know why he might do it):

bq. public class MyNotUsedBeanManagerImplimentation implements BeanManager { ... }

bq. Runtime still works since this dead code is not used by CDI container but how tools can know that there is some difference between those BeanManager implementations?

bq. Agree that may be this example is too tricky. And for 99.9% there will be the only implementation for every required service. But I just wanted to show that what is obvious for runtime is not so for design time.

Alexey, can you give example of why tools needs to know this - how would it represent this info to the user?

bq. Second problem may be more important. Even if we know for sure that there is the only one BeanManager implementation, the only one UserTransaction implementation, etc. we should scan every jar in the class path since we don't have any marker like beans.xml to skip not-CDI jars. It may be too long 

I don't understand this problem, why do you need to do this?

      was (Author: petemuir):
    bq. Nothing limits CDI container to have a few implementation in class path but use the only one (at least at once).
For runtime it's not a problem. You know that you must provide a BeanManager and you provide it. But what if the developer added the following class in the classpath (I don't know why he might do it):

bq. public class MyNotUsedBeanManagerImplimentation implements BeanManager { ... }

bq. Runtime still works since this dead code is not used by CDI container but how tools can know that there is some difference between those BeanManager implementations?

bq. Agree that may be this example is too tricky. And for 99.9% there will be the only implementation for every required service. But I just wanted to show that what is obvious for runtime is not so for design time.

Alexey, can you give example of why tools needs to know this - how would it represent this info to the user?

bq. Second problem may be more important. Even if we know for sure that there is the only one BeanManager implementation, the only one UserTransaction implementation, etc. we should scan every jar in the class path since we don't have any marker like beans.xml to skip not-CDI jars. It may be too long 

I don't understand this problem, why do you need to do this?
  
> Add some design time readable metadata for built-in beans of CDI-implementations.
> ---------------------------------------------------------------------------------
>
>                 Key: CDI-113
>                 URL: https://issues.jboss.org/browse/CDI-113
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Alexey Kazakov
>
> We need such metadata for tooling.
> It would be very helpful to have some metadata for beans which implement spec required services (BeanManager, ...)
> Or for any other beans which CDI implementations register programmatically and which should be available for users.
> For example Weld loads some beans from jars which don't have beans.xml but some of those beans are available for injections.
> So far we don't have any documented way to recognize such beans.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira