aspose file tools*
The moose likes JSF and the fly likes Unidentified exception => javax.faces.FacesException: javax.el.ELException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Unidentified exception => javax.faces.FacesException: javax.el.ELException" Watch "Unidentified exception => javax.faces.FacesException: javax.el.ELException" New topic
Author

Unidentified exception => javax.faces.FacesException: javax.el.ELException

Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

Hello folks!

I've been debugging an Exception here without success in finding the root cause. I know around it lies in, but not exactly what's causing it. My code is:

VIEW:
--------



CONTROLLER:
------------------



Through debugging, I know the exception is thrown when



is called, this one:

javax.faces.FacesException: javax.el.ELException: /webPages/agenda/agendaPreVenda.xhtml @178,88 rendered="#{agendaPreVendaController.habilitaTransferencia}":
Error reading 'habilitaTransferencia' on type br.com.wjnegocios.controller.agenda.AgendaPreVendaController


As we can see, the method



is a renderer method invoked to define when the respective outputPanel should be visible.

Could anyone help elucidate where to attack to get this resolved?

Thanks in advance!


DJ aspirant, Engineering undergraduate, Tokusatsus addicted, fond of English language and Asia's, Buddhist, blogger, etc. I'll need to insert all these attributes in a Java class and manage to create methods for handling my overwhelming life
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16140
    
  21

Just to re-iterate an old cancion: A backing bean is NOT a Controller. In JSF, the Controllers are almost entirely pre-written and supplied to you. The backing bean serves as the Model. Action processors are not part of the MVC paradigm, but rather connections from the MVC subsystem to the back-end of the application. MVC has no formal name for that concept (that I know of).

Also, as long as I'm going to be annoying, I strongly recommend putting braces on the if/then clauses. I know they're redundant. They're redundant right up to the moment when you temporarily paste in a "print" statement for debugging or make "one small change". Then suddenly they become the difference between the code doing what it was expected to do and doing something else entirely. I speak as one with many scorch marks on his hands.

I cannot see any fault at all in your samples. Therefore, my best guess is that you have some stale resources in your deployed webapp and thus the code being applied isn't the latest version of the code. This is especially easy to have happen in Tomcat, which will use an old exploded WAR even though there is a newer unexploded WAR of the same name in the webapps deployment directory.


Customer surveys are for companies who didn't pay proper attention to begin with.
Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

Hi Tim, thanks for the answers and recommendations again.

Much to my surprise, this time I think it's not stale information lingering around since it's my common practice to often clean the project within the IDE and immediately clean out the temporary Tomcat folders by hand, the folders "logs", "temp" and "work".

Regarding the recommendations, I've been following some pre-defined patterns prior to my arrival to the team, but naturally, they are not immutable, best practices are always subject to discussion, and you should know that my colleagues do take into account what you say, thanks to your vast experience

Well, the issue is still nebulous, Expression Language exception...

If someone else has any ideas to share, feel free, we are all ears.

Thanks beforehand!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16140
    
  21

It's not enough to clean out the temp and work directories. By default, if you deploy a .war file to Tomcat by copying it to the TOMCAT_HOME/webapps directory, Tomcat will unzip (explode) it and use the exploded copy. Even if you then copy a newer WAR into the webapps directory, it will continue to use the old code. So you need to also delete the exploded WAR directory as well as the other cleanup items you mentioned.
Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

I see, valuable information. Despite that, I'm not deploying my application directly into Tomcat, I'm still creating and debugging, not deploying to a standalone server or servlet container, separately from the Netbeans IDE.

Unless... all this process you mention is performed by the IDE somehow, though it does not look so within my webapps\ROOT folder.

Under my conditions, should I check out what you said some way? Does the IDE do that automatically or is it a process that happens only when we manually deploy a WAR file?

Thanks!
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2853
    
  11

I think Tim is probably right about there being stale code somewhere, but just in case, have you looked farther down your stack trace? Sometimes there can be another listing, prefaced with, "Caused by:", right below the original listing. Let's say one of the agenda in agendaLista was null, then you'd see that ELException and its stack trace followed by "Caused by:", then "NullPointerException", and then another stack trace. You'd see something similar even if agenda wasn't null, but agenda.getRegistroSelecionado() threw some sort of exception.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16140
    
  21

Greg Charles wrote:I think Tim is probably right about there being stale code somewhere, but just in case, have you looked farther down your stack trace? Sometimes there can be another listing, prefaced with, "Caused by:", right below the original listing. Let's say one of the agenda in agendaLista was null, then you'd see that ELException and its stack trace followed by "Caused by:", then "NullPointerException", and then another stack trace. You'd see something similar even if agenda wasn't null, but agenda.getRegistroSelecionado() threw some sort of exception.


Excellent observation! The initial message was "Error reading ...". Meaning that EL probably did find the isRegistroSelecionado() method, but there was an Exception within the method. That kind of stuff doesn't get reported very well, I'm afraid. I usually end up setting breakpoints and occasionally doing walks up and down the stack of the JSF and EL internal methods.
Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

Hi Greg, thanks for the answer!

Unfortunately, the only thing I get is something that, perhaps, cannot even be called a stack trace, those things that appear when we have something view related only, it's only this:

javax.faces.FacesException: javax.el.ELException: /webPages/agenda/agendaPreVenda.xhtml @181,91 rendered="#{agendaPreVendaController.habilitaTransferencia}": Error reading 'habilitaTransferencia' on type br.com.wjnegocios.controller.agenda.AgendaPreVendaController

No information written in red, blue, Java classes and methods being shown, it's only the line above.

I also restarted the IDE additionally to those procedures I've been following, aiming at possibly cleaning something else, but results are still the same.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16140
    
  21

Normally you would get a stack trace, although if you're using that horrible WTP system to run Tomcat, there's no telling where it went.

In cases like this, what I do is put a breakpoint on javax.faces.FacesException: javax.el.ELException for caught and uncaught exceptions so that I can intercept it at the moment it happens. The "cause" part of the Exception object should normally indicate the actual failure.
Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

Tim Holloway wrote:Excellent observation! The initial message was "Error reading ...". Meaning that EL probably did find the isRegistroSelecionado() method, but there was an Exception within the method. That kind of stuff doesn't get reported very well, I'm afraid. I usually end up setting breakpoints and occasionally doing walks up and down the stack of the JSF and EL internal methods.


GOOD NEWS!

I've been doing exactly that, working with breakpoints and checking step by step the flow followed by the compiler. Originally, I knew it was something wrong with the method



but I just did not know exactly what.

The good news is that I noticed, through debugging, that my IDE reported "null" when highlighting



What's the aim of that method? It is to detect if the list is valid for my purposes, to check if it has content and in case so, to return true and assure that my component is rendered.

What have I done?

I noticed that there was another method to check on that, and replacing it, it looks like this:



This other method also returns a boolean and performs exactly what I need.

What was the problem so?

Within my environment, I had I method that I considered appropriate to be used for rendering (it was actually being used somewhere else). However, I was mistaken, and fortunately found another one that performs exactly what I need and now I'm ready to rock.

Guys, thanks for the help, I'll be over here in case of further assistance.
Marcos Silvestri
Ranch Hand

Joined: Dec 06, 2009
Posts: 62

You don't know what happened...

My senior co-worker did not approve of the code



He considered a possible bottleneck, something that could impact performance in the future depending on how large the list could grow. He replaced all that for a more performatic code, without using iterations on a list that interacts with the database, but rather, on a private list attribute used solely for checking if the list is empty or not, without conversation with database.

It was worth the effort with you guys, thanks anyway!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Unidentified exception => javax.faces.FacesException: javax.el.ELException