Announcement

**Isomorphic** · 14 Mar 2013, 10:45

This is some kind of Tomcat bug. It's telling you that it translated the .jsp code to Java, and tried to compile that, and that Java code was invalid. That's supposed to never happen; if there was a problem with the .jsp, it should have been reported when the .jsp was being translated to Java.

Best guess, this is some kind of timing issue where you happened to be copying this file over to the remote server at the exact moment the browser accessed it. Or, there are intermittent filesystem read issues on the remote server.

If it's a persistent problem, you can probably solve it by deleting the "work" directory of the Tomcat instance, and re-starting it.

**RickBollinger** · 14 Mar 2013, 10:58

I really appreciate the quick reply. I have saved the source multiple times in various ways. So, it is not an intermittent copy problem. I have also restarted Tomcat dozens of times to no avail. The problem is no longer with the remote server. It happens with my locally embedded Tomcat as well. That worries me more.

I thought maybe it was a size problem from somewhere. But, if the VB output JSP runs, it creates the same size code that I see as page source. And, that runs just fine. The longest string I have is 26,122 characters.

I will try to locate my local Tomcat 'work' directory and clean it out.

This is getting all my attention because I am dead in the water without a fix. I have been preparing to leave VB behind. But, that can only work if I can get a pure JSP working version on which to base further development. I need to know what is broke so I can avoid it in the future no matter how I develop.

Thanks,

Rick

**RickBollinger** · 14 Mar 2013, 11:54

I made and found the new PlanetProjectAlphaAppY_jsp.java and loaded it into Eclipse.

I get the following error when I delete the complaining package name:

-Implements org.apache.jasper.runtime.HttpJspBase._jspService
-The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit.

That seems a bit small for an Enterprise scale application. And, it is in the JavaScript domain that the QuickStart Guide mentions for developers to use.

This is a big stop. I am trying to demo my software on a remote server and need the page source to work. I have invested hundreds and hundreds of hours.

I really need your help.

Thanks,

Rick

**Isomorphic** · 14 Mar 2013, 11:57

That certainly is a small number, but it's not coming from SmartClient. You should be able to configure Tomcat to use a larger number.

**RickBollinger** · 14 Mar 2013, 12:17

A little Google research indicates 64K is a JVM limit on how much code can be in a try/catch or just in a module.

There will be no changing this number that I can see.

My solution is to eliminate comments and debug statements in my methods.

Unless you know of any way out otherwise. Or, that I am wrong.

I am getting closer to the end of my application with only a few more windows and forms.

I hope they will fit.

Thanks,

Rick

P.S. Now I wonder why the regular .jsp file that VB makes with the XML inside still works. Doesn't that also get compiled into Java?

**Isomorphic** · 14 Mar 2013, 12:22

That JVM limit applies to individual methods, which is a reasonable limit on it's own, but Tomcat is generating Java code for the .jsp that's all in one giant method.

We would never recommend deleting comments. Instead, you can split the file into multiple .jsps, or move some large .js methods into their own file.

**Isomorphic** · 14 Mar 2013, 12:23

P.S. Now I wonder why the regular .jsp file that VB makes with the XML inside still works. Doesn't that also get compiled into Java?

No, it does not. It results in a very short bit of generated Java that causes our framework to output JavaScript.

**RickBollinger** · 14 Mar 2013, 12:59

I have found a number of ways to compress code without removing comments. I can try that right away.

I would be curious if there are any guidelines or good practices to splitting code into multiple jsp files.

I have to keep in mind that all of this needs to be exported to a remote server and still work.

Much to mull over hot coffee in the AM.

Thanks for the hope.

Rick

**Isomorphic** · 14 Mar 2013, 13:23

We don't have any best practices specific to .jsps other than the overview in the SmartClient Architecture topic in the SmartClient Reference.

**RickBollinger** · 15 Mar 2013, 07:01

In another forum post I saw the following statement:

With cacheFiles(), the files do not execute. cacheFiles() basically allows you to get files into the browser cache so that subsequent loading is immediate.

Does that mean that the alternative discussed, loadJSFiles, DOES execute the loaded files?

I looked at the docs unsuccessfully to find the mechanism to invoke the loaded .js files. Should I wrap them in a function and call them by name? What does loading really comprise?

Since the main app has a top level set of tabs, I thought I would assign the unloaded components to these tabs. If the user would be permitted to see a tab, then I would load its .js file and execute it to build its components unseen and add the tab at the end.

This would reduce the initial amount loaded from the JSP file and let subsequent loading happen asynchronously and only as appropriate for the user.

Sorry for the newbie question.

Thanks,

Rick

**Isomorphic** · 15 Mar 2013, 10:01

Please start a new thread for unrelated questions.

Yes, loadJSFiles() fully loads the target JS files, meaning the JavaScript in them is actually executed.

If you have previously called cacheJSFiles for the same URLs, the subsequent loadJSFiles() happens without a server round-trip (assuming you have not done anything to interfere with caching).

However, your application is far, far too small to start worrying about loading files separately per tab. Take a look at the SmartClient Architecture document again - this loading pattern is counter-productive in a small application, and only makes sense for huge application with clear segmentation points.

**RickBollinger** · 15 Mar 2013, 10:28

I would ask for an explanation for how my application is small when it blows some 65535 byte limit. Except, I am forced to segment now. The explanation is not needed. Actually, I was hoping to do this part later when I knew more.

It was always my intention to segment my app in the way I described. If a user is not a project manager, and I can establish that from the database, then they will not need the MyProjects tab or any of its contents.

Similarly, if they are not a Community Admin, they should not have access to MyCommunity, and so on for MyAccount. 3 fixed tabs and 3 conditional tabs with clear segmentation points. That results in one JSP file and 3 JS files.

I appreciate the info on loadJSFiles. I think I have enough now to proceed onto my next problem.

Thanks,

Rick

**Isomorphic** · 15 Mar 2013, 10:34

65k is what we would consider a small app, where it is not nearly worth loading JavaScript on-demand.

You are not required to load JavaScript on-demand at all yet. You do have to move your JavaScript into separate files, but those can be loaded by ordinary <script> tags without bothering with load-on-demand.

We understand that it seems like a no-brainer to only load JavaScript needed per-role. The reality is that the combination of JavaScript compression (which makes these files barely larger than the HTTP headers needed to deliver them) and shared caching (which means different roles may be able to leverage files cached by other roles) makes this a net loss for a small app.

If you don't understand all the factors involved here, it's best to just follow our best practices.

**RickBollinger** · 15 Mar 2013, 12:05

I yield to your greater wisdom and my gratitude is real.

FYI: some change in 8.2 since January has increased the size of the Java that is generated for the same amount of XML/JSP. To restore my remote app I tried to open up an archived version of my XML. VisualBuilder could not open it. Servlet.service threw the recently familiar exception.

Not to worry. I have been looking at the Architecture page in the docs. Under the cacheable UI discussion there is mention using SCRIPT tags with JSP files. I will use that to segment and substantiate my canvases and just disable tabs according to my scheme.

I will have to assume that recreation of a dataSource is no big deal.

Thanks,

Rick

P.S. This VB problem may not be true. My CVS seems to be acting up. The archved version was many times larger than what got saved. It seems to have duplicated stuff. Stay tuned.

Announcement

JasperException on saved source

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment