SuperContainer Troubleshooting and Known Issues
|SuperContainer Documentation||SuperContainer Companion Plug-in||Troubleshooting and Known Issues||Advanced Configs, Tips, Tricks, and FAQ||PHP Documentation|
I keep getting an "ERROR" when I use the plugin functions
When an "ERROR" occurs, definitely make use of the provided plug-in function, SCLastError, which returns detailed information on what the error is referring to -- and often provides great clues on how to resolve the issue.
This function is invaluable and can save you from hours (or even days) of headache when trying to develop a FileMaker solution that makes use of plugin functions. By reading through our section on Error Reporting with SuperContainer Companion plug-in, you will find out how to check for errors on each plug-in function that is used.
With that said, more often than not, the "ERROR" usually will refer to the base URL not being set yet. See: SCSetBaseURL().
I downloaded the Demo... now what?!
We have several resources available that go into some detail on how to to get started with SuperContainer -- most notably our documentation and the SuperContainerExample.fp7 file that comes with the downloaded content. The documentation outlines several steps on how to get started with SuperContainer, deploying an instance of SuperContainer on your machine, uploading files, and general use of the plugin .
In addition to our standard documentation for the plug-in, we also have a Product Support wiki page for SuperContainer that delves a bit deeper into the product, offering solutions and answers to common questions, usage tips, and troubleshooting help. I recommend that as a Go-To source for information and as a first line of defense when questions arise.
The SuperContainer forum on FMForums is also an ideal source of information and contains several threads of valuable information pertaining to the product.
If by chance, you would prefer to kick back and relax and let the makers of SuperContainer help to integrate its storage functionality into your solution, that's a perfectly viable option as well! We offer custom development work and can help integrate SC for you at our hourly rate of $165/hr. If this is something you think you would be interested in, please do not hesitate to contact us.
We are also available for any general support questions you may have about SuperContainer, or any of our plugins, so feel free to send an e-mail or give us a call if things start to get sticky.
SuperContainer Documentation: http://360works.com/plugins/SuperContainer/documentation.html
Companion Plugin Documentation: http://360works.com/plugins/SuperContainer/plugin-documentation.html
SC Product Support Page: http://wo.360works.com/cgi-bin/support/productsupport.cgi/SuperContainer
SC FMForums Page: http://fmforums.com/forum/forum/122-supercontainer-by-360-works/
How do I know how SuperContainer is deployed?
To check if you are running multiple instances of SuperContainer, you can simply open/launch your favorite browser -- whether Safari or Internet Explorer and type the following into the address bar:
http://myserver.com/SuperContainer/ (if connecting remotely) http://localhost/SuperContainer (if running from the server machine)
If you type the above in and get a page that displays the version of SuperContainer, this means that you have deployed SuperContainer via the WPE of FMS. If you get a 404 error or File Not Found exception, this means you are not running SC via the WPE. Next, try putting the following into your web browser's address bar:
http://myserver.com:8020/SuperContainer (if connecting remotely) http://localhost:8020/SuperContainer (if running from the server machine)
When specifying the "8020" port number, this indicates that you are running SuperContainer in "standalone-mode". If you receive a page that displays the version of SuperContainer, this means that you have deployed SC in standalone-mode (i.e. You have double-clicked the SuperContainerServer.jar file).
Double Scroll Bars on Web Viewer
There have been some instances when double scroll bars have been displayed when viewing an image within a SuperContainer web viewer. If this is the case, it may be that the window size has been exploded/increased and is being viewed at a value greater than 100%. This has been known to force scroll bars to display even with the "style=noscroll" set as a URL parameter. Ensure that the window is being displayed at 100%(max) initially. If the size of the window needs to be edited after the preview is generated to a value greater than 100%, this is possible to do -- if done after the web viewer has loaded.
PC Users are getting a Security Warning when Uploading
If your users are getting an error similar to:
"Warning - Security" "Java has discovered application components that could indicate a security problem." "Name: SuperContainer applet"
In the past, upgrading the Java JRE has fixed this issue. If you are running an older version of Java, try updating to the latest and see if this resolves the issue.
Not able to upload large files, SC deployed with FMS
IIS 7 has a default upload size configured at 30MB. This can be solved by adding the following code to the sites web.config file
<system.webServer> <security> <requestFiltering> <requestLimits maxAllowedContentLength="2000000000"/> </requestFiltering> </security> </system.webServer>
Note: Ensure you place the code within the <configuration> brackets (basically paste it in just before the </configuration> tag), and that the file is properly formatted (indentation = 4 spaces)
Image files are not resizing
In it's normal configuration, SuperContainer can generate thumbnail images of JPEGs, PNGs, GIF files, and most TIFF files. It will not generate thumbnails for PDF files, CMYK JPEG or TIFF files, RAW files, or Photoshop files. If you are running the SuperContainer Server on OS X, you can enable OS X Core Image processing to resize more file types. See the 'Enabling OS X Core Image resizing' section above for instructions on doing this.
File looks like it uploaded but is not visible when I revisit the file/record
The files are actually not being uploaded to the SuperContainer server at all! With the advent of the Apple bug and the disabling of the Drag-and-Drop feature, which hinged on the use of Java applets, users have been dragging files/folders to the SuperContainer web viewer (this does not actually upload the file to SuperContainer but instead only stores a temporary reference to the location of that file).
In order for the file to be uploaded to the server, the user would need to click the button labeled "Upload File" after choosing/dragging the file to the Web Viewer.
By default, the web viewer has a "Choose File" button and an "Upload File" button... I would suggest that you ensure that they are first selecting the file with the Choose File button then, clicking the "Upload file" button to actually send the file to the server.
NOTE: It is important to note that we have (fairly recently) released a newer version of SuperContainer (version 2.852), which restores the Drag-and-Drop functionality without using Java applets. By upgrading to the latest version, you should be able to successfully drag and drop files to the Web viewer without need of using the "Choose File" and "Upload File" buttons at all.
Seeing the same document for all records
If you're having a problem with all of your records pointing to the same SuperContainer file, and you see that replacing it in one record replaces it in all other records, it's because your URL is not unique for each record. Include the primary key, or some other unique value, into the Web Viewer URL for each record, and then each record will be associated with its own separate file
How to handle "ERROR" response from plugin
If you try to call a plugin function, and you get a result of "ERROR", then call the SCGetLastError function to get a text description of what happened. It is always a good idea to have your scripts check the result of all plugin calls to see if an error occurred.
List all locations of log files
When troubleshooting a problem that you're having, we may ask you to send us a copy of your log files. There are several different log files for the different components of SuperContainer, and they are located in different places depending on whether you are running on Windows or Mac.
- Macintosh: /Users/yourUserName/Library/Logs/360PluginBridge.log
- Windows: C:\Documents and Settings\All Users\Shared Documents\360PluginBridge.txt
- SuperContainer Server log (default location):
- Macintosh: /Users/Shared/SuperContainer/SuperContainer.log
- Windows: C:\Documents and Settings\SuperContainer\SuperContainer.log
- SuperContainer companion plugin log:
- Macintosh: /Users/yourUserName/Library/Logs/360Plugin Logs/360Plugin.log
- Windows: C:\Documents and Settings\All Users\Shared Documents\360Works FM Pro\360Plugin.log
Providing the correct value to SCSetBaseURL
When calling SCSetBaseURL, you should include the portion of the URL up to and including the 'Files' portion, ie: SCSetBaseURL("http://yourServer:portNumber/SuperContainer/Files")
When calling other plugin functions, just pass in the portion of the URL that comes after the 'Files' portion, ie: SCGetContainer("Images/41")
Don't forget if you have additional parameters to add such as "selfSignedSSL" then you must include empty quotes for the username and password values because the order matters.
Set Variable[$result; Value:SCSetBaseURL("http://yourServer.com:8020/SuperContainer/Files"; "" ; "" ; "selfSignedSSL=1")]
Problems installing Tomcat
Some customers have reported seeing this error message when trying to start Tomcat, after downloading and installing it as a Windows Service:
The Apache Tomcat service terminated with service-specific error 0 (0x0)
This is not directly a SuperContainer problem, it is a problem with Tomcat. This can be caused by having Java 6 installed, instead of Java 5, if you are using Tomcat 5.5. Try downloading and installing Java 5 from www.java.com to see if that fixes the problem.
Uploading package files
SuperContainer 2: supports upload of package files.
SuperContainer 1: Some OS X files, such as rtfd documents, are not really files, they are folders which are presented as a single file icon by OS X. These files cannot be uploaded through a web browser unless they are first compressed, such as a into a .zip or .sit file.
Thumbnails Are NOT Generating
If you've customized the path were SuperContainer saves files, and lets assume that you're saving to a folder at the top level of an external drive. Ex. save path /Volumes/External Drive/SuperContainer/ And you've only given write privileges to the SuperContainer directory you may experience problems with preview generation. The reason is that SuperContainer save the previews in the "thumbnails" directory at the same level as the directory where SuperContainer is writing the actual files. And if SuperContainer does not have write permissions it will fail in creating the "thumbnails" folder, thus failing to generate a preview. There are two solutions, first give write permissions to SuperContainer so that the following structure is possible: /Volumes/External Drive/SuperContainer/ /Volumes/External Drive/thumbnails/ Second solution is to point SuperContainer to the sub folder of the custom directory, like so: point SuperContainer to /Volumes/External Drive/SuperContainer/Files for example, so that the "thumbnails" folder is created like so: /Volumes/External Drive/SuperContainer/thumbnails.
Out of Memory
When resizing large images, SuperContainer may run out of memory. If you're running the SuperContainerServer.jar, you can launch it from the terminal with additional arguments which increase the maximum memory used by SuperContainer:
cd /path/toSuperContainer java -Xmx600m -jar SuperContainerServer.jar
If you're running SuperContainer in Web Publishing Engine instance of Tomcat the look for this file: FM12 path
FileMaker Server/Web Publishing/publishing-engine/jwpc-tomcat/bin/catalina.sh, FM11 path
FileMaker Server/Web Publishing/publishing-engine/cwpe-tomcat/bin/catalina.sh, on Windows open the
.bat file. Open the file and look for this block:
# FileMaker Server JWPC Tomcat Settings CATALINA_HOME="../../../../Common/Tomcat" CATALINA_BASE=".." JAVA_OPTS="-server -d64 -Xmx512M -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton -DFMS.COMPONENT=jwpc"
-Xmx parameter and save the file.
If you're running SuperContainer in your own instance of Tomcat, add this line to the top of
/Library/apache-tomcat-5.5.23/bin/catalina.sh, right below the
Same preview image after deleting a file and uploading new file
change Java Temporary Internet Files setting to NOT keep temporary files on the machine.
Standalone Mode on OS X Crashing
Newer versions of OS X use Java version 6 by default. Due to 64-bit issues, SuperContainer CoreImage support does not work correctly in Java 6. The workaround is to launch SuperContainerServer.jar using Java 5 instead. Use the following command to launch SuperContainer in Java 5 (substituting the correct path in the first step):
cd /path/to/SuperContainer /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Commands/java -jar SuperContainerServer.jar
Registration is gone after restart
There is a possibility of a permissions problem with the registration information that is written to Java Preferences
/Library/Preferences/com.prosc.supercontainer.plist file and re-register
Windows: remove the registration keys from
An ampersand (&) or other special characters in the "Registered To" field can cause trouble with registration. To fix this, you must hard-code the registration information into the web.xml file. The ampersand must be coded as "&" (without quotes) instead of just an ampersand.
NAS Storage permissions problems
Use UNC notation and refer to server by IP address.
Error 500 in browser
Incorrect permissions is the likeliest cause of this error.
If using FMS deployment set the permissions to owner: fmserver rw group: fmsadmin rw If using standalone deployment, set read/write permission for the currently logged in user. If using Tomcat deployment, set read write for the user used to run tomcat.
Command line example for fixing permissions for FMS deployment: cd /Users/Shared/ chown -R fmserver:fmsadmin SuperContainer/ chmod -R 775 SuperContainer/
FileMaker crashing, Java issues
This from Kirk Bowman's email:
- I had a Java install that was not listed under Add/Remove Programs. I was able to remove it with this tool which I found on the Java site.
- I had a second Java Install which was from a trial copy of Crystal Reports. This is the install Jesse noticed in the logs I sent. I removed it manually.
Once they were removed, I installed JRE 6 Update 7 (for FMS9 compatibility) and the crashes have stopped on Windows with the SuperContainer applet.
This crash may happen when 64 bit Java is used, since the core image C libs are compiled for 32 bit they won't work with 64 bit Java, the solution is to use 32 bit Java.
Missing Files on Mac
On a Mac, if you configure SuperContainer to store images in a mounted volume, and one day it mysteriously stops seeing all the files it had previously created, but otherwise seems to be working normal, there's a good chance that someone tried to operate it while the volume was not mounted.
What SC does if you give it a path that doesn't exist, is it makes that path for you. This is a useful feature in most cases, but if the volume you are targeting is not mounted (on a Mac) SC will make a directory with the same name as the volume in /Volumes. Then next time the volume actually is mounted, the sym link in /Volumes gets a 1 appended to it. Fortunately this is exceedingly simple to fix.
Mount the volume, copy any files that were uploaded into the imposter folder to the proper location in the volume, unmount the volume, delete the folder and remount the volume.
Memory Leaks in SuperContainer?
There is a documented and filed bug with Mac OS X's Core Images X Library, which does leak memory. SuperContainer makes use of Mac OS X's Core Image library by default, but also can use Mac's QuickLook library for image rendering.
This is not SuperContainer specific and is related to the Core Image library.
The best approach is to enable QuickLook for SuperContainer, the instructions for this can be found on our SuperContainer Product Support wiki page. See Enabling QuickLook.
Container fields in Windows that use OLE
SC Companion plugin behaves incorrectly, b/c FileMaker stores only the preview of the file internally and only the preview ends up uploaded to SC Server when using the Companion plugin SCSetContainer function.
Workaround: use ExportFieldContents script step and export the file then use the filepath to the file when calling SCSetContainer function.
FileMaker crashes when closing a window with SC webviewer
This is confirmed bug in FileMaker: http://forums.filemaker.com/posts/af993cfbc4
Behavior: when closing a FileMaker window containing a layout that has multiple webviewers displaying a Java applet, FileMaker crashes. A crash log is produced on the Desktop.
This issue is not specific to SuperContainer, this is a problem with all Java applets.
Platforms exhibiting problem:
Java versions exhibiting problem:
- Java 1.6 (we've tested several different updates, and there is no fix for this in Java 1.6 yet)
There are five possible solutions
- Downgrade to Java 1.5 - http://java.sun.com/products/archive/j2se/5.0_19/index.html
- Use Custom Menus in FileMaker Pro Advanced to close/navigate to different layouts. See Creating Custom Menus in FileMaker Pro Advanced.
- Use FM script to either switch to a different layout then close, or minimize the window and then close
- Use the style=noapplet parameter in the SC URL
- Un-check "Enable the next generation Java Plug-in" option in the Java Control Panel -> advanced -> Java Plug-in
Expired certificate in SuperContainer Java applet
New certificate was included in version 2.56
SuperContainer applet not responding to mouse events(on Mac)
This was a bug introduced by Apple Java update for Mac.
Workaround was included in release 2.52
Weird flickering of SuperContainer applet
was introduced in version 2.52, in leu of working around bug in Apple's update (see above)
Fix added to version 2.58
Black or Grey webviewer, when using SC with other 360Works plugins
This may be caused by an old 360Works plugin, all plugins that were release by 360Works prior to December, 2008 can cause this issue.
Fixed in current version(s) of 360Works plugin(s)
Black or Grey webviewer, without 360Works plugins installed
This can be caused by an outdate Java Runtime 1.1.4 released by Microsoft.
I believe that this JRE is shipped with some Microsoft product and is installed silently.
Please contact 360Works for troubleshooting help/directions and fixes.
SuperContainer and proxies
Proxies can cause issues for the SuperContainer applet.
Please contact 360Works with specific problems related to proxies.
We have found a few plugins which cause issues with Java in FileMaker. As SuperContainer is Java-based, a damaged java being launched within FileMaker will prevent SuperContainer's java applet from loading properly. SuperContainer can still be used in noapplet mode, but the older, damaged java instances launched by these plugins will prevent the applet from working properly.
Plugins with known issues:
• PDMSQL by Professional Data Management
Issue with deleting files stored in SuperContainer
When SuperContainer server is set to store files on a network drive, in presumably a Windows network
And a webviewer on a layout where delete script is executed is pointing to the file using a file URL instead of using SuperContainer RawData URL, the delete will fail without much of a message, similarly the file could not be deleted via Windows explorer from another machine.
"The specified action was denied by the server"
When SuperContainer server is running on a Windows machine, WebDAV Publishing can interfere with the SuperContainer Put operation (used for file uploads) and produce the error message "The specified action was denied by the server." WebDAV Publishing is a part of IIS (Internet Information Services), and IIS is a part of Windows Server.
To disable WebDAV Publishing:
- Start Server Manager (usually in the Taskbar on Windows Server)
- Select "Roles" near the top of the hierarchy
- Scroll down to Role Services and expand it (click the little arrow button next to the heading)
- If WebDAV Publishing has a status of "Installed"
- Click "Remove Role Services" (a separate window will open)
- Uncheck the box labeled "WebDAV Publishing"
- Click the "Remove" button
- Restart the server after the removal process completes
Publisher could not be verified
Usually this is seen when working with a web viewer pointed to a SuperContainer resource. The security settings in Internet Explorer are used as the basis for web viewers in FileMaker, and the settings for ActiveX controls (in Internet Explorer) can affect how Windows treats requests for SuperContainer java applets. A quick fix for this is to just add the "noapplet" style modifier to your URL which will make SuperContainer display resources in HTML. For example:
To modify Internet Explorer settings to allow SuperContainer java applets in web viewers in FileMaker:
- Click the Tools menu, and then click Internet Options (for some versions click the "gear" in the top right of the IE window then click Internet Options)
- On the Security tab, make sure "Internet" (the globe) is selected, and then click the Custom Level button
- Scroll down the Security Settings list until you see "ActiveX controls and plug-ins"
- For "Automatic prompting for ActiveX controls", click Enable
- For "Download signed ActiveX controls", click Enable or Prompt
- For "Run ActiveX controls and plug-ins", click Enable or Prompt
- For "Script ActiveX controls marked safe for scripting", click Enable or Prompt
- Click "OK", and then click "OK" again
You may get a notice saying that your settings are unsafe. This is normal and expected.
SuperContainer reverts to default base URL when running in standalone
When running SuperContainer in standalone mode you can set the base URL from the Options window. If you change the base URL specified in the Options window to a custom path then sometimes an error will occur where the server "forgets" the custom path and reverts to the default value. The fix is to modify the default value in the web.xml file to your custom path.
- Navigate to the location of the SuperContainerServer.jar file
- In that same directory there should be a folder named "SuperContainer"
- In that SuperContainer folder there should be a folder named "WEB-INF"
- In that WEB-INF folder there should be a file named "web.xml".
- Open the web.xml file in a text editor. You are looking for the line that corresponds to the operating system where the SuperContainer server is running. They each have a "<description>" tag, so it shouldn't be difficult to find the correct section.
- Now copy the full path of the location where you want SuperContainer server to store its files. Take the copied file path and replace the text between the "<param-value>" tags with it. This should force SuperContainer to set its base URL to the location you have specified.
It's fine to use a test folder that you create to see how SuperContainer will look once it has been set in this method. You can always come back to the web.xml file and modify it again.