• 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

EJB not being called

 
Ranch Hand
Posts: 69
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am unable to figure out if this is a EJB issue or JSF manangedBean issue.I am posting it in EJB forum , if required please move it to JSF forum.I am trying to populate a datatable in jsf from DB .I am using glassfish 4.1,netbeans,mysql and primefaces.This is the code so far (I have not pasted the entity class ):
welcome.xhtml

My EJB

My Controller


My issue is that the control is going to TeamController when i put a debug point (I confirmed it by using the sysout)


the above statement is not printed.Another thing is if I do not use the controller class , if I directly use TeamFacade class directly and call it from JSF page , it is working.But from what i read from the internet its not a good idea to call an EJB directly from JSF.Any idea what is going on?

Thanks
Udaya Krishna
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't see you calling getAllTeams, you only call getTeamList (line 74 of the xhtml file).
 
udaya krishna
Ranch Hand
Posts: 69
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rob spoor ,
You mean like this ?


I tried that already..it did not work!!so i tried this way..

Thanks
Udaya Krishna
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The JSF bean's request scope is pretty useless. Use the view scope.

Second somewhere you do need call the getAllTeams() method, else the list will be empty by default (eg when the constructor is called).

By the way with view scope, the constructor is called every time the page is loaded if I recalled correctly.
 
udaya krishna
Ranch Hand
Posts: 69
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi K.TSang,

I changed the scope to view and in TeamContoller constructor i did this :


and in my xhtml :

still no luck !!

Thanks
Udaya Krishna
 
K. Tsang
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Forget the JSF view for the minute. After calling the EJB in JSF bean, are there items in the list?

If not, change the EJB method to output something before returning to see if the JSF bean is calling it.
 
Saloon Keeper
Posts: 27752
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
Nitpick time.

You do not write Controllers in JSF, only View Templates and Models. The presence of business logic/action methods in backing beans does not make them Controllers. A Controller is an object whose sole function is to replicate data to and from the Model and View and in JSF that function is automatic - the Controllers are pre-supplied as part of JSF itself.

This is not proper:


JSF "value" attributes are not function calls, they are property references. Thus, if you code:


And disregarding that "teamController" isn't itself a Controller, JSF's internal Controller will invoke teamController's "getAllTeams()" method.

The distinction is clearer in this example:

Here, JSF's Controllers will invoke "getFirstName()" to render the form and "setFirstName()" to set myBean's firstName property. That's the distinction between the "${}" EL notation (read-only) and the "#{}" EL notation (read-write). And in case you're wondering, "${}" does work in JSF, but it's not generally used, since "#{}" can be used for the same purpose.

In JSF1, a dataTable required an explicity intermediary object (DataModel) to provide a façade for the actual model data. The DataModel decorates the raw data model with cursor information, which helps both in rendering the table and in determining what row you clicked on when you select a commandLink or commandButton in a table row.

In JSF2, you can specify a raw array or ordered Collection as the "value" attribute of a dataTable. However, if you do this, the DataModel is constructed automatically and anonymously. Meaning that unlike cases where you've explicitly constructed it, you won't have access to those useful goodies. So I recommend always explicitly constructing a DataModel to wrap your table's backing data unless the table will be strictly display-only and you don't need the extra functionality. You're not saving much in the way of coding and nothing in the way of overhead by using raw model data, since, like I said, if you don't construct the DataModel, JSF will do so itself.

Regardless of who constructed the DataModel, however, having its backing bean in Request scope means that the model data is completely invalidated every time the form is re-submitted and the DataModel itself is destroyed. That makes it impossible to track cursor information properly.

Request Scope is pretty useless in JSF.
 
udaya krishna
Ranch Hand
Posts: 69
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim,

Thanks for the reply.As you can see I initially tried

That did not work (and I think we call the methods in JSF using "action" attribute), so I tried that way and what I am trying to achieve is rather than making an EJB directly as a backing bean/managed bean I wanted another layer inbetween hence I wrote the Controller class.I did not know what other approach I needed to think of.So I am still stuck here .Any help in the code is welcome.

Thanks
Udaya Krishna
 
udaya krishna
Ranch Hand
Posts: 69
Netbeans IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok another thing I noticed here.If I try @ManagedBean annotation in TeamController class instead of @Named the data is populated!!Looks like I need to dig deep a little on concepts of EJB and ManagedBean.Meanwhile any help is appreciated.

Thanks
Udaya Krishna A
 
Tim Holloway
Saloon Keeper
Posts: 27752
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
It's very difficult to use EJBs or similar ORM objects directly as backing beans. That's because backing beans are essentially unique and ORM model objects generally aren't and the JSF managed-bean functions have no ability to fetch a specific instance of an object and present it as a Managed Bean - they only support no-argument constructors.

So the usual case is that you would define a GUI Model object (not a Controller - like I said, in JSF you do not write Controllers), and that GUI Model object would contain one or more Data Object Model (EJB) objects as properties. So while there are no Controllers, you have 2 different types of Model objects, 1 for JSF, one for ORM. And they're (usually) both POJOs.

If @Named didn't work and @ManagedBean did, chances are that the server environment you're deploying in doesn't support CDI, which is what defines and implements the @Named attribute.

In theory, CDI should be replacing the JSF-specific annotations, however, I haven't been rushing to do so myself since I've got a lot of investment in Spring and the CDI equivalents to Spring functions have been disappointing so far.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic