You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Mike Kienenberger <mk...@gmail.com> on 2005/10/26 20:21:48 UTC
Providing spring-like InitializingBean interface for JSF managed beans
I've been reviewing open issues with my current application, and some
of them seem to deal with using Spring. This is kind of frustrating
because I'm finding that JSF managed beans do ALMOST everything I want
without Spring, except for providing a
InitializingBean.afterPropertiesSet() method call after a new bean's
properties have been set.
So after pondering it for a bit, it occurred to me that there's no
reason why support for this interface (repackaged for MyFaces) can't
be added to the org.apache.myfaces.el.VariableResolverImpl or to the
org.apache.myfaces.config.ManagedBeanBuilder class.
It seems to me that modifying one of the above classes to call the
below code would provide this functionality in a backward-compatible
way that does not affect the TCK.
if (newBean instanceof InitializingBean)
((InitializingBean)newBean).afterPropertiesSet();
This could be done either as the last line in
ManagedBeanBuilder.buildManagedBean() or right after the call to
buildManagedBean() in VariableResolverImpl.resolveVariable.
Unfortunately, I can't see a way to adding this functionality cleanly
as a generic JSF tomahawk extension, so it would have to remain a
MyFaces-only feature.
Thoughts?
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Mike Kienenberger <mk...@gmail.com>.
I see that this functionality has already made it into JSF 1.2, using
annotations. The interesting part of the implementation is that it
also supports a destroy method using ServletRequestListener,
HttpSessionListener, and ServletContextListener.
http://weblogs.java.net/blog/edburns/archive/2005/08/using_ejb_annot.html
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=119
On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
> I've been reviewing open issues with my current application, and some
> of them seem to deal with using Spring. This is kind of frustrating
> because I'm finding that JSF managed beans do ALMOST everything I want
> without Spring, except for providing a
> InitializingBean.afterPropertiesSet() method call after a new bean's
> properties have been set.
>
> So after pondering it for a bit, it occurred to me that there's no
> reason why support for this interface (repackaged for MyFaces) can't
> be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> org.apache.myfaces.config.ManagedBeanBuilder class.
>
> It seems to me that modifying one of the above classes to call the
> below code would provide this functionality in a backward-compatible
> way that does not affect the TCK.
>
> if (newBean instanceof InitializingBean)
> ((InitializingBean)newBean).afterPropertiesSet();
>
> This could be done either as the last line in
> ManagedBeanBuilder.buildManagedBean() or right after the call to
> buildManagedBean() in VariableResolverImpl.resolveVariable.
>
> Unfortunately, I can't see a way to adding this functionality cleanly
> as a generic JSF tomahawk extension, so it would have to remain a
> MyFaces-only feature.
>
> Thoughts?
>
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Marco Mistroni <mm...@gmail.com>.
Hello Mike,
On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> I've been reviewing open issues with my current application, and some
> of them seem to deal with using Spring. This is kind of frustrating
> because I'm finding that JSF managed beans do ALMOST everything I want
> without Spring, except for providing a
> InitializingBean.afterPropertiesSet() method call after a new bean's
> properties have been set.
>
> So after pondering it for a bit, it occurred to me that there's no
> reason why support for this interface (repackaged for MyFaces) can't
> be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> org.apache.myfaces.config.ManagedBeanBuilder class.
>
> It seems to me that modifying one of the above classes to call the
> below code would provide this functionality in a backward-compatible
> way that does not affect the TCK.
>
> if (newBean instanceof InitializingBean)
> ((InitializingBean)newBean).afterPropertiesSet();
>
> This could be done either as the last line in
> ManagedBeanBuilder.buildManagedBean() or right after the call to
> buildManagedBean() in VariableResolverImpl.resolveVariable.
>
> Unfortunately, I can't see a way to adding this functionality cleanly
> as a generic JSF tomahawk extension, so it would have to remain a
> MyFaces-only feature.
>
> Thoughts?
>
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Mike Kienenberger <mk...@gmail.com>.
Sean,
I've taken a more comprehensive look at Shale's ViewController.
Unfortunately, ViewController not the same thing.
ViewController allows you to specify one backing bean per view
(possibly per subview) that will be sent ViewController events for the
duration of the view's existance. I need something that works for
any arbitrary number of managed beans.
-Mike
On 10/26/05, Sean Schofield <se...@gmail.com> wrote:
> Check out Shale's ViewController.
>
> sean
>
> On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > No, I hadn't realized that. Thanks.
> >
> > But it is a hack. I'm more interested in seeing a formal solution.
> > I'd hate to write an application, and have another developer or design
> > tool break it by not maintaining the ordering.
> >
> >
> > > having a class implement a special interface for lifecycle stuff is going out of fashion
> >
> > Well, with all due respect, that's your opinion :)
> >
> > Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
> > mailing lists, but it still seems in fashion there according to 1.2RC2
> > :) For myself, I'd rather implement an interface than configure
> > another xml file. There's little to be gained by making it an xml
> > configuration option.
> >
> > An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
> > not compatible as it breaks the dtd spec.
> >
> > That said, I'd prefer an xml extension over nothing :)
> >
> > Annotations are not a reasonable option at this point, and I don't
> > seem them as being better than an interface.
> >
> >
> > On 10/26/05, Simon Kitching <sk...@obsidium.com> wrote:
> > > Mike Kienenberger wrote:
> > > > I've been reviewing open issues with my current application, and some
> > > > of them seem to deal with using Spring. This is kind of frustrating
> > > > because I'm finding that JSF managed beans do ALMOST everything I want
> > > > without Spring, except for providing a
> > > > InitializingBean.afterPropertiesSet() method call after a new bean's
> > > > properties have been set.
> > > >
> > > > So after pondering it for a bit, it occurred to me that there's no
> > > > reason why support for this interface (repackaged for MyFaces) can't
> > > > be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> > > > org.apache.myfaces.config.ManagedBeanBuilder class.
> > > >
> > > > It seems to me that modifying one of the above classes to call the
> > > > below code would provide this functionality in a backward-compatible
> > > > way that does not affect the TCK.
> > > >
> > > > if (newBean instanceof InitializingBean)
> > > > ((InitializingBean)newBean).afterPropertiesSet();
> > > >
> > > > This could be done either as the last line in
> > > > ManagedBeanBuilder.buildManagedBean() or right after the call to
> > > > buildManagedBean() in VariableResolverImpl.resolveVariable.
> > > >
> > > > Unfortunately, I can't see a way to adding this functionality cleanly
> > > > as a generic JSF tomahawk extension, so it would have to remain a
> > > > MyFaces-only feature.
> > > >
> > > > Thoughts?
> > > >
> > >
> > > Have you considered simply defining a managed property for your beans
> > > that need initialisation?
> > >
> > > <managed-property>
> > > ...
> > > </managed-property>
> > > <managed-property>
> > > ...
> > > </managed-property>
> > > <managed-property>
> > > <description>initialiser called after properties set</description>
> > > <property-name>initialised</property-name>
> > > <value>true</value>
> > > </managed-property>
> > >
> > >
> > > public class MyManagedBean {
> > > public void setInitialised(boolean dummy) {
> > > // here we can do stuff required after all managed
> > > // properties have been set on this bean
> > > ...
> > > }
> > > }
> > >
> > > I haven't tested this, but don't see why it wouldn't work.
> > > Managed properties are always initialised in the order they are
> > > specified in the faces-config file in MyFaces, and with luck it's
> > > actually part of the spec (haven't checked). So it's a *little* bit
> > > hacky but not too bad.
> > >
> > > This doesn't work for managed beans that use <map-entries> or
> > > <list-entries> but those probably don't need post-initialisation anyway.
> > >
> > >
> > > Re a general mechanism for post-init, that would be nice. However the
> > > approach of having a class implement a special interface for lifecycle
> > > stuff is going out of fashion, in favour of lifecycle annotations and
> > > similar. So if anything was to be implemented I would rather see another
> > > xml tag in the managed-bean specifying an initialisation method, or the
> > > ManagedBeanManager checking for an annotation on the target class
> > > (though that does require java 1.5). A possible xml extension would be:
> > > <managed-bean>
> > > <t:post-init xmlns:t="http://myfaces.apache.org/..." method="init"/>
> > >
> > > I haven't checked whether the schema for faces-config.xml is "open" with
> > > respect to elements in foreign namespaces or not; if not that would be a
> > > nice addition.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> >
>
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Sean Schofield <se...@gmail.com>.
Check out Shale's ViewController.
sean
On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
> No, I hadn't realized that. Thanks.
>
> But it is a hack. I'm more interested in seeing a formal solution.
> I'd hate to write an application, and have another developer or design
> tool break it by not maintaining the ordering.
>
>
> > having a class implement a special interface for lifecycle stuff is going out of fashion
>
> Well, with all due respect, that's your opinion :)
>
> Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
> mailing lists, but it still seems in fashion there according to 1.2RC2
> :) For myself, I'd rather implement an interface than configure
> another xml file. There's little to be gained by making it an xml
> configuration option.
>
> An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
> not compatible as it breaks the dtd spec.
>
> That said, I'd prefer an xml extension over nothing :)
>
> Annotations are not a reasonable option at this point, and I don't
> seem them as being better than an interface.
>
>
> On 10/26/05, Simon Kitching <sk...@obsidium.com> wrote:
> > Mike Kienenberger wrote:
> > > I've been reviewing open issues with my current application, and some
> > > of them seem to deal with using Spring. This is kind of frustrating
> > > because I'm finding that JSF managed beans do ALMOST everything I want
> > > without Spring, except for providing a
> > > InitializingBean.afterPropertiesSet() method call after a new bean's
> > > properties have been set.
> > >
> > > So after pondering it for a bit, it occurred to me that there's no
> > > reason why support for this interface (repackaged for MyFaces) can't
> > > be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> > > org.apache.myfaces.config.ManagedBeanBuilder class.
> > >
> > > It seems to me that modifying one of the above classes to call the
> > > below code would provide this functionality in a backward-compatible
> > > way that does not affect the TCK.
> > >
> > > if (newBean instanceof InitializingBean)
> > > ((InitializingBean)newBean).afterPropertiesSet();
> > >
> > > This could be done either as the last line in
> > > ManagedBeanBuilder.buildManagedBean() or right after the call to
> > > buildManagedBean() in VariableResolverImpl.resolveVariable.
> > >
> > > Unfortunately, I can't see a way to adding this functionality cleanly
> > > as a generic JSF tomahawk extension, so it would have to remain a
> > > MyFaces-only feature.
> > >
> > > Thoughts?
> > >
> >
> > Have you considered simply defining a managed property for your beans
> > that need initialisation?
> >
> > <managed-property>
> > ...
> > </managed-property>
> > <managed-property>
> > ...
> > </managed-property>
> > <managed-property>
> > <description>initialiser called after properties set</description>
> > <property-name>initialised</property-name>
> > <value>true</value>
> > </managed-property>
> >
> >
> > public class MyManagedBean {
> > public void setInitialised(boolean dummy) {
> > // here we can do stuff required after all managed
> > // properties have been set on this bean
> > ...
> > }
> > }
> >
> > I haven't tested this, but don't see why it wouldn't work.
> > Managed properties are always initialised in the order they are
> > specified in the faces-config file in MyFaces, and with luck it's
> > actually part of the spec (haven't checked). So it's a *little* bit
> > hacky but not too bad.
> >
> > This doesn't work for managed beans that use <map-entries> or
> > <list-entries> but those probably don't need post-initialisation anyway.
> >
> >
> > Re a general mechanism for post-init, that would be nice. However the
> > approach of having a class implement a special interface for lifecycle
> > stuff is going out of fashion, in favour of lifecycle annotations and
> > similar. So if anything was to be implemented I would rather see another
> > xml tag in the managed-bean specifying an initialisation method, or the
> > ManagedBeanManager checking for an annotation on the target class
> > (though that does require java 1.5). A possible xml extension would be:
> > <managed-bean>
> > <t:post-init xmlns:t="http://myfaces.apache.org/..." method="init"/>
> >
> > I haven't checked whether the schema for faces-config.xml is "open" with
> > respect to elements in foreign namespaces or not; if not that would be a
> > nice addition.
> >
> > Regards,
> >
> > Simon
> >
>
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Mike Kienenberger <mk...@gmail.com>.
@Sean / Shale ViewController:
Thanks. I'll take a look at that. I need to verify that it's
compatible with Facelets.
@Simon / property ordering:
I've given this more thought, and you're probably correct. IDE tools
should be maintaining the order, and using comments should handle any
issues with other developers.
Unfortunately, I now realize that I am also using the
DisposableBean.destroy() method for one of my backing beans, but I may
switch the rest over to using a property initializer.
@Simon / fashions & /trends
My apologies for the way I answered you earlier. I asked for comments
and then refused to listen to yours :)
@Simon / DTDs
The problem is that I'm looking for solutions that work with JSF 1.1.
That means annotations are out, and the solution has to work with the
existing DTDs.
In summary, I think property setting will work for the majority of the
use cases. If Shale is compatible with my project, that will solve
the rest of the issues.
I'd still like to see this supported natively and cleanly by JSF bean
management, though.
-Mike
On 10/26/05, Simon Kitching <sk...@obsidium.com> wrote:
> See comments inline..
>
> [PS:
> Because it's hard to read and hard to reply to.
> Why is top-posting bad?]
>
> Mike Kienenberger wrote:
> > No, I hadn't realized that. Thanks.
> >
> > But it is a hack. I'm more interested in seeing a formal solution.
> > I'd hate to write an application, and have another developer or design
> > tool break it by not maintaining the ordering.
>
> I've checked the JSF spec. The section titled "The Managed Bean
> Facility" explicitly states that:
> <quote>
> Properties are assigned in the order that their <managed-property>
> elements are listed in the application configuration resource.
> </quote>
>
> So there's no worry about other tools or implementations failing to
> respect that. If you have to worry about other developers messing it up,
> you have more important worries :-)
>
> So, apart from the fact that a dummy parameter needs to be passed, this
> solution seems quite reasonable to me.
>
> >
> >
> >> having a class implement a special interface for lifecycle stuff is going out of fashion
> >
> > Well, with all due respect, that's your opinion :)
> >
> > Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
> > mailing lists, but it still seems in fashion there according to 1.2RC2
> > :) For myself, I'd rather implement an interface than configure
> > another xml file. There's little to be gained by making it an xml
> > configuration option.
> >
> > An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
> > not compatible as it breaks the dtd spec.
> >
> > That said, I'd prefer an xml extension over nothing :)
> >
> > Annotations are not a reasonable option at this point, and I don't
> > seem them as being better than an interface.
>
> The reason that special interfaces are being phased out in many cases is
> so that POJO (plain old java objects) can be used. This means that a
> class can be used in multiple contexts rather than being wired for a
> specific purpose. In particular, EJB classes can often make sense
> standalone, or can be used in Spring if they aren't required to
> implement EJB-specific interfaces. Avoiding implementing interfaces also
> makes compilation easier, and can simplify unit testing.
>
> It's a real trend, based on experience with building and maintaining
> real-world projects.
>
> And DTDs are also obsolete :-). The upcoming version of JSF uses schemas
> instead to specify its config file constraints. And schemas have a
> feature where you can declare that an element is allowed to have
> additional xml attributes with any namespace *not* matching the schema's
> namespace. This is very nice for exactly the reasons we are talking
> about here; custom extensions to standard schema definitions.
>
> Regards,
>
> Simon
>
>
Re: Providing spring-like InitializingBean interface for JSF managed
beans
Posted by Simon Kitching <sk...@obsidium.com>.
See comments inline..
[PS:
Because it's hard to read and hard to reply to.
Why is top-posting bad?]
Mike Kienenberger wrote:
> No, I hadn't realized that. Thanks.
>
> But it is a hack. I'm more interested in seeing a formal solution.
> I'd hate to write an application, and have another developer or design
> tool break it by not maintaining the ordering.
I've checked the JSF spec. The section titled "The Managed Bean
Facility" explicitly states that:
<quote>
Properties are assigned in the order that their <managed-property>
elements are listed in the application configuration resource.
</quote>
So there's no worry about other tools or implementations failing to
respect that. If you have to worry about other developers messing it up,
you have more important worries :-)
So, apart from the fact that a dummy parameter needs to be passed, this
solution seems quite reasonable to me.
>
>
>> having a class implement a special interface for lifecycle stuff is going out of fashion
>
> Well, with all due respect, that's your opinion :)
>
> Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
> mailing lists, but it still seems in fashion there according to 1.2RC2
> :) For myself, I'd rather implement an interface than configure
> another xml file. There's little to be gained by making it an xml
> configuration option.
>
> An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
> not compatible as it breaks the dtd spec.
>
> That said, I'd prefer an xml extension over nothing :)
>
> Annotations are not a reasonable option at this point, and I don't
> seem them as being better than an interface.
The reason that special interfaces are being phased out in many cases is
so that POJO (plain old java objects) can be used. This means that a
class can be used in multiple contexts rather than being wired for a
specific purpose. In particular, EJB classes can often make sense
standalone, or can be used in Spring if they aren't required to
implement EJB-specific interfaces. Avoiding implementing interfaces also
makes compilation easier, and can simplify unit testing.
It's a real trend, based on experience with building and maintaining
real-world projects.
And DTDs are also obsolete :-). The upcoming version of JSF uses schemas
instead to specify its config file constraints. And schemas have a
feature where you can declare that an element is allowed to have
additional xml attributes with any namespace *not* matching the schema's
namespace. This is very nice for exactly the reasons we are talking
about here; custom extensions to standard schema definitions.
Regards,
Simon
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Mike Kienenberger <mk...@gmail.com>.
No, I hadn't realized that. Thanks.
But it is a hack. I'm more interested in seeing a formal solution.
I'd hate to write an application, and have another developer or design
tool break it by not maintaining the ordering.
> having a class implement a special interface for lifecycle stuff is going out of fashion
Well, with all due respect, that's your opinion :)
Mind you, I'm stuck at Spring 1.2RC2, and I don't follow the spring
mailing lists, but it still seems in fashion there according to 1.2RC2
:) For myself, I'd rather implement an interface than configure
another xml file. There's little to be gained by making it an xml
configuration option.
An interface is compatible with JSF 1.1 and 1.2. Extending the xml is
not compatible as it breaks the dtd spec.
That said, I'd prefer an xml extension over nothing :)
Annotations are not a reasonable option at this point, and I don't
seem them as being better than an interface.
On 10/26/05, Simon Kitching <sk...@obsidium.com> wrote:
> Mike Kienenberger wrote:
> > I've been reviewing open issues with my current application, and some
> > of them seem to deal with using Spring. This is kind of frustrating
> > because I'm finding that JSF managed beans do ALMOST everything I want
> > without Spring, except for providing a
> > InitializingBean.afterPropertiesSet() method call after a new bean's
> > properties have been set.
> >
> > So after pondering it for a bit, it occurred to me that there's no
> > reason why support for this interface (repackaged for MyFaces) can't
> > be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> > org.apache.myfaces.config.ManagedBeanBuilder class.
> >
> > It seems to me that modifying one of the above classes to call the
> > below code would provide this functionality in a backward-compatible
> > way that does not affect the TCK.
> >
> > if (newBean instanceof InitializingBean)
> > ((InitializingBean)newBean).afterPropertiesSet();
> >
> > This could be done either as the last line in
> > ManagedBeanBuilder.buildManagedBean() or right after the call to
> > buildManagedBean() in VariableResolverImpl.resolveVariable.
> >
> > Unfortunately, I can't see a way to adding this functionality cleanly
> > as a generic JSF tomahawk extension, so it would have to remain a
> > MyFaces-only feature.
> >
> > Thoughts?
> >
>
> Have you considered simply defining a managed property for your beans
> that need initialisation?
>
> <managed-property>
> ...
> </managed-property>
> <managed-property>
> ...
> </managed-property>
> <managed-property>
> <description>initialiser called after properties set</description>
> <property-name>initialised</property-name>
> <value>true</value>
> </managed-property>
>
>
> public class MyManagedBean {
> public void setInitialised(boolean dummy) {
> // here we can do stuff required after all managed
> // properties have been set on this bean
> ...
> }
> }
>
> I haven't tested this, but don't see why it wouldn't work.
> Managed properties are always initialised in the order they are
> specified in the faces-config file in MyFaces, and with luck it's
> actually part of the spec (haven't checked). So it's a *little* bit
> hacky but not too bad.
>
> This doesn't work for managed beans that use <map-entries> or
> <list-entries> but those probably don't need post-initialisation anyway.
>
>
> Re a general mechanism for post-init, that would be nice. However the
> approach of having a class implement a special interface for lifecycle
> stuff is going out of fashion, in favour of lifecycle annotations and
> similar. So if anything was to be implemented I would rather see another
> xml tag in the managed-bean specifying an initialisation method, or the
> ManagedBeanManager checking for an annotation on the target class
> (though that does require java 1.5). A possible xml extension would be:
> <managed-bean>
> <t:post-init xmlns:t="http://myfaces.apache.org/..." method="init"/>
>
> I haven't checked whether the schema for faces-config.xml is "open" with
> respect to elements in foreign namespaces or not; if not that would be a
> nice addition.
>
> Regards,
>
> Simon
>
Re: Providing spring-like InitializingBean interface for JSF managed
beans
Posted by Simon Kitching <sk...@obsidium.com>.
Mike Kienenberger wrote:
> I've been reviewing open issues with my current application, and some
> of them seem to deal with using Spring. This is kind of frustrating
> because I'm finding that JSF managed beans do ALMOST everything I want
> without Spring, except for providing a
> InitializingBean.afterPropertiesSet() method call after a new bean's
> properties have been set.
>
> So after pondering it for a bit, it occurred to me that there's no
> reason why support for this interface (repackaged for MyFaces) can't
> be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> org.apache.myfaces.config.ManagedBeanBuilder class.
>
> It seems to me that modifying one of the above classes to call the
> below code would provide this functionality in a backward-compatible
> way that does not affect the TCK.
>
> if (newBean instanceof InitializingBean)
> ((InitializingBean)newBean).afterPropertiesSet();
>
> This could be done either as the last line in
> ManagedBeanBuilder.buildManagedBean() or right after the call to
> buildManagedBean() in VariableResolverImpl.resolveVariable.
>
> Unfortunately, I can't see a way to adding this functionality cleanly
> as a generic JSF tomahawk extension, so it would have to remain a
> MyFaces-only feature.
>
> Thoughts?
>
Have you considered simply defining a managed property for your beans
that need initialisation?
<managed-property>
...
</managed-property>
<managed-property>
...
</managed-property>
<managed-property>
<description>initialiser called after properties set</description>
<property-name>initialised</property-name>
<value>true</value>
</managed-property>
public class MyManagedBean {
public void setInitialised(boolean dummy) {
// here we can do stuff required after all managed
// properties have been set on this bean
...
}
}
I haven't tested this, but don't see why it wouldn't work.
Managed properties are always initialised in the order they are
specified in the faces-config file in MyFaces, and with luck it's
actually part of the spec (haven't checked). So it's a *little* bit
hacky but not too bad.
This doesn't work for managed beans that use <map-entries> or
<list-entries> but those probably don't need post-initialisation anyway.
Re a general mechanism for post-init, that would be nice. However the
approach of having a class implement a special interface for lifecycle
stuff is going out of fashion, in favour of lifecycle annotations and
similar. So if anything was to be implemented I would rather see another
xml tag in the managed-bean specifying an initialisation method, or the
ManagedBeanManager checking for an annotation on the target class
(though that does require java 1.5). A possible xml extension would be:
<managed-bean>
<t:post-init xmlns:t="http://myfaces.apache.org/..." method="init"/>
I haven't checked whether the schema for faces-config.xml is "open" with
respect to elements in foreign namespaces or not; if not that would be a
nice addition.
Regards,
Simon
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Mike Kienenberger <mk...@gmail.com>.
Thanks Marco.
Yes, I've been using jsf-spring-2.7.1 since April, and this is how
I've handled InitializingBean up to this point. However, it's
inefficient and introduces unnecessary bugs to use the full Spring
framework when all I really want to do is have my
InitializingBean.afterSetProperties() method called. JSF managed
beans provides all of the other bean management that an average user
needs, but somehow this particular functionality was overlooked in the
design, and it should be corrected.
Also, jsf-spring only works for spring 1.2RC2 and older. Maybe
that'll change at some point with a stable 3.0.0 release, but so far
3.0.0 is unusable due to the lack of backward compatiblity and the
lack of documentation. So that makes upgrading Spring to fix bugs
difficult.
On 10/26/05, Marco Mistroni <mm...@gmail.com> wrote:
> Hello Mike,
> sorry for previous post...i pressed 'send' by mistake
> dunno if you know it already, but have you checked the jsf-spring project
> @sourceforge?
>
> it integrates Spring & JSF perfectly and i am sure it does what you
> want..
>
> thanks and regards
> marco
>
>
> On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
> > I've been reviewing open issues with my current application, and some
> > of them seem to deal with using Spring. This is kind of frustrating
> > because I'm finding that JSF managed beans do ALMOST everything I want
> > without Spring, except for providing a
> > InitializingBean.afterPropertiesSet() method call after a
> new bean's
> > properties have been set.
> >
> > So after pondering it for a bit, it occurred to me that there's no
> > reason why support for this interface (repackaged for MyFaces) can't
> > be added to the
> org.apache.myfaces.el.VariableResolverImpl or to the
> > org.apache.myfaces.config.ManagedBeanBuilder class.
> >
> > It seems to me that modifying one of the above classes to call the
> > below code would provide this functionality in a backward-compatible
> > way that does not affect the TCK.
> >
> > if (newBean instanceof InitializingBean)
> > ((InitializingBean)newBean).afterPropertiesSet();
> >
> > This could be done either as the last line in
> > ManagedBeanBuilder.buildManagedBean() or right after the
> call to
> > buildManagedBean() in
> VariableResolverImpl.resolveVariable .
> >
> > Unfortunately, I can't see a way to adding this functionality cleanly
> > as a generic JSF tomahawk extension, so it would have to remain a
> > MyFaces-only feature.
> >
> > Thoughts?
> >
>
>
Re: Providing spring-like InitializingBean interface for JSF managed beans
Posted by Marco Mistroni <mm...@gmail.com>.
Hello Mike,
sorry for previous post...i pressed 'send' by mistake
dunno if you know it already, but have you checked the jsf-spring project
@sourceforge?
it integrates Spring & JSF perfectly and i am sure it does what you
want..
thanks and regards
marco
On 10/26/05, Mike Kienenberger <mk...@gmail.com> wrote:
>
> I've been reviewing open issues with my current application, and some
> of them seem to deal with using Spring. This is kind of frustrating
> because I'm finding that JSF managed beans do ALMOST everything I want
> without Spring, except for providing a
> InitializingBean.afterPropertiesSet() method call after a new bean's
> properties have been set.
>
> So after pondering it for a bit, it occurred to me that there's no
> reason why support for this interface (repackaged for MyFaces) can't
> be added to the org.apache.myfaces.el.VariableResolverImpl or to the
> org.apache.myfaces.config.ManagedBeanBuilder class.
>
> It seems to me that modifying one of the above classes to call the
> below code would provide this functionality in a backward-compatible
> way that does not affect the TCK.
>
> if (newBean instanceof InitializingBean)
> ((InitializingBean)newBean).afterPropertiesSet();
>
> This could be done either as the last line in
> ManagedBeanBuilder.buildManagedBean() or right after the call to
> buildManagedBean() in VariableResolverImpl.resolveVariable.
>
> Unfortunately, I can't see a way to adding this functionality cleanly
> as a generic JSF tomahawk extension, so it would have to remain a
> MyFaces-only feature.
>
> Thoughts?
>