You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Nicklas Karlsson <ni...@gmail.com> on 2006/03/15 10:14:27 UTC
Managed bean constructor dependencies (Spring)
Hello,
I have wired my beans with the Spring
<application>
<variable-resolver>
org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>
So that the serviceLocator in the managed beans base class gets set:
<managed-bean>
<managed-bean-name>orderBean</managed-bean-name>
<managed-bean-class>orderapplication.view.bean.OrderBean
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>serviceLocator</property-name>
<value>#{serviceLocator}</value>
</managed-property>
</managed-bean>
but the problem is that I can't call any methods (e.g. auto-populate) in the
managed beans constructor that
uses the serviceLocator, since it gets set after the constructor. Since JSF
doesn't have any "init-mehtod" or such,
is there a better way to auto-populate a bean than looking it up manually
from another bean and calling the init method?
Thanks in advance,
Nik
Re: Managed bean constructor dependencies (Spring)
Posted by Nicklas Karlsson <ni...@gmail.com>.
> (Of course if you using spring, why inject a service-location? Why not
> just inject the service?)
>
Well, with a single servicelocator (implementing an interface) I can have a
single setter in a base class
for all backing beans and I don't have to make any xml changes if a bean
uses one or three services from the
locator...
Re: Managed bean constructor dependencies (Spring)
Posted by Barry Kaplan <gr...@memelet.com>.
If you are using spring 2.0, you can define the orderBean in your spring
context:
<bean id="user" class="com.foliofn.folio.ui.user.User">
<aop:scope type="session"/>
<property name="serviceLocator" ref="serviceLocator"/>
</bean>
(Of course if you using spring, why inject a service-location? Why not
just inject the service?)
-barry
Re: Managed bean constructor dependencies (Spring)
Posted by Marco Mistroni <mm...@gmail.com>.
Hello Nicklas,
i think you can do that if you use jsf-spring library..
hth
marco
On 3/15/06, Matthias Wessendorf <mw...@gmail.com> wrote:
>
> Shale itself has an example app, that uses Spring for definition of DAOs.
> That shouldn't be a risk IMHO.
>
> -Matthias
>
> On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
> >
> > > but you can use Shale's Viewcontroller ([1], [2]).
> > > Its init() method is called *after* all properties are set!
> > >
> >
> > How intrusive is this alternative? Is it enough to register the
> > ViewController and you get the additional
> > features and the other stuff will work as before or am I in risk of
> breaking
> > something else ( e.g. the Spring
> > variable resolving) or are there other dependencies?
> >
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>
Re: Managed bean constructor dependencies (Spring)
Posted by Matthias Wessendorf <mw...@gmail.com>.
Shale itself has an example app, that uses Spring for definition of DAOs.
That shouldn't be a risk IMHO.
-Matthias
On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
>
> > but you can use Shale's Viewcontroller ([1], [2]).
> > Its init() method is called *after* all properties are set!
> >
>
> How intrusive is this alternative? Is it enough to register the
> ViewController and you get the additional
> features and the other stuff will work as before or am I in risk of breaking
> something else ( e.g. the Spring
> variable resolving) or are there other dependencies?
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: Managed bean constructor dependencies (Spring)
Posted by Ricardo Tercero Lozano <rt...@gmail.com>.
Your managed beans must extend AbstractViewController. Another problem could
be the view - managed bean matching. It's assumed that a view (jsp page) is
controlled only by one managed bean. The problem is than in Faces this
relation doesn´t exist and a matching algorithm is needed. By default, the
related bean name is obtained doing a transformation based on the view (jsp)
path. I've reworked this behavior (my managed beans are none of the type
path1$path2$beanname), to associate views to managed beans in an xml config
file like this:
<?xml version="1.0" encoding="UTF-8"?>
<views>
<view>
<viewId>/path1/path2/jsfview.jsp</viewId>
<bean-name>myManagedForm</bean-name>
</view>
<view>
...
</view>
...
</views>
If you are interested, let me know and I'll publish the code.
On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
>
> but you can use Shale's Viewcontroller ([1], [2]).
> > Its init() method is called *after* all properties are set!
> >
>
> How intrusive is this alternative? Is it enough to register the
> ViewController and you get the additional
> features and the other stuff will work as before or am I in risk of
> breaking something else ( e.g. the Spring
> variable resolving) or are there other dependencies?
>
Re: Managed bean constructor dependencies (Spring)
Posted by Nicklas Karlsson <ni...@gmail.com>.
>
> but you can use Shale's Viewcontroller ([1], [2]).
> Its init() method is called *after* all properties are set!
>
How intrusive is this alternative? Is it enough to register the
ViewController and you get the additional
features and the other stuff will work as before or am I in risk of breaking
something else (e.g. the Spring
variable resolving) or are there other dependencies?
Re: Managed bean constructor dependencies (Spring)
Posted by Ricardo Tercero Lozano <rt...@gmail.com>.
In fact, shale view controller is a phase listener. The init() method is
called after the component tree is restaured. This means it is called after
*all* properties are set, both from faces-config.xml dependencies and
saveState sets.
What you asked for is the Spring "afterPropertiesSet" functionality. There's
no equal behavior in faces, and I really wonder why.
On 3/15/06, Matthias Wessendorf <mw...@gmail.com> wrote:
>
> Right!
>
> but you can use Shale's Viewcontroller ([1], [2]).
> Its init() method is called *after* all properties are set!
>
> -Matthias
>
> [1] http://struts.apache.org/struts-shale/features-view-controller.html
> [2] http://tinyurl.com/oegu4
>
> On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
> > Hello,
> >
> > I have wired my beans with the Spring
> >
> > <application>
> >
> > <variable-resolver>
> org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
> > </application>
> >
> > So that the serviceLocator in the managed beans base class gets set:
> >
> > <managed-bean>
> > <managed-bean-name>orderBean</managed-bean-name>
> >
> > <managed-bean-class>orderapplication.view.bean.OrderBean
> > </managed-bean-class>
> > <managed-bean-scope>session</managed-bean-scope>
> > <managed-property>
> > <property-name>serviceLocator</property-name>
> > <value>#{serviceLocator}</value>
> > </managed-property>
> > </managed-bean>
> >
> > but the problem is that I can't call any methods (e.g. auto-populate) in
> the
> > managed beans constructor that
> > uses the serviceLocator, since it gets set after the constructor. Since
> JSF
> > doesn't have any "init-mehtod" or such,
> > is there a better way to auto-populate a bean than looking it up
> manually
> > from another bean and calling the init method?
> >
> > Thanks in advance,
> > Nik
> >
>
>
> --
> Matthias Wessendorf
> Zülpicher Wall 12, 239
> 50674 Köln
> http://www.wessendorf.net
> mwessendorf-at-gmail-dot-com
>
Re: Managed bean constructor dependencies (Spring)
Posted by Matthias Wessendorf <mw...@gmail.com>.
Right!
but you can use Shale's Viewcontroller ([1], [2]).
Its init() method is called *after* all properties are set!
-Matthias
[1] http://struts.apache.org/struts-shale/features-view-controller.html
[2] http://tinyurl.com/oegu4
On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
> Hello,
>
> I have wired my beans with the Spring
>
> <application>
>
> <variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
> </application>
>
> So that the serviceLocator in the managed beans base class gets set:
>
> <managed-bean>
> <managed-bean-name>orderBean</managed-bean-name>
>
> <managed-bean-class>orderapplication.view.bean.OrderBean
> </managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> <managed-property>
> <property-name>serviceLocator</property-name>
> <value>#{serviceLocator}</value>
> </managed-property>
> </managed-bean>
>
> but the problem is that I can't call any methods (e.g. auto-populate) in the
> managed beans constructor that
> uses the serviceLocator, since it gets set after the constructor. Since JSF
> doesn't have any "init-mehtod" or such,
> is there a better way to auto-populate a bean than looking it up manually
> from another bean and calling the init method?
>
> Thanks in advance,
> Nik
>
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
Re: Managed bean constructor dependencies (Spring)
Posted by Phanidhar Adusumilli <ph...@gmail.com>.
Shale's viewcontroller is not intrusive, The only limitation is that there
can be only one view controller per page. And it is called after the view is
restored/created.
If the page has more than one managed bean and the init mechanism is needed
for those beans the following 2 ways can be considered (instead of calling
an init method from a setter):
1. By using observer pattern with viewcontroller. Use shale's viewcontroller
for the page and let the other managed beans which need the
init/prerender/preprocess/destroy mechanism register themselves to the view
controller from the constructor. Then in the viewcontroller's
init/destroy/preprocess/prerender methods call the same methods for all the
registered beans.
2. Creating a custom variable resolver. This method does not use shale's
view controller. instead the custom variable resolver acts like a decorator
to the existing resolver. Once the variable is resolved (the bean is
instantiated and all the setters are called) call init.
On 3/15/06, Nicklas Karlsson <ni...@gmail.com> wrote:
>
> Not the most elegant way but works for me.
> >
>
> I think I'll settle for something like that - I am overriding
> setServiceLocator and call the init method after the super()-call.
> Seems to be working, and I prefer doing a documented "less-than-ideal"
> solution that introducing a new component into
> the palette.
>
>
Re: Managed bean constructor dependencies (Spring)
Posted by Nicklas Karlsson <ni...@gmail.com>.
>
> Not the most elegant way but works for me.
>
I think I'll settle for something like that - I am overriding
setServiceLocator and call the init method after the super()-call.
Seems to be working, and I prefer doing a documented "less-than-ideal"
solution that introducing a new component into
the palette.
Re: Managed bean constructor dependencies (Spring)
Posted by Bjoern Mehner <Bj...@icw.de>.
Hi,
A pragmatic way is described in http://wiki.apache.org/myfaces/FAQ bottom
of the page.
Not the most elegant way but works for me.
bye, Bjoern
--------------------------------------------------
Björn Mehner
InterComponentWare AG
Otto-Hahn-Str. 3
D-69190 Walldorf, Germany
"Nicklas Karlsson" <ni...@gmail.com> wrote on 15.03.2006 10:14:27:
> Hello,
>
> I have wired my beans with the Spring
>
> <application>
> <variable-resolver>org.springframework.web.jsf.
> DelegatingVariableResolver</variable-resolver>
> </application>
>
> So that the serviceLocator in the managed beans base class gets set:
>
> <managed-bean>
> <managed-bean-name>orderBean</managed-bean-name>
> <managed-bean-class>orderapplication.view.bean.OrderBean
> </managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> <managed-property>
> <property-name>serviceLocator</property-name>
> <value>#{serviceLocator}</value>
> </managed-property>
> </managed-bean>
>
> but the problem is that I can't call any methods (e.g. auto-
> populate) in the managed beans constructor that
> uses the serviceLocator, since it gets set after the constructor.
> Since JSF doesn't have any "init-mehtod" or such,
> is there a better way to auto-populate a bean than looking it up
> manually from another bean and calling the init method?
>
> Thanks in advance,
> Nik