7:07 p.m.
We need a general purpose way of finding a BeanManager.
+1 for me.
This way should include JNDI lookup to a fallback BeanManagerLocator that
uses a ServiceLoader
+1 for me.
I think the behavior should look like this:
- Lookup BeanManager in JNDI
- If not found, try to load BeanManagerLocator from system property.
- If not found, try to load BeanManagerLocator from ServiceLoader.
- If more than one BeanManagerLocator found, sort by priority or die if
there is more than one. (not sure about the sort, I think it should die, but
can be convinced otherwise).
- Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1.
I think the BeanManager interface is too low level.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
7:24 p.m.
I am new to the group. Where is the source code for CDI 1.1?
I can branch it, add this and solicit feedback.
I think working code is much easier to talk about than bullet points.
On Mon, Apr 25, 2011 at 4:07 PM, Rick Hightower
<richardhightower(a)gmail.com>wrote:
We need a general purpose way of finding a BeanManager.
+1 for me.
This way should include JNDI lookup to a fallback BeanManagerLocator that
uses a ServiceLoader
+1 for me.
I think the behavior should look like this:
- Lookup BeanManager in JNDI
- If not found, try to load BeanManagerLocator from system property.
- If not found, try to load BeanManagerLocator from ServiceLoader.
- If more than one BeanManagerLocator found, sort by priority or die if
there is more than one. (not sure about the sort, I think it should die, but
can be convinced otherwise).
- Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1.
I think the BeanManager interface is too low level.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
3:26 a.m.
Hi Rick,
We're all new to this group, the only person who has spent much time on CDI 1.1 so far
is me, as I collated issues from CDI 1.0. Comments inline.
On 26 Apr 2011, at 00:24, Rick Hightower wrote:
I am new to the group. Where is the source code for CDI 1.1?
The "source code" for CDI is the specification, which is in docbook format, and
available at https://github.com/pmuir/cdi - this is the 1.0 spec with a few updates that
Gavin had put in a while back. One task I still need to do is diff this spec to the 1.0
spec and see what issues he already addressed. At some point we may include a reference
API (based on the one Weld distributed for 1.0) but I'm not sure yet.
I can branch it, add this and solicit feedback.
Please do :-)
From previous experience I would suggest putting up a complete proposal on the JIRA issue
for this, which walks through any algorithms, APIs and edge cases. This can then be
discussed by the EG. I suggest doing this before diving in and editing the spec, as making
spec document changes can be a large task if you don't know it well (as your change
can impact on many sections!).
Eventually, I would suggest making changes, and then creating a github pull request where
we can use the github code review features to comb through it.
I think working code is much easier to talk about than bullet points.
I'm afraid most of the work here will be bullet points, very little (ok no) working
code ;-)
On Mon, Apr 25, 2011 at 4:07 PM, Rick Hightower <richardhightower(a)gmail.com>
wrote:
We need a general purpose way of finding a BeanManager.
+1 for me.
This way should include JNDI lookup to a fallback BeanManagerLocator that uses a
ServiceLoader
+1 for me.
I think the behavior should look like this:
Lookup BeanManager in JNDI
If not found, try to load BeanManagerLocator from system property.
If not found, try to load BeanManagerLocator from ServiceLoader.
If more than one BeanManagerLocator found, sort by priority or die if there is more than
one. (not sure about the sort, I think it should die, but can be convinced otherwise).
Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1. I think the
BeanManager interface is too low level.
--
Rick Hightower
(415) 968-9037
Profile
--
Rick Hightower
(415) 968-9037
Profile
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
3:28 a.m.
Can you add your comments to the JIRA issue, that is the best way to track such design
discussions.
On 26 Apr 2011, at 00:07, Rick Hightower wrote:
We need a general purpose way of finding a BeanManager.
+1 for me.
This way should include JNDI lookup to a fallback BeanManagerLocator that uses a
ServiceLoader
+1 for me.
I think the behavior should look like this:
Lookup BeanManager in JNDI
If not found, try to load BeanManagerLocator from system property.
If not found, try to load BeanManagerLocator from ServiceLoader.
If more than one BeanManagerLocator found, sort by priority or die if there is more than
one. (not sure about the sort, I think it should die, but can be convinced otherwise).
Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1. I think the
BeanManager interface is too low level.
This will need a new JIRA issue. I would suggest emphasising the problem when you create
the issue rather than your solution (i.e. the BM interface is too low level NOT that we
need a utility class as the first promotes discussion and ideas, the second will force
people to consider a certain approach).
3:38 a.m.
On 26 Apr 2011, at 00:07, Rick Hightower wrote:
We need a general purpose way of finding a BeanManager.
+1 for me.
I agree, this is something we can make easier for CDI 1.0. In part we need to see what the
javax.inject EG comes up with here, as we build on their foundations.
FTR this is a (possibly the?) reason CDI moved away from having a "Container"
API -- this is supposed to be addressed by JSR-330 part 2, and so was intentionally left
out of CDI 1.0 so that we didn't end up with an inconsistent approach. I need to check
with the EE spec lead on the status of the 330-part2 work.
This way should include JNDI lookup to a fallback BeanManagerLocator that uses a
ServiceLoader
+1 for me.
Regarding design for this feature, we should keep it as low footprint in terms of
specification and API class as possible, as (always) the impl can make a better decision
about how to locate the BM than we can. Rick, can you elaborate on why you want all these
additonal JNDI lookup, system property lookup, priority lookup stuff? Comments on each in
line.
I think the behavior should look like this:
Lookup BeanManager in JNDI
We should avoid requiring this. JNDI lookups are
expensive (they require synchronization) compared to straight singleton lookups (which at
least two CDI impls, Weld and OWB support today).
If not found, try to load BeanManagerLocator from system property.
What is the use case for this?
If not found, try to load BeanManagerLocator from ServiceLoader.
If more than one BeanManagerLocator found, sort by priority or die if there is more than
one. (not sure about the sort, I think it should die, but can be convinced otherwise).
Why can it not just be that a service loader is used to find the BeanManagerLocator,
and that there must not be more than one property name in use (if there is, it's an
error).
I doubt more than one CDI impl (due to scanning) can be running at the same time, and
I'm also not sure this is useful.
Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1. I think the
BeanManager interface is too low level.
--
Rick Hightower
(415) 968-9037
Profile
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
5:58 p.m.
Inline...
On Tue, Apr 26, 2011 at 12:38 AM, Peter Muir <pmuir(a)redhat.com> wrote:
On 26 Apr 2011, at 00:07, Rick Hightower wrote:
We need a general purpose way of finding a BeanManager.
+1 for me.
I agree, this is something we can make easier for CDI 1.0. In part we need
to see what the javax.inject EG comes up with here, as we build on their
foundations.
FTR this is a (possibly the?) reason CDI moved away from having a
"Container" API -- this is supposed to be addressed by JSR-330 part 2, and
so was intentionally left out of CDI 1.0 so that we didn't end up with an
inconsistent approach. I need to check with the EE spec lead on the status
of the 330-part2 work.
Ok.
This way should include JNDI lookup to a fallback BeanManagerLocator that
uses a ServiceLoader
+1 for me.
Regarding design for this feature, we should keep it as low footprint in
terms of specification and API class as possible, as (always) the impl can
make a better decision about how to locate the BM than we can. Rick, can you
elaborate on why you want all these additonal JNDI lookup, system property
lookup, priority lookup stuff? Comments on each in line.
I think the behavior should look like this:
- Lookup BeanManager in JNDI
We should avoid requiring this. JNDI lookups are expensive (they require
synchronization) compared to straight singleton lookups (which at least two
CDI impls, Weld and OWB support today).
Ok. But don't singletons wreak havoc with classloaders. What if CDI was
being used as library in a container that did not support CDI (jetty,
tomcat). Wouldn't we want to avoid singletons?
I am ok with dropping JNDI lookup. The CDI container should be in a well
known locations stored in the ServletContext, i.e., application scope. There
should be no classical singleton. There should be nothing that would prevent
a web application restart. We should not assume that CDI will only be used
by Java EE 6. It should be OSGI, web application, re-loadable friendly.
I mentioned JNDI because currently the BeanManager is stored in JNDI.
- If not found, try to load BeanManagerLocator from system property.
What is the use case for this?
Flexibility. Let CDI be used in places we have not thought of.
- If not found, try to load BeanManagerLocator from ServiceLoader.
- If more than one BeanManagerLocator found, sort by priority or die if
there is more than one. (not sure about the sort, I think it should die, but
can be convinced otherwise).
Why can it not just be that a service loader is used to find the
BeanManagerLocator, and that there must not be more than one property name
in use (if there is, it's an error).
I doubt more than one CDI impl (due to scanning) can be running at the same
time, and I'm also not sure this is useful.
I agree. There should be only one. If there is more than one, it is an
error. I was trying to include the logic that was in Solder. The stuff I
have done, throws as exception if more than one is found.
- Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1.
I think the BeanManager interface is too low level.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
6:28 a.m.
On 26 Apr 2011, at 22:58, Rick Hightower wrote:
Inline...
On Tue, Apr 26, 2011 at 12:38 AM, Peter Muir <pmuir(a)redhat.com> wrote:
On 26 Apr 2011, at 00:07, Rick Hightower wrote:
> We need a general purpose way of finding a BeanManager.
> +1 for me.
I agree, this is something we can make easier for CDI 1.0. In part we need to see what
the javax.inject EG comes up with here, as we build on their foundations.
FTR this is a (possibly the?) reason CDI moved away from having a "Container"
API -- this is supposed to be addressed by JSR-330 part 2, and so was intentionally left
out of CDI 1.0 so that we didn't end up with an inconsistent approach. I need to check
with the EE spec lead on the status of the 330-part2 work.
Ok.
>
> This way should include JNDI lookup to a fallback BeanManagerLocator that uses a
ServiceLoader
> +1 for me.
Regarding design for this feature, we should keep it as low footprint in terms of
specification and API class as possible, as (always) the impl can make a better decision
about how to locate the BM than we can. Rick, can you elaborate on why you want all these
additonal JNDI lookup, system property lookup, priority lookup stuff? Comments on each in
line.
>
> I think the behavior should look like this:
>
> Lookup BeanManager in JNDI
We should avoid requiring this. JNDI lookups are expensive (they require synchronization)
compared to straight singleton lookups (which at least two CDI impls, Weld and OWB support
today).
Ok. But don't singletons wreak havoc with classloaders. What if CDI was being used as
library in a container that did not support CDI (jetty, tomcat). Wouldn't we want to
avoid singletons?
Singletons can be implemented in many ways, they don't have to be static based (which
I think you are referring to in your comment) - suggest you take a look at the way this is
implemented in GlassFish or Weld for example (or I think OWB has a similar concept)
I am ok with dropping JNDI lookup. The CDI container should be in a well known locations
stored in the ServletContext, i.e., application scope. There should be no classical
singleton. There should be nothing that would prevent a web application restart. We should
not assume that CDI will only be used by Java EE 6. It should be OSGI, web application,
re-loadable friendly.
I mentioned JNDI because currently the BeanManager is stored in JNDI.
In general I think this is swerving too much into specifying implementation. We certainly
musn't specify that the Bean Manager must be *stored* in the servlet context or in
JNDI, this is an implementation detail.
What we can do is say that the BM is available for lookup from the ServletContext or JNDI
or via a static method on an API class.
> If not found, try to load BeanManagerLocator from system property.
What is the use case for this?
Flexibility. Let CDI be used in places we have not thought of.
That's not a usecase, that's a get out for not having a usecase ;-) We need to
stick to addressing concrete usecases that have real world applications. So, unless we can
come up with a real use case for this, it shouldn't be put in the spec.
> If not found, try to load BeanManagerLocator from ServiceLoader.
> If more than one BeanManagerLocator found, sort by priority or die if there is more
than one. (not sure about the sort, I think it should die, but can be convinced
otherwise).
Why can it not just be that a service loader is used to find the BeanManagerLocator, and
that there must not be more than one property name in use (if there is, it's an
error).
I doubt more than one CDI impl (due to scanning) can be running at the same time, and
I'm also not sure this is useful.
I agree. There should be only one. If there is more than one, it is an error. I was
trying to include the logic that was in Solder. The stuff I have done, throws as exception
if more than one is found.
Because Solder is an extension which is working with multiple impl's of CDI it needs
to jump through hoops that a spec based impl doesn't need.
> Once the BeanManagerLocator is found, use it to return a BeanManager
>
> In addition,
>
> I think we need a simplified interface for BeanManager.
>
>
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
>
> This could just be a utility class, but it should be included with CDI 1.1. I think
the BeanManager interface is too low level.
>
>
>
> --
> Rick Hightower
> (415) 968-9037
> Profile
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
--
Rick Hightower
(415) 968-9037
Profile
4753
days inactive
4755
days old
6 comments
2 participants
participants (2)
-
Peter Muir -
Rick Hightower