Thanks Matthias,

I do not use EL API, and I don't understand what you mean by DI-container.


But I can show you the following example:

I have an application scoped bean and a session scoped bean (MbSessionBean)
In my application scoped bean I found code like that:

         public String getImageUrl()
         {
                 int layout = 
(MbSessionBean)getManagedBean("mbsessionbean").getLayout();

                 if(layout == 1)
                         return "/pages/imageone.jpg";
                 else
                         return "/pages/imagetwo.jpg";
         }



        protected static final Object getManagedBean(String beanName)
        {
                
                Object ob;
                FacesContext facesContext = FacesContext.getCurrentInstance();
                Application app = facesContext.getApplication();
                javax.faces.el.ValueBinding vb 
=app.createValueBinding("#{"+beanName+"}");
                ob = vb.getValue(facesContext);
                return ob;
        }



Of course this is not nice code, because I ask user dependent data
from a method of an application scoped bean.
But I wonder how it can work.

How does the application bean know which session scoped bean it should ask?

Obviously it works. But does it only work by chance, ( for example
because there has never been 2 or more session beans with different
data at the same time...) or does it really work?

If it works (even the code is ugly) I could let it this way now and
clean it another time....


Cheers Georg


2009/4/27 Matthias Wessendorf <[email protected]>:
> I'd not do that...
>
> generally fetching beans by using the EL API is not that good.
> Use a real DI container for that
>
> -M
>
> On Mon, Apr 27, 2009 at 11:22 AM, Georg Füchsle <[email protected]> 
> wrote:
>> Hallo,
>>
>> I found such things in my code:
>>
>> In an static method of an application scoped bean I fetch a session
>> scoped bean and read some data from it.
>> It seems to work. But is it really allowed?
>>
>> Georg
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>

Reply via email to