• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using generic templates for managed beans

 
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm wondering if there's a way to build a template for managed beans which could be extended by a constructor instead of re-writing beans for each entity. I can do that quite easily for Dao objects by creating facades and using those facades to create Dao implementations for specific entities. Not sure if the same concept works for managed beans and haven't really come accross any searches.


I wrote the following but I'm not sure how to implement or even if the concept of generics and templating can be applied to managed beans in the same way it can be applied to Dao classes:



The above assumes there's only one method needed in the bean. I thought of extending like this:



Is the same concept for creating dao templates possible for managed beans? Thanks in advance
 
Bartender
Posts: 543
4
Netbeans IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have you tried just implementing that and making it managed?
 
Jay Tai
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yep, I get the following exception:



The class it can't find looks like this:



I also tried to build an implementation class and implemented that:



It gave me:

 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm a little wary of attempting to "template-ize" JSF because the JSF architecture is designed with most of the really important template-like functions already built in.

But your example is certainly a reasonable one.

The reason it fails, however, isn't because it's JSF. I'm pretty sure that the EJB annotations aren't being inherited by the subclasses. Annotations can be defined as inheritable or non-inheritable, so they have to be used with care.
 
Jay Tai
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would sure save a heck of a lot of tedious grunt work if thre's a way i could template managed beans. Especially if they all involve the same old CRUD operations. I guess my question would be how I would make inherently non-inheritable EJBs inherited by the sub class. I was also wary, but the DAOs template with little problems and work perfectly. I guess there must be a way to extend the really important template functions where managed beans are concerned or maybe i'm missing some key limitations in the JSF architecture.
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The main limitation is that JSF is basic POJO. It does not support constructors with arguments in them. About as close as you can get is to inject in an argument-constructed property object, like something Spring could build, but the actual JSF managed bean mechanism can only invoke a no-arguments constructor.

One trick I use in situations like these is to make an abstract base class with an abstract accessor method. So, for example:



This forces the subclasses to include code maybe something like this:



Somewhat kludgy, but better than nothing.
 
Jay Tai
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm trying to avoid Spring which looks like it has a big learning curve and expensive configuration overheads. I think I see where you're going with your abstract class. I'm still thinking about how to adapt that to a managed bean. I'll post the results. Meanwhile I'd be interested to know if you've ever managed to apply that to a managed bean succesfully did CDI with EJBs. Thank you!
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is the kind of code I would put into a template-based Managed Bean. Actually, I think have.

The core Spring is (or was) only about 150K. Problem is, usually a lot of secondary Spring subsystems end up moving in.

On the plus side, they move in because they're so darned useful. They make it easy to work with plug-replaceable components, handle the grunt wrappers around persistence code (such as getting and releasing JDBC Connections with proper allowances for Exceptions, and so on.

I looked at CDI in depth about 2 months ago and was disappointed. It's like Spring but missing some of Spring's capabilities and there didn't seem to be as much effort made into making Spring legacy code easily transition into it as I'd like.

I'm already at JBoss for making JBoss 4 upgrades equivalent to the VB-to-VB.Net transition without having further breakages to deal with.
 
Jay Tai
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm certainly much less of a veteran when it comes to different java flavors. I figure JSF is key if only for the learning experience. I intend to keep things as POJO as possible till I'm more fluent. But I'm curious, is spring really an xml file configuration nightmare? Obviously one drawback with JSF is the tedious repition required to build generic classes. Here I think your abstract template could be a life saver. But I'm really curious about diving into Spring
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spring and JSF both started out using XML, but in both cases, XML now is the last-resort (override) mechanism, with annotations generally preferred.

For example, to define a DAO in Spring, you'd create a POJO class and annotate it with the Spring @Repository marker. You'd probably also annotate it as @Transactional.

To inject it into a JSF backing bean, you'd use the @ManagedBean annotation and an EL expression, since as long as faces-config wired in the Spring/JSF expression bridge, Spring beans and JSF beans would appear indistinguishable in the EL namespace.

The Manning Press "Spring in Action" book has what I think is a pretty good hit-the-ground-fast introduction.

Spring objects are POJO. That's the whole point of Spring. To be able to take POJOs and wire them together, just as JSF takes POJOs (backing beans) and wires then together. The only reason I combine both in my webapps is that JSF's bean management is specific to backing beans and no-argument constructors, but Spring can take generic beans and has the option to use argument-based constructors and/or factories. It doesn't, however attempt to replace JSF's bean management or processing lifecycle features, so the two are more complementary than exclusive.
 
Jay Tai
Ranch Hand
Posts: 222
Netbeans IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The fact that Spring and JSF are complimentary and Spring is suited for building generic beans is music to my ears. The choice I have now is either to try and implement your abstract class and continue and entirely JSF app or to try combing it with a Spring configuration for building some of my generic beans. I know this may sound like an open ended question but do you think it would be realistic to be up and running with at least one or two generic bean classes in a matter of weeks following the book you suggested?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, if my memory isn't playing tricks again, I've got at least one JSF app using an inheritable base class on Managed Beans whose persistence service is an injected Spring object.

Backing beans are not Spring beans, since JSF manufactures them directly, as needed without using Spring. However, ManagedProperties are set via EL expressions and those expressions can reference either JSF-managed or Spring-managed beans as long as you have the EL bridge setup in faces-config.xml.
 
Not so fast naughty spawn! I want you to know about
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic