 (RSS) |
Nitobi User Forums
Nitobi Support Forums
|
Please take our Customer Satisfaction Survey
| View previous topic :: View next topic |
| Author |
Message |
ebuite37
Joined: 19 Mar 2007
Posts: 18
Location: Grand Haven, MI
|
 Posted: Tue Jul 29, 2008 3:40 pm Post subject: curious bug using with Tomcat (solved!) |
 |
|
I've noticed a curious but very significant bug when using the Combo datasourceUrl attribute in Tomcat. The bulk of my testing has been done on Glassfish. Tomcat was tested, but at a smoke test level (my bad!).
The nature of the problem is that the standard EL method expression signature in the TLD file for that attribute parses fine in Glassfish but not in Tomcat. I'm working on the issue, and I will post the fix when I am done.
Last edited by ebuite37 on Mon Aug 04, 2008 1:27 pm; edited 1 time in total |
|
| Back to top |
|
 |
ebuite37
Joined: 19 Mar 2007
Posts: 18
Location: Grand Haven, MI
|
| Posted: Fri Aug 01, 2008 6:33 pm Post subject: Bugfix and minor API change |
|
|
I have been digging through the Tomcat source code (I find that usually ends up taking less time than Googling and sifting through mountains of Mailing lists and blogs), and I found there is a slight difference in the way Tomcat (Jasper) handles Method Expressions.
In putting together the fix, I have decided to move forward with an enhancement I had already planned for this. I brought it up with Nitobi, and they agreed that implementing it now would would be better than later.
Currently, if you have a Method Expression in your JSP (e.g., gethandler="#{mybean.mymethod}) you would have to provide a method in the 'mybean' managed bean using the signature:
| Code: |
java.lang.String methodName(com.nitobi.server.handler.GetHandler,javax.servlet.http.HttpServletRequest) |
I feel that this will hurt us in the long term, since it requires you all to hard code the GetHandler and the HttpServletRequest classes into your method signatures. I also don't like to have to deal with HttpServletRequest objects in the managed beans, since I feel it breaks the MVC paradigm.
Instead the signature is going to be the following:
| Code: |
java.lang.String methodName(com.nitobi.jsf.event.NitobiGetEvent)
|
This would basically turn your managed bean methods into event handler methods, although a true event firing should be a void return (I think the string is required in order to work with both servlet names and method expressions; I'll research it and do a void return if I can) The NtitobiGetEvent object will contain the data you need to fulfill the request. Although this will be a JSF event, it will not be plugged into the event lifecycle, since this event fires only during an AJAX call and not during a full view rebuild. Thus, the full JSF lifecycle will not be (which I think is just fine since we avoid the overhead).
Looking at the JSF 2 plans, I feel that this change will shield your applications from migration aches and pains as far as this is concerned.
I apologize to those who have already implemented code using the old API, and I hope you agree that this is an important enough change to merit a change during the beta phase. Please chime in with your thoughts and concerns!
Regards,
Eric Buitenhuis[/code][/list] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
