[JBoss Seam] - Handling input too large for an integer field using SEAM...
by jkrupka
I've started tweaking the seam app generated by the eclipse/hibernate tools, and feeling out how seam/jsf work. I noticed that if you key in a non integer value, or a number higher than (2^31)-1 into the results per page field and try submitting it the form, either to find the results, clear the form, or switch pages, it just reloads the same page. I believe this is because this is due to the failure to convert that value to an int, but no error is being thrown, to the screen or the logs. That field is tied to the pageSize attribute of the session bean. The method that is called when I hit that button is never hit.
Granted there is no reason why someone would enter that high of a number, or a non int into a page size field but I've seen people do stupider things. That said, where exactly is the error happening? Is the only solution to treat it as a String variable, and do the conversion and error handling myself?
Thanks!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961357#3961357
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961357
20 years, 1 month
[EJB 3.0] - Re: Problem using SequenceGenerator
by bryan_castillo
I don't think my problem is database related.
Arno, did you see if the next value of your postgres sequence corresponded to the value actually inserted?
I launched jboss in debug mode and attached eclipse remotely to it and found the hibernate class which is applying modifications to the value returned from the database sequence.
The generated id is being generated by org.hibernate.id.SequenceHiLoGenerator. Here is the method.
public synchronized Serializable generate(SessionImplementor session, Object obj)
| throws HibernateException {
| if (maxLo < 1) {
| //keep the behavior consistent even for boundary usages
| long val = ( (Number) super.generate(session, obj) ).longValue();
| if (val == 0) val = ( (Number) super.generate(session, obj) ).longValue();
| return IdentifierGeneratorFactory.createNumber( val, returnClass );
| }
| if ( lo>maxLo ) {
| long hival = ( (Number) super.generate(session, obj) ).longValue();
| lo = (hival == 0) ? 1 : 0;
| hi = hival * ( maxLo+1 );
| if ( log.isDebugEnabled() )
| log.debug("new hi value: " + hival);
| }
|
| return IdentifierGeneratorFactory.createNumber( hi + lo++, returnClass );
| }
I would like to have the id, generated by org.hibernate.id.SequenceGenerator instead of org.hibernate.id.SequenceHiLoGenerator. Is there a way to specify the class which should be used as the generator?
I read some of the comments for both of these generators and it looks like the HiLo version is used for performance. I believe it is able to reserve chunks of sequence numbers at a time. But I was trying to created entity beans for an existing database and still fit the same sequence/id usage pattern of the old code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961349#3961349
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961349
20 years, 1 month
[JBoss Seam] - Re: Progress
by chane
"gavin.king(a)jboss.com" wrote :
| * deprecation of @Conversational(ifNotBeginOutcome) in favor of no-conversation-view-id
I just started to use 1.1 in cvs and I am wondering about the reason for deprecating @Conversational. I don't use pages.xml very much and would prefer to have this functionality on my SFSB rather than in a seperate file.
I am all for choices; however, I am just curious about the reason for deprecating a choice. I could be missing the bigger picture with respect to pages.xml; It seems like one more place to remember to look in for how a given component works by being forced to use pages.xml.
Thanks,
Chris....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3961348#3961348
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3961348
20 years, 1 month