[JBoss Seam] - SelectItems with noSelectionLabel not resetting to null on s
by james_haysï¼ mac.com
I've pulled down the latest successful build of Seam from August 17th, but am still having issues with this particular drop down list. When the page loads, I choose an item from the list and submit the form. Everything performs as expected. The next time I load the page, the previous item is already selected, as expected since I'm running inside a conversation. When I go back and choose "-- Select --" from the dropdown list, which is the noSelectionLabel, my SFSB field is not reset to null, but retains its old value.
Any suggestions on this? Do you want me to submit this as a bug?
| <h:outputLabel value="Requesting Strat. Unit:" for="StrategicUnit"/>
| <h:selectOneMenu id="StrategicUnit" value="#{search.strategicUnit}">
| <s:selectItems var="strategicUnit" value="#{strategicUnitsList}"
| label="#{strategicUnit.title}" noSelectionLabel="-- Select --"/>
| <s:convertEntity/>
| </h:selectOneMenu>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075965#4075965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075965
18Â years, 10Â months
[EJB 3.0] - Complex query generated by 4 non-lazy relations
by icordoba
Hi there,
i have a typical Portal-user-role-component structure, with obvious relations. I have to configure these relations as eager because I need to use entities in the client side (JSP page). My problem is that a very complex and slow query is generated with thousand "combinations" of results, just to load a portal. I've seen that changing eager to lazy in the relations makes the query be much simpler, as lazy relations are not loaded.
Can I configure Hibernate / JBoss EJB3 to avoid this complex query. Login procedure takes about 20 seconds because of this overhead.
thanks for any help.
| select portal0_.id as id347_5_, portal0_.locale as locale347_5_, portal0_.description as descript3_347_5_, portal0_.requiresSignupConfirmation as requires4_347_5_, portal0_.newUserNotification as newUserN5_347_5_, portal0_.sessionRememberDays as sessionR6_347_5_, portal0_.userSelfSignup as userSelf7_347_5_, portal0_.homeurl as homeurl347_5_, portal0_.lastAccessed as lastAcce9_347_5_, properties1_.portal_id as portal4_7_, properties1_.pkey as pkey7_, properties1_.pkey as pkey348_0_, properties1_.name as name348_0_, properties1_.value as value348_0_, properties1_.portal_id as portal4_348_0_, actions2_.Portal_id as Portal1_8_, component3_.className as actions2_8_, component3_.className as className346_1_, component3_.admin as admin346_1_, component3_.guest as guest346_1_, roles4_.portal_id as portal6_9_, roles4_.pkey as pkey9_, roles4_.pkey as pkey353_2_, roles4_.name as name353_2_, roles4_.description as descript3_353_2_, roles4_.portal_id as portal6_353_2_, roles4_.loginText as loginText353_2_, roles4_.newUserRole as newUserR5_353_2_, actions5_.Role_pkey as Role1_10_, component6_.className as actions2_10_, component6_.className as className346_3_, component6_.admin as admin346_3_, component6_.guest as guest346_3_, extrauserd7_.portal_id as portal7_11_, extrauserd7_.pkey as pkey11_, extrauserd7_.pkey as pkey352_4_, extrauserd7_.name as name352_4_, extrauserd7_.defaultValue as defaultV3_352_4_, extrauserd7_.options as options352_4_, extrauserd7_.required as required352_4_, extrauserd7_.portal_id as portal7_352_4_, extrauserd7_.publicField as publicFi6_352_4_ from Portal portal0_ left outer join Property properties1_ on portal0_.id=properties1_.portal_id left outer join Portal_Component actions2_ on portal0_.id=actions2_.Portal_id left outer join Component component3_ on actions2_.actions_className=component3_.className left outer join Role roles4_ on portal0_.id=roles4_.portal_id left outer join Role_Component actions5_ on roles4_.pkey=actions5_.Role_pkey left outer join Component component6_ on actions5_.actions_className=component6_.className left outer join ExtraUserdataField extrauserd7_ on portal0_.id=extrauserd7_.portal_id where portal0_.id=?
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075964#4075964
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075964
18Â years, 10Â months
[JBossCache] - Re: Could this be deadlock when modifying TreeCache
by ramdas
"manik.surtani(a)jboss.com" wrote : Each cache instance would create 1 channel (unless you're using a multiplexer, but that's a different story)
Increasing the FC max_credits value to 20 million does seemed to have helped stabilize the application environment... we went through more than 2 weeks without an application outage.. but then we had a failure again - and on taking the thread dump of the JBoss AS , it looked very similar to what started this discussion.
If i understand how FC works, increasing the value of FC max_credits helps increase the threshold for any server in the cluster from blocking in the event of another slower member in the cluster not responding, right? Was attempting to better understand why i would start seeing blocked FC jgroups threads after having increased the value of FC max_credits.
Thanks
Ramdas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075959#4075959
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075959
18Â years, 10Â months