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

[Marcos Silvestri]

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:
--------

<h:selectBooleanCheckbox value="#{row.registroSelecionado}">
	<a4j:support reRender="pnlTransferencia" event="onclick" limitToList="true"/>
</h:selectBooleanCheckbox>

<a4j:outputPanel id="pnlTransferencia">
        
	<a4j:outputPanel rendered="#{agendaPreVendaController.habilitaTransferencia}">

		<a4j:region renderRegionOnly="true">
			<h:inputText id="txtPesqUsernameParaTransferencia"
						 value="#{agendaPreVendaController.agendaParametrosPesquisa.usuarioAgenda}"
						 styleClass="field" size="30" maxlength="30"/>
			<rich:suggestionbox id="sugPesqUsernameParaTransferencia" for="txtPesqUsernameParaTransferencia"
								suggestionAction="#{agendaPreVendaController.usernameSugestao}"
								var="result" fetchValue="#{result.username}"
								width="175" height="200"
								nothingLabel="Nenhum usuário encontrado">
			</rich:suggestionbox>
		</a4j:region>
	
		<h:commandButton value="Confirmar Transferência"/>	

	</a4j:outputPanel>
	
</a4j:outputPanel>

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

private List<Agenda> agendaLista;

public boolean isHabilitaTransferencia() {
	if (this.agendaLista != null)
		for (Agenda agenda : this.agendaLista)
			if (agenda.getRegistroSelecionado()) 
				return true;
	return false;
}

Through debugging, I know the exception is thrown when

if (agenda.getRegistroSelecionado())

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

isHabilitaTransferencia()

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!

[Tim Holloway]

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.

[Marcos Silvestri]

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]

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]

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]

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]

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]

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]

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]

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

isRegistroSelecionado()

but I just did not know exactly what.

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

(agenda.isRegistroSelecionado())

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:

if (agenda.isAgendaValida())

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]

You don't know what happened...

My senior co-worker did not approve of the code

public boolean isHabilitaTransferencia() {  
    if (this.agendaLista != null)  
        for (Agenda agenda : this.agendaLista)  
            if (agenda.isAgendaValida())   
                return true;  
    return false;  
}  

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!