[cdi-dev] [JBoss JIRA] Commented: (CDI-117) Add BeanManager to a ServletContext attribute
Rick Hightower
richardhightower at gmail.com
Mon Apr 25 18:57:28 EDT 2011
I checked it out. Ok... I am finally starting to realize what Seam Solder
is. :)
This is good. I like the order bit for the provider / serviceLoader.
...
CDISource has some overlap with Seam Solder so I will start really looking
into what Seam Solder does more fully. (Get ideas, share ideas, etc.)
I wrote a Spring CDI integration (on top of CDISource which works with Weld,
Candi and OpenWebBeans) piece that needs to hold onto an application
context, but I wanted to do this in a generic way as possible.
See...
https://github.com/CDISource/cdisource/tree/master/spring/src/main/java/org/cdisource/springintegration/springsupport
Imagine if instead of locating a Spring application context, it was locating
a bean container. (In other words look at the design and style instead of
what it is doing)
(The actual bean container lookup, I shared earlier needs a bit of
refactoring)
The ApplicationContextLocator.java has one method that returns an
Application Context
https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/springsupport/ApplicationContextLocator.java
(again imagine the words were BeanContainer)
The ApplicationContextLocatorManager
Locates an instance of ApplicationContextLocator then stores it in a
"singleton" that is web application friendly.
...
>From the JavaDocs:
ApplicationContextLocatorManager, this is used to find an
ApplicationContextLocator. An ApplicationContextLocator locates an
application context. This does not use a normal singleton. It uses a
singleton that will not prevent a web application from reloading. It does
this by using WeakHashMap with WeakReference keyed on the current
classloader. To load the ApplicationContextLocator it first checks to see if
a property or system property has been set called
org.cdisource.springintegration.springsupport.ApplicationContextLocator. If
this has not been set, then it checks the ServiceLoader. If more than one
item is loaded form the ServiceLoader, it throws an exception. If one
ApplicationContextLocator is found with the ServiceLoader then it uses this
ApplicationContextLocator. Lastly, it instantiates a
ApplicationContextLocatorImpl which is the default implementation.
(Again imagine it was doing this for BeanManager instead).
https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/springsupport/ApplicationContextLocatorManager.java
I am going to refactor our BeanContainer pieces to adopt a
similar philosophy. (Currently, it has some ugly singleton bits).
On Mon, Apr 25, 2011 at 2:37 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> We have explored a similar ServiceLoader approach in Solder, for reference.
> (Pardon the reminder if I already cited it).
>
>
> https://github.com/seam/solder/tree/master/api/src/main/java/org/jboss/seam/solder/beanManager
>
> Here's the implementation that puts the BeanManager in the ServletContext.
>
>
> https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/seam/servlet/beanManager/ServletContextAttributeProvider.java
>
> It's easy for the spec to say "you should never have to lookup the
> BeanManager as you should always be able to use dependency injection."
> However, the reality is, we have to adopt to the world around us. Thus,
> standardizing this API would be fantastic.
>
> -Dan
>
>
> On Mon, Apr 25, 2011 at 15:23, Rick Hightower <richardhightower at gmail.com>wrote:
>
>> Andy Gibson, Rob Williams and I, implemented something like this for
>> CDISource.
>> It works with Weld, OpenWebBeans and Candi.
>>
>> We have a BeanContainerManager that uses java.util.ServiceLoader.
>>
>> see
>>
>>
>> https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/main/java/org/cdisource/beancontainer/BeanContainerManager.java
>>
>> I think in addition to the ability to easily load a BeanManager, we need a
>> simplified interface for dealing with beans. BeanManager is a bit at the SPI
>> level. It needs a Facade to make it easier to use.
>>
>> Compare the BeanManager to the Spring's Application Context. I think the
>> BeanManager should be more like the Spring Application Context.
>>
>> for some ideas see:
>>
>>
>> https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/main/java/org/cdisource/beancontainer/BeanContainer.java
>>
>> The Spring integration piece that I wrote tries to find the BeanManager in
>> JNDI and then uses the Service Locator if it does not find it in JNDI.
>>
>> I think it would be nice if there was a BeanManagerFactory that looks up
>> first using JNDI, then uses a Service Locator if it can't find it in JNDI.
>>
>> Ok it is not the exact behavior, but I know what you are taking about:
>>
>>
>> https://github.com/CDISource/cdisource/blob/master/spring/src/main/java/org/cdisource/springintegration/BeanManagerLocationUtil.java
>>
>>
>>
>>
>> On Mon, Apr 25, 2011 at 12:38 AM, Pete Muir (JIRA) <
>> jira-events at lists.jboss.org> wrote:
>>
>>>
>>> [
>>> https://issues.jboss.org/browse/CDI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597724#comment-12597724]
>>>
>>> Pete Muir commented on CDI-117:
>>> -------------------------------
>>>
>>> Cloves please file an issue for your approach.
>>>
>>> > Add BeanManager to a ServletContext attribute
>>> > ---------------------------------------------
>>> >
>>> > Key: CDI-117
>>> > URL: https://issues.jboss.org/browse/CDI-117
>>> > Project: CDI Specification Issues
>>> > Issue Type: Feature Request
>>> > Components: Java EE integration
>>> > Affects Versions: 1.0
>>> > Reporter: Christian Kaltepoth
>>> > Priority: Minor
>>> >
>>> > CDI 1.0 defines a JNDI lookup as the standard way to obtain the
>>> BeanManager for resources not managed by the CDI environment. However in a
>>> servlet environment it would be much easier to get the BeanManager from a
>>> standardized servlet context attribute. This would be also a major
>>> simplification in environments that don't support JNDI (for example GAE) or
>>> that don't allow to use the standard JNDI name for the BeanManager (for
>>> example Apache Tomcat).
>>> > This topic was already discussed on weld-dev about a year ago [1]. Weld
>>> 1.0 already supports this [2] and OpenWebBeans also added this feature [3].
>>> Unfortunately Weld 1.1 changed the attribute to a Weld-specific name in [4]
>>> which currently leads to much confusion [5].
>>> > As both of the major CDI implementations support this feature I think
>>> it should finally be put into the spec.
>>> > [1] http://lists.jboss.org/pipermail/weld-dev/2010-March/002359.html
>>> > [2] https://issues.jboss.org/browse/WELD-202
>>> > [3] https://issues.apache.org/jira/browse/OWB-360
>>> > [4] https://jira.jboss.org/browse/WELD-679
>>> > [5]
>>> http://seamframework.org/Community/GettingBeanManagerFromServletContextWithWeld11
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> For more information on JIRA, see:
>>> http://www.atlassian.com/software/jira
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>>
>>
>> --
>> *Rick Hightower*
>> (415) 968-9037
>> Profile <http://www.google.com/profiles/RichardHightower>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20110425/70872ef0/attachment-0001.html
More information about the cdi-dev
mailing list