• 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

JSF Application Not Working on New Server

 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I originally posted this in the JSF forum and some of the folks there thought I might get better comments in the WebSphere forum. I requested that the post be moved, but that was well over a week ago, so I'm guessing that's not happening. I apologize for the double-post (the original is here).



So I've been given the task of migrating an application that I didn't write in a framework that I'm not familiar with to our new server. Lucky me, but I suspect everyone's been in this boat before.

The framework in question is JSF - I have very little experience with the framework so I know little about how things function. What I do know is that this application appears to be using MyFaces 1.1.4 (according to the jar file in WEB-INF/lib, anyway). I also know that, when I deploy the application to our old target environment (WebSphere 6.0), it works fine. If I then deploy the exact same code to our new target environment (WebSphere 6.1), it fails. The particularly frustrating part is that I have no indication as to why it's failing; there are no warnings or error messages. It seems that, whenever I reach a JSP tag such as:



It simply doesn't resolve. This should hit a backing bean named "test" and pull out the value for lastName, correct? Rather, it does nothing at all. The backing bean is never instantiated (I can see that the constructor is not being invoked) and these calls in the JSP seem to be simply ignored. Like I said, it's not giving me an error when it tries to evaluate them. Rather, they don't seem to get evaluated, at all.

The end result is that, in the old environment (WAS 6.0), I get a page that looks like this (with my own text inserted for testing purposes):



If I generate that same page in WAS 6.1, I get this:



Any ideas about this? Like I said, I'm not horribly well versed in JSF, but this seems to be some issue with JSF and WebSphere 6.1, rather than the code, so I'm gravitating toward explanations involving the jar files I'm using or what order they're being loaded, but I haven't been able to find a solution. Any thoughts from the community? I've been pulling my hair out over this one for some time now and just not getting anywhere.

Thanks,
Corey
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm now wondering if there are conflicting class files on the WebSphere classpath.

MyFaces is one implementation. I think WebSphere 6.1 might have its own JSF implementation somewhere up on its classpath. I don't think WebSphere 6.0 came with JSF libraries packaged with the installation. I have a feeling WebSphere 6.1 and WebSphere 7 do.

What are the Sun JSF jar files called? I think they are jsf-impl.jar and jsf-api.jar, but confirm that. Do a search for *jsf*.jar on your server, and see if any libraries appear on the WebSphere classpath.

You might also change the classloader to parent-last on the war file, rather than parent-first. This will force the loading of the myfaces jar files packaged in the war, rather than the jar files found on the path of a parent classloader. If you do mess around with classloader policies, make sure you document it and change it back when you're done. Changing classpaths can help identify problems, and sometimes it can even solve them, but it can cause problems down the line as well, and it can be one of the most frustrating and confusing issues to troubleshoot if the change is not properly documented and obvious to the people maintaining the applications.

Just a kick at the can. But I've seen it work before.

-Cameron McKenzie
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic