[JBoss Seam] - noSelectionLabel s:selectItems NumberFormatException
by dave.rogers
When I use the 'noSelectionLabel' option on a s:selectItems tag inside a ice:selectOneMenu component which has a 'required="true"' attribute I am getting an error.
The behaviour is correct except when I attempt to submit the form when the noSelectionLabel option is chosen. This should display a validation message, but instead I receive the following error...
11:48:22,708 ERROR [[Blocking Servlet]] Servlet.service() for servlet Blocking Servlet threw exception
| java.lang.NumberFormatException: For input string: "Select..."
| at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
| at java.lang.Integer.parseInt(Integer.java:447)
| at java.lang.Integer.<init>(Integer.java:620)
| at org.jboss.seam.ui.EntityConverter.getAsObject(EntityConverter.java:197)
| at org.jboss.seam.ui.PrioritizableConverter.getAsObject(PrioritizableConverter.java:61)
| at org.jboss.seam.ui.ConverterChain.getAsObject(ConverterChain.java:105)
| at com.icesoft.faces.renderkit.dom_html_basic.DomBasicInputRenderer.getConvertedValue(DomBasicInputRenderer.java:97)
| at com.icesoft.faces.renderkit.dom_html_basic.MenuRenderer.getConvertedValue(MenuRenderer.java:129)
| at javax.faces.component.UIInput.getConvertedValue(UIInput.java:395)
| at javax.faces.component.UIInput.validate(UIInput.java:349)
| at com.icesoft.faces.component.ext.HtmlSelectOneMenu.validate(HtmlSelectOneMenu.java:418)
| at javax.faces.component.UIInput.processValidators(UIInput.java:183)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIForm.processValidators(UIForm.java:70)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
| at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:146)
| at org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:262)
| at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
| at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.renderCyclePartial(BlockingServlet.java:473)
| at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.receiveUpdates(BlockingServlet.java:442)
| at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.executeRequest(BlockingServlet.java:324)
| at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:186)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at twp.filter.RoleFilter.doFilter(RoleFilter.java:46)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at twp.filter.UtilFilter.doFilter(UtilFilter.java:44)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:595)
Evidently seam is attempting to parse the noSelectionLabel as an entity ID, which is incorrect.
The rendering of the selection list seems OK when looking at the source code of the rendered page...
<select class="iceSelect" id="jobCreateForm:jobType" name="jobCreateForm:jobType" onblur="setFocus('');" onchange="setFocus('');iceSubmitPartial(form, this, event);" onfocus="setFocus(this.id);" size="1" style="">
| <option value="">
| Select...
| </option>
| <option value="0">
| Capital 2006 Rates
| </option>
| <option value="1">
| Capital 2007 Rates
| </option>
| <option value="2">
| Capital Super 9
| </option>
| <option value="3">
| Laings Job
| </option>
| <option value="4">
| Mains
| </option>
| <option value="5">
| Maintenance
| </option>
| <option value="6">
| Rechargeable
| </option>
| <option value="7">
| Requisitioned
| </option>
| </select>
For referencem, my JSF code is...
<ice:selectOneMenu required="true" value="#{jobCreator.job.jobType}" partialSubmit="true" id="jobType">
| <s:selectItems hideNoSelectionLabel="true" noSelectionLabel="Select..." value="#{selectJobTypes.resultList}" var="jobType" label="#{jobType.name}"/>
| <s:convertEntity entityClass="twp.pojo.JobType"/>
| <ice:message for="jobType"/>
| </ice:selectOneMenu>
the relevant java code is (in JobCreator.java)...
public List<Partner> getPossibleContractors(){
| if(job.getJobType()==null)
| return new ArrayList<Partner>();
| List<Partner> possibleContractors = em.createNamedQuery(
| "possibleContractors")
| .setParameter("jobType", job.getJobType().getJobTypeId())
| .getResultList();
| return possibleContractors;
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044638#4044638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044638
19 years, 1 month
[JBossCache] - Re: TreeCache CacheLoader Issue
by robnor
I tried to change this.
I now have major problem with node locking errors.
It seems it cannot cope with highfrequency updates?
I have an Ojbect (ImportTracker) that holds multiple objects (BatchTracker). The ImportTracker holds all the BatchTrackers, the BatchTracker holds data about the import of a specific Batch.
Further I have a DistributionManager. The Batch is productified and distributed to several hubs. The distributionManager is the one responsible for keeping track of the distribution.
A Batch, can be productified into several different products. There are multiple hubs requesting different kinds of products. The Distributionmanager keeps track that the Batch and its products are being delivered to the hubs requesting the producttype. The batchimport is not done until all producttypes has been delivered to all hubs.
Then we may have say 3 machines dedicated to import all working on a local cache which is persisted in a single database (to avoid overwrite they store objects in different nodes for example /import/<host1>/importTracker).
This will make the application to make many many put to the persistent storage.
Can get around nodelocking? or perhaps jbosscache is not the tool I should use?
Anyway, your comment solved the issue regarding not "flushing" the inmemory data to persistent storage.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4044635#4044635
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4044635
19 years, 1 month