• Post Reply Bookmark Topic Watch Topic
  • New Topic

Upgrading JSF 1.1 to 1.2  RSS feed

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am working on a project that has JSF version 1.1 implementation. Attempting it to upgrade to version 1.2, I replaced jsf-api and jsf-impl JAR files, and also html_basic and jsf_core TLD files. While running the application, I observed that the first managed bean that was accessed was null. Debugging it, I found a custom implementation of com.sun.faces.config.ConfigureListener overriding configure(ServletContext, FacesConfigBean). However, this method is not present in version 1.2. This might be the reason why manage bean is not initializing. Now, the custom version of ConfigureListener combines several faces-config.xml placed at class paths (but not under WEB-INF) and resolving duplicate entries based on precedence (like same managed bean may point to different parent/child classes in each XML). There is some other code written too using classes from jsf-impl, I do not know if it is going to work either.

How can this situation be handled with the consideration of reverting back to 1.1 if 1.2 fails in production for any reason? Also in general, is it a good idea to extend or use jsf-impl classes? Thanks.
 
Java Cowboy
Sheriff
Posts: 16079
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both JSF 1.1 and 1.2 are super-old versions. I doubt if it's worth it to try to upgrade from one super-old version to a slightly newer super-old version.

If you have a very old JSF 1.1 application they I'd either leave it alone if it works good enough, or do a major upgrade to a current version of JSF (Java EE 7 -> JSF 2.2 or Java EE 8 -> JSF 2.3) or rewrite the whole application using a different, more modern web app framework.
 
Saloon Keeper
Posts: 19013
80
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF version 1 (both 1.1 and 1.2) are so old that there are trilobite fossils above them. There is essentially zero support for either of them at this point - and probably has been for more than 5 years. Like I said, JSF1 is really, really old. Moving from a platform with extreme technical debt to one with merely very very deep technical debt is false economy.

Also, based on what I'm hearing, the original app probably wasn't well-written to begin with. Even in JSF1 I believe that you could could distribute segments of faces-config.xml without having to resort to custom mods to the JSF infrastructure.

The #1 rule for JSF has always been that the more JSF-specific code there is in your webapp, the more likely it is that you're not doing it right.

So I second Jesper's recommendations.
 
Taranjeet Bagga
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Jesper and Tim for the response. I'll have to check if a major upgrade can be done. Because this is a part of huge enterprise application, so a minor upgrade would be desired. But that too looks complicated. My other question was - "Also in general, is it a good idea to extend or use jsf-impl classes?" or we should just use jsf-api classes in custom code?
 
Tim Holloway
Saloon Keeper
Posts: 19013
80
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Once a product has passed end-of-life by this many years, there's no such thing as a "minor upgrade".

No, you should not customize JSF's classes. For one thing, MAJOR architectural differences exist between the internals of JSF1 and JSF2. It's akin to digging for water at the bottom of a dry well. While thunderclouds are forming overhead.

Remember what I said earlier - the more JSF-specific your code is, the more likely it is that you're doing it wrong. And on a version that old, there aren't going to be many people around who can help you.

I have been working with JSF since its initial version (about 2006) and almost the only JSF-specific code I've ever written either used only the JSF model classes (DataModel and SelectItem) or invoked a stock support class I write calles JSFUtils which internally uses FacesContext to obtain the HttpRequest object for when I need to invoke J2EE container security and get the user ID. That way my JSF code is insulated from breakage and I can swap JSFUtils out when doing offline testing.

I did do one component that went deeper - I wrote a custom JSF tag to interface with Google Maps. It required a major rewrite when JSF2 came out. JSF2 makes it less likely that you'd need binary code for custom tags, though, since there are better ways now.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!