[JBoss JIRA] Created: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
8:19 p.m.
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
11:56 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Dan Allen commented on CDI-113:
-------------------------------
I don't think that Weld loads any beans from jars which don't have beans.xml. Any
built-in bean that Weld provides is clearly documented in the CDI specification. Examples
include BeanManager, UserTransaction and a few others (security principle, validation
factory). Some may depend on the runtime environment (such as when Weld runs in a Servlet
environment). However, these cases are well specified.
It's accurate to say that extensions can load beans from jars which don't have
beans.xml. The most basic example is using the BeforeBeanDiscovery#addAnnotatedType() in
an extension method that observes this event. It's those cases when metadata is
probably useful. Granted, this would have been possible had the XML configuration schema
been approved. So perhaps the right approach is to pursue that request.
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
12:56 a.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Alexey Kazakov commented on CDI-113:
------------------------------------
> However, these cases are well specified.
They are well
specified for runtime but not for tools.
How should tools recognize BeanManager implementations? What if there are a few classes
that implement this interface? Only particular CDI container knows what to load to provide
spec required services.
And one more problem. CDI container don't have to look in jars without beans.xml at
all. So no beans.xml no any need to scan such jars. But for tools it's not the case.
Tools have to look in all the jars in class path if they want to find all BeanManager
implementations. Otherwise they need to know all the available CDI-implementations to work
around this problem using hard-coded names/paths.
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
1:08 a.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Dan Allen commented on CDI-113:
-------------------------------
I may have lost you, but why are we talking about multiple BeanManager implementations?
There is only one BeanManager implementation, and that's the one provided by the
runtime environment (JBoss AS). If you see @Inject BeanManager, you just have to assume
that it's a valid injection point based on the rules of CDI. This is a much different
case than injecting an application-defined bean.
If I'm not understanding your concern, please let me know.
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
1:41 a.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Alexey Kazakov commented on CDI-113:
------------------------------------
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):
public class MyNotUsedBeanManagerImplimentation implements BeanManager {
...
}
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?
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.
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 :(
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
2:34 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-113:
-------------------------------
bq. I don't think that Weld loads any beans from jars which don't have beans.xml.
Any built-in bean that Weld provides is clearly documented in the CDI specification.
Examples include BeanManager, UserTransaction and a few others (security principle,
validation factory). Some may depend on the runtime environment (such as when Weld runs in
a Servlet environment). However, these cases are well specified.
This isn't 100% accurate, Weld also provides some built in beans that are Weld
specific, currently this is only the Context control beans.
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
2:38 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-113:
-------------------------------
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
2:38 p.m.
New subject: [JBoss JIRA] Issue Comment Edited: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
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
6:08 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Alexey Kazakov commented on CDI-113:
------------------------------------
bq. Alexey, can you give example of why tools needs to know this - how would it represent
this info to the user?
@Inject BeanManager manager;
JBoss Tools used to complain that no bean is eligible for "@Inject BeanManager
manager;" until we hardcoded BeanManagerImpl (for Weld) as a special bean.
bq. I don't understand this problem, why do you need to do this?
How we can find actual bean classes without scanning the entire class path? So far we just
hardcoded weld-*.jars name template and scan such jars along with jars which contain
beans.xml.
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
6:10 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Alexey Kazakov commented on CDI-113:
------------------------------------
There are some JBT related issues in jira: JBIDE-8017 JBIDE-8019
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
1:01 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-113:
-------------------------------
{quote}
{quote}Alexey, can you give example of why tools needs to know this - how would it
represent this info to the user?{quote}
@Inject BeanManager manager;
JBoss Tools used to complain that no bean is eligible for "@Inject BeanManager
manager;" until we hardcoded BeanManagerImpl (for Weld) as a special bean.
{quote}
I don't think you should be making BeanManagerImpl available for injection, just
BeanManager (which all impls *must* provide). So hardcode BeanManager, not
BeanManagerImpl.
{quote}{quote}I don't understand this problem, why do you need to do this?{quote}
How we can find actual bean classes without scanning the entire class path? So far we just
hardcoded weld-*.jars name template and scan such jars along with jars which contain
beans.xml.{quote}
Why do you need to find actual bean classes? All that you should be making available is
the interfaces provided by the spec.
I think we need to talk about this offline as there is clearly a misunderstanding here,
which I think may stem from the way we did things in Seam 2.
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
1:03 p.m.
New subject: [JBoss JIRA] Updated: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-113:
--------------------------
Fix Version/s: TBD
Affects Version/s: 1.0
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
Affects Versions: 1.0
Reporter: Alexey Kazakov
Fix For: TBD
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
6:57 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Alexey Kazakov commented on CDI-113:
------------------------------------
Ok. If it is not interesting to look at particular implementation of built-in beans at all
and having navigation to the interfaces only is enough then JBT doesn't need any
additional metadata. Actually JBT already works in this way - JBIDE-8697.
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
Affects Versions: 1.0
Reporter: Alexey Kazakov
Fix For: TBD
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
7:01 p.m.
New subject: [JBoss JIRA] Commented: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir commented on CDI-113:
-------------------------------
I would say it's actively wrong to have the tool look at the impl of a built in bean,
or to navigate to them. Part of the goal of a specification is to encourage people to
write portable code, encouraging them to look at implementations is not a good way 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
Affects Versions: 1.0
Reporter: Alexey Kazakov
Fix For: TBD
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
7:03 p.m.
New subject: [JBoss JIRA] Closed: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
[
https://issues.jboss.org/browse/CDI-113?page=com.atlassian.jira.plugin.sy...
]
Pete Muir closed CDI-113.
-------------------------
Fix Version/s: (was: TBD)
Resolution: Won't Fix
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
Affects Versions: 1.0
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
4755
days inactive
4784
days old
14 comments
3 participants
participants (3)
-
Alexey Kazakov (JIRA) -
Dan Allen (JIRA)
-
Pete Muir (JIRA)