Wolf:
Was not referring to the quality of the
code at all—notice that I said “sounds” and not “looks”
like a mess. I was referring to the setup of filters, DIs et al.
As for your calling the dep in the
constructor and expecting setter injection to provide the dep, well. =)
Btw, this looks to be the same issue with Robert Cambell (see highlighted part following).
Not to sound didactic, guys, but this may
help: http://www.martinfowler.com/articles/injection.html#FormsOfDependencyInjection
As an aside: if you were using Spring 2.0,
you would be able to manage the backing bean from spring (servlet scoping) and
use constructor injection to avoid the issue. Can anyone from the EG shed any
light as to whether or not JSF 1.2 (or a later version) will support
constructor (or any other form of) injection?
From:
Robert Campbell [mailto:[EMAIL PROTECTED]
Sent: Friday, 21 July 2006 6:35 PM
To: MyFaces
Discussion
Subject: Re: JSF/Spring
integration - managed-property problem
Lol.. i know the code
looks like crap - it's just for a quick proof of concept, no worries.
Since time is an issue for me, I gave up this problem a few days ago and just
used a crappy work-around:
In the
constructor of SearchForm (the JSF Managed Bean that I tried
injecting the Spring bean into) I just threw in:
ServletContext servletContext =
getServletContext();
ApplicationContext appContext =
WebApplicationContextUtils.getWebApplicationContext(servletContext);
SearchManager searchManager =
(SearchManager) appContext.getBean("searchManager");
setSearchManager(searchManager);
Which works.. but again, obviously not following best-practices :-/
…difference in semantics between type 2 (setter) and type
3 (constructor) injection =)
If parts of this demo go live I'll need to really figure this problem out to
follow best-practices, plus I'm simply curious as to why it doesn't work.. arg.
On 7/19/06, Wolf
Benz <[EMAIL PROTECTED]>
wrote:
Wow that sounds like a mess!
-- Now that's a nice thing to say about someone else's code ;-)
Re: the # at the end that just means your extensions filter is
probably not binding the _javascript_ properly. All links (generally)
in JSF are just to # on the current page, then _javascript_ traps the
action and converts it to a form POST (because HTML does not support
anything like <a href="" method="post">). The fact that
it's not
taking you anywhere (except #) means the _javascript_ did not catch the
click properly. I would guess this is something to do with the way in
which you've setup the filters.
-- I just turned the extension filters off and I got it all back to
working... :-)
Are you managing your backing beans with spring? Or simply trying
to inject spring beans into JSF beans? Can you show more examples of
your code?
-- Sure. I followed the 1st approach here: http://www.jroller.com/
page/cagataycivici?entry=integrating_jsf_and_spring
(nice link)
It's nice. It allows for declarative wiring.
I think the reason they're not injected is because Spring injects the
JSF beans after their constructor has run. I call the dependency *in*
the constructor.
I solved this by calling (in the JSF Constructors) :
if(facade == null){
logger.warn("Facade still
null. Cascading to explicit Instantiation.
");
facade =
(WebFacade)FacesContextUtils.getWebApplicationContext
(FacesContext.getCurrentInstance()).getBean("webfacade");
}
As for Robert Cambell's issue—I thought of something—the order in
which the listeners occur is important. Make sure
ContextLoaderListener is right at the top.
-- That's the case. (read that before)
Bye, Wolf
