Announcement

**Blama** · 19 Feb 2015, 01:23

Hi fanie1980,

just as suggestion: Did you empty the cache? For me on my Tomcat-only dev system I have problems with cached DS-definitions.
Of course this does not explain what you are seeing (errors after an amount of time), but generally speaking something seems weird or mixed up here.

Regarding your .ds.xml:
Did you see FieldType.MODIFIERTIMESTAMP and FieldType.CREATORTIMESTAMP? Might be of use for you.

Best regards,
Blama

**fanie1980** · 24 Feb 2015, 02:37

Originally posted by Blama View Post

Hi fanie1980,

just as suggestion: Did you empty the cache? For me on my Tomcat-only dev system I have problems with cached DS-definitions.
Of course this does not explain what you are seeing (errors after an amount of time), but generally speaking something seems weird or mixed up here.

Regarding your .ds.xml:
Did you see FieldType.MODIFIERTIMESTAMP and FieldType.CREATORTIMESTAMP? Might be of use for you.

Best regards,
Blama

Thank you Blama,

Am I correct in saying that the FieldType.CREATORTIMESTAMP and FieldType.MODIFIERTIMESTAMP will show me when ds.xml files were created and changed, thus allowing me to compare whether or not Tomcat is using a cached file. Is that what you use it for?

In addition to my previous post I have also found that this only happens on one tomcat instance. We run two instances with Load Balancing. The busiest instance seems to be the first to cause the validation to fail.

If I view the datasources being downloaded I can clearly see the field showing a length of a 1000, but I am still restricted to only 60 characters on the client validation.

Please guys, need some help.

**Blama** · 24 Feb 2015, 02:51

Hi fanie1980,

FieldType.CREATORTIMESTAMP and FieldType.MODIFIERTIMESTAMP are unrelated to your problem and just a more declarative solution to your "customUpdateExpression="GETDATE()"".

Regarding the bug I can't help. Is for sure the same war deployed on both instances?

I find it very confusing that you get both
- Must be no more than 60 characters
- Must be no more than 1000 characters
validation errors. This really seems wrong. But again, I can't help.

Best regards,
Blama

**fanie1980** · 24 Feb 2015, 05:18

Yes the same war is deployed to both instances.

We have now narrowed it down to the following:
In tomcat, LENGTH validation fails on ALL TextItems (TextItems, TextAreaItems, RichTextItems) after a couple of days.

For some reason all the length fields defined in the datasource fields are ignored and replaced by a default length validator of 60.

The only way we have been able to force the correct length to be used is to remove the length attribute from the datasource field (Memo, below).

Code:

<DataSource 
	schema="dbo"
	dbName="Nova"
	tableName="DxMemo"
	ID="DxMemo"
	dataSourceVersion="1"
	generatedBy="v8.2p_2012-09-17/EVAL Deployment 2012-09-17"
	serverType="sql"
	requiresAuthentication="true"
	logActionHistory="true"
>
	<fields>
		<field primaryKey="true" name="IDMEMO" type="sequence" hidden="true"></field>
		<field name="IDGROUP" type="integer" required="true" hidden="true"></field>
		<field name="IDRESERVATION" type="integer" required="true" title="Reservation"></field>
		
		<field name="IDITINERARY" type="integer" foreignKey="DxItinerary.IDITINERARY" hidden="true" required="false"></field>
		
		<field name="Memo" type="text" required="true"></field>
		<field name="CheckInFlag" type="boolean"></field>
		<field name="CheckOutFlag" type="boolean"></field>
		<field name="AllocateFlag" type="boolean"></field>
		<field name="CancelFlag" type="boolean"></field>
		<field name="HistoryFlag" type="boolean"></field>
		<field name="CreateDT" type="datetime" customInsertExpression="GETDATE()" hidden="true"></field>
		<field name="CreateIDEMPLOYEE" type="integer" hidden="true"></field>
		<field name="ChangeDT" type="datetime" canEdit="false" customUpdateExpression="GETDATE()" hidden="true"></field>
		<field name="ChangeIDEMPLOYEE" type="integer" hidden="true"></field>
	</fields>
</DataSource>

And to then define an implicit Length Range Validator (http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/serverds/DataSourceField.html#length)

Please can Isomorphic help, at this stage none of our TextItems are using the validation as determined by the datasource ds.xml

**fanie1980** · 26 Feb 2015, 23:27

It is now 3 days since last post and validation has stopped working again. All TextItem validation within my application has stopped working and defaulted to length 60.

At this stage smartgwt is unstable and cannot be used further. Maybe we should halt all development as the integrity of our application is compromised.

Could this be caused by Tomcat and Apache Load balancing? Could it have something to do with Tomcat? I do not see how because validation is happening on the client side.

**Isomorphic** · 4 Mar 2015, 10:13

We have never seen an issue like this, or had other reports of it, and it seems (very) unlikely to be a result of a framework bug, given how it's such a specific strange symptom which we have never seen elsewhere, and is intermittent / only occurs on one particular deployment that you're aware of.

The validation failure would be coming from SmartGWT, its true. It sounds like perhaps you have some application code which is in some strange circumstances applying an additional validator to the field in question with the shorter length (60).

Given that you have no way to reproduce the problem outside of one particular deployment, there's not much we can suggest. Perhaps there is some pattern of usage within the app which causes this bad state which would lead you to an idea of the cause.
If you can show us a way to reliably reproduce the problem and believe it to be a framework bug rather than an issue with your application code, please feel free to post a test case.

Regards
Isomorphic Software

**fanie1980** · 16 Mar 2015, 04:10

Length Validation in Tomcat

The issue is very strange, after a few weeks we are no closer.

It certainly seems like a deployment (in Tomcat) issue but we can now confirm that it does not happen in Smartgwt 3.0p. Only since we upgraded has this started.

What we can see in Tomcat is that once the app is deployed it creates a copy in the temp folder (0-myapp), after a few days tomcat creates a second copy (1-myapp). Immediately after this happens the validation (only length validation on text fields) starts failing. We need to clear all the tomcat cache files and restart. And the process starts all over again.

We have also noticed that it does not only happen to data bound components. Any field that does not comply to the length validator fails.

We have also noticed that this happens on two very separate projects, both running the same version and two separate machines. So it is no longer an isolated issue.

In Power 5.0 release notes you make mention of this:

Code:

Modified behavior for fields with specified length attribute. We now automatically create and apply a lengthRange
validator for fields with a specified length. This is enforced on the client and on the server
(for server-backed dataSources).
Previously we would always enforce the length limit within TextItem and TextAreaItem editors by refusing to allow
the user to enter more characters than the specified length. This has now been made configurable via the new
"enforceLength" attribute and has been disabled by default for TextAreaItems where it is typically confusing for us
to limit entry of long strings.
Also fixed a bug in how we limit the length of user-entered strings. Previously the user could put focus at the
beginning of the value in a TextItem which had already reached the maximum allowable length, and type a character,
and the new value would accept the typed character and drop characters from the end of the string to maintain the
correct length limit. Now we simply reject the change in this scenario.

We have tried this but it still does not work. Are you aware of any changes between these two release that could have caused this.

We have now been forced to downgrade to 3.0p again

**Isomorphic** · 16 Mar 2015, 21:47

It sounds to us like Tomcat is doing some kind of partial shutdown and re-start of the deployed application, and at a wild guess, is reloading some SmartGWT framework classes while keeping others in memory.

Doing something like this would break any framework, and once this has happened, the server-side system is probably corrupted in many different ways, and this validation issue is just the most obvious.

So the first thing to do is try to find out what exactly Tomcat is doing when you see this second copy of the application files being made.

**fanie1980** · 1 Apr 2015, 07:41

Tomcat Shutdown

Since your last post we can confirm that tomcat is not responsible for our app crashing or shutting down.

We have used JConsole, Java Vm and YourKit to monitor:
Threads
Memory and leaks
CPU
GC

Everything seems to be in order. There are no errors in the tomcat log files and we have also managed to bypass the Tomcat Load Balancer. After a couple of days to hours the same thing happens.

We have been running the app for two years solidly with no issues, since we upgraded to Smartgwt 5 all of this started happening.

Please guys, we need some help

**Isomorphic** · 1 Apr 2015, 11:55

You said previously:

What we can see in Tomcat is that once the app is deployed it creates a copy in the temp folder (0-myapp), after a few days tomcat creates a second copy (1-myapp). Immediately after this happens the validation (only length validation on text fields) starts failing. We need to clear all the tomcat cache files and restart. And the process starts all over again.

So you previously narrowed this down to a weird behavior of Tomcat but now you are inexplicably dismissing Tomcat as a cause. Obviously,
SmartGWT isn't copying your app deployment around, and if clearing cache files generated by Tomcat fixes the issue, that's not something under SmartGWT's control.

We'd suggest you keep looking at Tomcat, and try to find out what it's doing when those files are being moved around. Obviously there *should* be logs for whatever is going on.

Posting in Tomcat forums also makes a lot more sense than posting here, since SmartGWT routinely apps run for months at a time without needing a restart.

**Isomorphic** · 1 Apr 2015, 11:58

For completeness, we should mention that if you are really stumped, you can purchase Consulting hours from us (there's no evidence of a framework issue, so purchasing Support would not apply).

**fanie1980** · 6 May 2015, 04:27

This is still happening all over the place, Smartgwt has been so unstable and is affecting all our customers. This happens a few times a day and needs to be taken seriously.

Our other partner has also started having the exact same validation issues.

Please can you explain how the validation works. I see there is an OperationType of VALIDATION. As soon as the validation falls over than we are only able to get it back up by restarting the app.

**Isomorphic** · 6 May 2015, 13:30

We could not agree more than this should be taken seriously. That's why you should definitely follow up on the avenues of investigation we've already suggested.

As we've already explained:

1. you are the only user reporting an issue of this kind

2. there is no indication this is a SmartGWT bug; all available data point to a Tomcat deployment issue

3. we don't have enough information to even start to speculate about how to reproduce the problem on our end

If you continue to just periodically post here, providing no new information, and not following up on any of our suggested approaches, it's a certainty that the problem will never be solved.

Announcement

ListGridField with TextAreaItem as editor ignores DS length validation

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment