Peter Goldstein

A couple of quick comments.

First, I'm not quite sure how you're doing your i18n - your description doesn't have enough detail. I suspect you may have some problems there, in part because I don't see a discussion of ViewHandlers in your posts. See the postings here -

i18n posting

- for a basic discussion of how to do i18n in JSF apps.

Second, this may very well be a character encoding issue. There's a lack of control by the developer over the response character encoding in JSF 1.1. This has been improved in JSF 1.2 with the addition of the calculateCharacterEncoding(FacesContext) method to ViewHandler, but the problem remains in JSF 1.1 apps or JSF 1.2 apps that don't use this new functionality. A discussion of the default response character encoding algorithm in JSF 1.2 apps can be found here -

View Handler javadoc

In MyFaces/JSP based apps I believe the response encoding is basically just copied from the request encoding. That appears to be the default behavior in Facelets based apps (see FaceletViewHandler).

If everything here is ok - you're localizing correctly and the character encodings of the request and response are both UTF-8 - it's time to check your JVM's character encoding and make sure that it's set to UTF-8 so it can properly read your bundles. You can configure the JVM's character encoding - Google for details.

As part of your debugging process you can use a backing bean to print out Strings from the bundle to your log, to confirm that everything is kosher before the String is written out to the response.

Anyway, those are the places I'd start looking for problems. This post should give you a few things to investigate. Hope that helps.

Regards,

Peter

Jarno,

I see a similar behavior and I'm not sure of the underlying cause. I can see some suspicious lines in the FaceletsViewHandler (I'm using Facelets) that lead me to suspect that the request character encoding is simply copied to the response writer. This is in JSF 1.1.

However if you're able to upgrade to JSF 1.2 there may be a solution. In 1.2 the ViewHandler interface includes a calculateCharacterEncoding(FacesContext) method. I'm assuming that this works similarly to the calculateLocale(FacesContext) in JSF 1.1. In which case you should be able to force the character encoding to UTF-8.

Not sure if that helps, but it seems interesting.

Regards,

Peter

Ranjith,

I'm fairly confused by your comments in your post.

First, my issue was a result of a class collision between two different sets of MyFaces jars - each of which provided the JSF API and implementation. You've removed the jsf-libs subdirectory in Tomcat (which I really wouldn't recommend unless you've got a compelling reason). Where is your JSF implementation in your scenario? Did you add the JSF libs to your WEB-INF/lib? Your post makes this very unclear.

Second, you absolutely must have a listener specified in your web.xml. The exact listener class depends on which JSF implementation you're using. Assuming you're using JSF-RI, you need to include this:

<listener>
<listener-class>com.sun.faces.config.ConfigListener</listener-class>
</listener>

If MyFaces, you need to put back the listener segment you removed. Other implementations have different listener classes.

From the stack trace you posted it does appear that you've got the FacesServlet running and the URL mapping set up correctly. My first suspect would be the lack of a listener-class entry.

Anyway, if you can clarify some of the above - namely the implementation you're using, where the JSF classes are packaged, etc. - that would be helpful in resolving your problem.

Hope that's helpful.

Regards,

Peter

I'm having a JSF issue that seems (at least from the stack trace) to have its root cause in a JBoss class loader issue. I was hoping someone on this list might be able to help shed some light on the problem.

I'm running JBoss 4.0.3SP1, with the EJB3 final draft upgrade (RC5?) and a version of MyFaces that's been upgraded to 1.1.1. I'm using Facelets 1.0.3.

I have a session scoped bean defined in my managed bean list in faces-config.xml. It's defined using the XML snippet:

<managed-bean>
<description>Used for managing localized dates for weeks.</description>
<managed-bean-name>weekBean</managed-bean-name>
<managed-bean-class>us.emotive.challengeme.components.program.WeekBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

Now, I should be able to invoke the managed bean creation facility from Java code. This facility should check for a pre-existing bean with that name, and create a new WeekBean if one doesn't already exist in scope.

I call this facility using a code snippet like:

FacesContext facesContext = FacesContext.getCurrentInstance();
ValueBinding vb = facesContext.getApplication().createValueBinding("#{weekBean}");
WeekBean weekBean =
(WeekBean)vb.getValue(facesContext);

I would expect this to yield a WeekBean. Instead I get an exception and a long stack trace. In the trace I see this:

Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: us.emotive.challengeme.components.program.WeekBean
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:198)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:475)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:377)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

This is odd because:

i) If I use a reference to weekBean in a JSF/Facelets page, as opposed to a backing bean, everything gets instantiated fine.
ii) I can alter the above code to look like:

FacesContext facesContext = FacesContext.getCurrentInstance();
ValueBinding vb = facesContext.getApplication().createValueBinding("#{sessionScope.weekBean}");
WeekBean weekBean =
(WeekBean)vb.getValue(facesContext);
if (weekBean == null) {
weekBean = new WeekBean();
vb.setValue(facesContext, weekBean);
}

and all the classes get loaded and instantiated just fine.

I'm suspecting a bug, but considering the number of different technologies involved I'm not sure where. I was hoping someone on this list might have a clue, and help me cut short the process of swapping in and out different components.

Has anyone seen this before? Is this a known issue? Anyone know whether this is a bug or I'm doing something wrong? Any guidance would be appreciated.

There are rules when including JSF pages that need to be followed.

i) The "top level" JSF page must have an <f:view> tag surrounding all JSF tags being used. Since you seem to be mixing and matching simple JSPs and JSF pages I'm not clear if that will always be the case in what you describe

ii) The content of the included JSF (faces) page fragments need to be surrounded with <f:subview> tags. These <f:subview> tags can either be in the included page or surround the include statement in the including page. Either is fine.

iii) All non JSF tags and content in the included JSF (faces) page fragments need to be surrounded by <f:verbatim> tags.

If you're using JSF with a JSP renderer, make sure you're following all of these rules.

If you're building a system with lots of includes and you're using JSF, I'd probably suggest that you consider Facelets. It eliminates requirement (iii) and has expanded support for templating and dynamic inclusion. It does however introduce a few other requirements, most notably that your pages be strict XML. I have been pretty happy with Facelets' features and performance, but your mileage may vary.

--Peter

I've resolved this problem, and am going to post for the future edification of anyone who may run into something similar.

This turned out to be a build/class loader issue. My build was copying the MyFaces jar files from the JBoss jsf-libs directory into the WEB-INF/lib for my application. This appears to have caused some kind of class loader collision, because my pages all rendered fine and one could access the FacesContext from them. However the backing beans stored in my jar file appear to be using a version of the FacesContext class loaded from the WEB-INF/lib directory. Despite being the exact same library files, the class loader was loading them again (presumably because of the web application class loading rules) and hence I was seeing a different version of the class.

So, in short, if you see a null FacesContext in backing beans on JBoss check your WEB-INF/lib and make sure you're not including any of the MyFaces jars.

Ernest,

Happy to help.

For stuff like this I generally recommend going straight to the source. So if you want to know more about ResourceBundles, check out the javadoc on Sun's site - http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html .

You will see that there are only a couple of abstract methods that you need to implement if you want to extend this class. There are a couple of examples in the Javadoc (although I think they may be missing the getKeys() method).

If you download the source distribution for the Java libraries from Sun, you should be able to see how the ListResourceBundle and PropertyResourceBundle classes are implemented - they're pretty simple.

If you're not familiar with the Singleton pattern I mentioned, I'd recommend that you read the "Gang of Four" authored book, Design Patterns. They're generally good things to know, as a good deal of Java development is an implementation of one or more of these patterns (although overdoing the patterns is often a risk). There are also quite a few pages on the web describing Singleton use in Java apps - a Google search should serve you well here.

Anyway, good luck with your project.

--Peter

Ernest,

I think you may be underestimating the humble ResourceBundle. When most people think of ResourceBundles they think of the properties files underlying PropertyResourceBundle instances. Things like:

MyResources_en.properties

mother=mother
father=father

MyResources_es.properties

mother=madre
father=padre

But there's a lot more to it than that. In short, ResourceBundles are class instances, so you can write a set of ResourceBundles that are backed by just about anything (including database data). The main questions that arises in these implementations are whether the data in question is dynamic and how often refreshes may be required.

For the case of database backed data, I'd define a set of ResourceBundle classes that delegate to a singleton for each group of ResourceBundles. The singleton is responsible for loading the data from the database and refreshing the data either on request or on a timed schedule.

If the data is static, then it's pretty much trivial and I'd strongly recommend this approach. You don't even have to synchronize access to the cache in the singleton.

If the data is somewhat dynamic, then I'd still recommend that you consider this sort of approach, as it means that you can automatically plug into a pre-built i18n system, rather than creating your own. Especially if the set of keys to be accessed is fixed, even if the backing values aren't.

If you need to change data then you can persist the dynamic data using your favorite persistence mechanism, and then refresh the ResourceBundle singleton. Or, you can refresh the singleton cache directly, in a manner similar to the Gerardo's TreeMap idea.

Feeds and such can be handled with timed refreshes of the bundle values.

In any case, it might be worth thinking about. If it's not your cup of tea, then Gerardo's proposal sounds like it could be very effective.

--Peter

Ernest,

Reading your post my first question is why does all of this need to be in the database?

If you're dealing with fixed data - that is, large lists of text items that are translated before application deployment - it would seem more efficient to store the data in the resource bundles themselves. Then you would store the resource bundle keys in the database column, and have the presentation tier do the resource bundle lookup.

So is there a particular reason why have you chosen to store all of these strings in the database?

In a managed bean situation you're reallly not supposed to have constructors that take arbitrary arguments. The container is supposed to manage bean creation which works best if the constructor is simple and standardized - it simplifies the configuration.

Arguments that would be in a constructor are typically passed into the managed bean using the managed-property elements in faces-config.xml, which invoke the appropriate setters. I'm hard pressed to come up with a real-life backing bean situation where you couldn't replace constructor arguments with use of managed properties.

That all said, it would certainly be possible to create a bean in Java code (say, inside the methods of another bean) that has a constructor that takes arbitrary arguments. You could then bind this bean instance into the framework using the ValueBinding API. I'm not sure to what extent this bean would then be "managed", but it may accomplish what you're looking for. But I would very much recommend that you investigate managed properties before going this route.

Dennis, I didn't look closely enough at your original post. I don't think the problem is that JSF is doing something with the list, it's that you've got an open Iterator and are using the Collection methods rather than Iterator methods to remove the item.

Try replacing otherItems.remove(o) with it.remove(o) in your original solution. That may very well solve your problem.

That would explain why you're encountering the same problem with the copied List, which the underlying code can't be manipulating.

Why don't you make a new List that is a copy of the old one, remove the item from the copy, and set the new List in the bean? I think that should work as a workaround.

Have you followed the requirement that all non-JSF tags and content be wrapped in <f:verbatim> tags in your included JSP? That might be your issue, but I can't tell without examining the included page.

Tim, thank you for the reply, but I'm not sure I understand it.

The login bean is being invoked from a JSP that is processed by the FacesServlet. Specifically I've got a login.jsp, which is invoked from a browser using a URL (...)/login.faces, and the FacesServlet is configured to handle all URLs with a .faces extension.

As far as I can tell, the FacesServlet should be the target for this POST request - the submit button is created by a JSF tag, and hence I would assume a submission runs through the FacesServlet. Moreover, the navigation IS being handled by the configuration in faces-config.xml, so a FacesContext has to get created at some point or another. Also, I'm not accessing the bean directly, but rather through a JSF tag as described in my post.

Given the above, I'm not sure I understand your reply. Any clarification would be appreciated.

I'm having a somewhat unexpected problem with a null value returned by FacesContext.getCurrentInstance() inside a managed bean method invoked by a command button. Specifically, I have a login form with a button tag like this:

<h:commandButton action="#{authenticationBean.login}" title="#{bundle.SubmitButtonTitle}" value="Submit"/>

I have an authenticationBean mapped in my faces-config.xml like this:

<managed-bean> <description>Used for managing user authentication.</description> <managed-bean-name>authenticationBean</managed-bean-name> <managed-bean-class>com.pmg.AuthenticationBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean>

and a navigation rule that looks like this:

<navigation-rule> <from-view-id>/login.jsp</from-view-id> <navigation-case> <from-outcome>success</from-outcome> <to-view-id>/protected/testParent.jsp</to-view-id> </navigation-case> <navigation-case> <from-outcome>failure</from-outcome> <to-view-id>/login.jsp</to-view-id> </navigation-case> </navigation-rule> </faces-config>

The login method starts with:

public String login() { FacesContext facesContext = FacesContext.getCurrentInstance(); ...

Now, this facesContext variable is set to null, and I don't understand how that's possible. Not only that, but if I comment out all calls to facesContext, then the navigation works fine and I'm directed to the intended target page.

This is all running on JBoss 4.0.3SP1

Anyone have any idea what the problem might be? I'm surprised by this, and don't really have any good idea how to debug the underlying problem. Any help would be greatly appreciated.