While running in demo mode, SuperContainer Server will run for two hours each time you start it. If the demo period expires, you may simply quit and restart the SuperContainer Server to renew the two hour demo period. When you are ready to purchase a license, just replace the demo license key with your permanent license key to get rid of the two hour timeout.
There is no cost for the plugin; it is included with the purchase price of SuperContainer. There are no registration functions necessary.
If you would like to upgrade from a Workgroup license, first purchase an Enterprise license, and then contact us and we will credit the original charge for the Workgroup license. We are planning on upgrading our online store at some point to make this a more automated process.
Use SuperContainerServer.jar if you just want to put together a proof of concept, or if you're demoing SuperContainer. The standalone mode is also great to use while developing.
SuperContainer 2.0 comes with a bundled installer. If you'd prefer to install manually, you can do the following:
JkFmMount /SuperContainer/* cwpe JkFmMount /SuperContainer cwpe
/SuperContainer/*=cwpe /SuperContainer=cwpe
After saving your changes, restart your web service and all associated services (tomcat, IIS, FMS). Restarting your computer will work as well. SuperContainer should now be up and running!
1. Download latest SuperContainer form www.360wokrs.com/supercontainer/
2. Extract the downloaded zip
3. Stop Tomcat, either using the 'badge' icon in the bottom right corner on Windows, or by stoping service.
3. Copy the SuperContainer folder
4. Paste the folder into tomcat's webapps directory, usually it's located in c:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps. If the SuperContainer folder already exists there, then first backup the existing folder, then paste the folder from clipboard, then replace the SuperContainer\WEB-INF\web.xml file with one form the backed up folder, web.xml file contains customized settings.
5. Start Tomcat, test the deployment.
You can run SuperContainer version 1.72 or later for your clients in Tomcat by following these steps:
The following companies have told us that they are set up or willing to configure their servers to host SuperContainer. They are listed in order of when they first contacted us:
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.
There's a mac-specific feature that lets SuperContainer use native OS X image processing libraries for its image handling. This means it can generate thumbnails of PDFs, as well as just about any other image type you throw at it. This only works if you're running SuperContainer server in standalone mode on an OS X box. It will not work on a Windows server, or when running in Tomcat. It doesn't matter what the client machines are using, however.
Just create a new file at the following location:
/Library/Preferences/com.prosc.supercontainer.properties
The contents of the file should be the following line:
coreImageEnabled true
And then restart SuperContainer. Thumbnails will now be generated using OS X image libs, and PDF will appear as thumbnails instead of icons.
See the section on Plugin autoupdate
Accessing SuperContainer from FileMaker Pro
| Version 7 | Version 8 | Version 8.5 | Version 9 | Version 10 | |
| FileMaker Pro: Access with a Web Viewer | - | - | Y | Y | Y |
| FileMaker Pro: Using optional plugin | Y | Y | Y | Y | Y |
Web Publishing Engine, including optional plugin (requires SuperContainer Enterprise License)
| Version 7 | Version 8 | Version 8.0v4 | Version 9 | Version 10 | |
| FileMaker Pro Server, Custom Web Publishing | - | - | - | Y | Y |
| FileMaker Pro Server Advanced, Instant Web Publishing | - | - | Y* | Y | Y |
| FileMaker Pro Server Advanced, Custom Web Publishing | Y | Y | Y* | Y | Y |
Note: * = FileMaker Server / Server Advanced 8.0v4 on OS X will not work with the optional SuperContainer Companion Plugin. It will work on Windows, or on 8.0v1 - 8.0v3
SuperContainer is fully compatible and tested to work with FileMaker 10
By default, SuperContainer saves files in /Users/Shared/SuperContainer on Mac OS X and C:\Documents and Settings\SuperContainer on Windows. You can set this to any path you want, such as an external drive or network volume. If you are running in standalone mode (ie. double-clicking on SuperContainerServer.jar), that can be configured by clicking 'options'. If you are running in Tomcat or with FileMaker Server, you can configure that by editing the SuperContainer/WEB-INF/web.xml file. Change the 'macintoshFilesPath' or 'windowsFilesPath' setting to where you want the files to be stored. Be sure to configure file permissions appropriately for the folder you're storing to, especially for network volumes.
SuperContainer saves its preferences in a file on your computer (when running in standalone mode by double-clicking the .jar file). On a mac, this is located at /Library/Preferences/com.prosc.supercontainer.plist. Remove this file to remove any stored preferences.
Windows: Search the registry for all keys which include "supercontainer" and remove them.
Mac: Look for a file /Library/Preferences/com.prosc.supercontainer and remove it.
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.
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:
There are three possible solutions
New certificate was included in version 2.56
This was a bug introduced by Apple Java update for Mac.
Workaround was included in release 2.52
was introduced in version 2.52, in leu of working around bug in Apple's update (see above)
Fix added to version 2.58
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)
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.
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:
• All AcmeTech products, including MondoMail, NetTools, CCauthorize, JavaCompanion, and JavaScript Interpreter
• PDMSQL by Professional Data Management
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.
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
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.
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.
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")
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.
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.
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.
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 Tomcat, add this line to the top of /Library/apache-tomcat-5.5.23/bin/catalina.sh, right below the #!/bin/sh
JAVA_OPTS="-Xmx512m"
change Java Temporary Internet Files setting to NOT keep temporary files on the machine.
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
There is a possibility of a permissions problem with the registration information that is written to Java Preferences
Mac: remove /Library/Preferences/com.prosc.supercontainer.plist file and re-register
Windows: remove the registration keys from HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft/Prefs/com/prosc/supercontainer/model
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.
Use UNC notation and refer to server by IP address.
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 standaone deployment set read right 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/
This from Kirk Bowman's email:
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.
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. Done.
Jeremiah Small
To include SuperContainer in your Custom Web Publishing site, just use a FRAME or an IFRAME with the same URL that you would use for your FileMaker Web Viewer.
There are several options available to protect the contents of SuperContainer. Here are some possibilities:
http://yourIpAddress:portNumber/SuperContainer/Files/Client1/Images/39 http://yourIpAddress:portNumber/SuperContainer/Files/Client1/Images/40
To these:
http://yourIpAddress:portNumber/SuperContainer/Files/Client1/Images/rjx11mp/39 http://yourIpAddress:portNumber/SuperContainer/Files/Client1/Images/82crlqq/40
Now, malicious users cannot access unauthorized resources by simply incrementing the record ID.
Remember that you can combine these approaches as well - for example, using the built-in SuperContainer password with the random URL technique. Also see below for tips on SSL encryption.
If you've specified a username and password that are required to access SuperContainer, you can include them in your Web Viewer URL like this:
http://username:password@yourServer:8080/SuperContainer/Files
Note that this behavior may not work in new versions of Microsoft Internet Explorer. See [http://support.microsoft.com/default.aspx?scid=kb;[LN];834489 this article] for more information. If you are having trouble with IE, you can:
The demo file that comes with SuperContainer disables many of the plugin functions when they are being accessed through Instant Web Publishing. For an explanation, read the Security issues with Web Publishing article.
redirecting SuperContainer request from Apache or IIS
redirecting SuperContainer request from Apache or IIS
FIX! Fill this in
FIX! Fill this in
For the purposes of this example assume that we have a contact record that has to files attached to it, one file is the picture of the contact and the other file is contact biography Word file.
In order to have both files linked to the same record they both need to have some common piece of information, such as a record ID. As well, they both need a differentiating attribute, file type is a good candidate.
Example URLs:
http://serverAddress:portNumber/SuperContainer/Files/recordID/FileType
http://192.168.2.1:8020/SuperContainer/Files/12/image
http://192.168.2.1:8020/SuperContainer/Files/12/document
or
http://192.168.2.1:8020/SuperContainer/Files/12/contact_image
http://192.168.2.1:8020/SuperContainer/Files/12/contact_bio
FIX! Fill this in
FIX! Fill this in
There are two ways to accomplish that in SuperContainer.
1.
This requires that SuperContainer is running in 'standalone' mode on Mac. In this mode SuperContainer will automatically render the first page of the PDF. To get a preview of another page just use the page parameter in your URL.
EX:
http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=1
http://localhost:8020/SuperContainer/Files/multi/page/PDF?page=4
2.
This method requires that the system browser on user's machine is able to render PDF files. On Mac this is built in functionality, on Windows this can be accomplished by installing Adobe Acrobat plugin for IE or the equivalent. To load the PDF file in the webviewer use the following URL:
http://localhost:8020/SuperContainer/RawData/multi/page/PDF
Using the context RawData tells SuperContainer to return the actual file stored instead of displaying a Java applet or HTML form to present the file. And if the browser is able to render the PDF then it will be available to the user right in the webviewer. Note that this method loads the complete PDF into the webviewer where the first method load just preview of a single page.
FIX! Fill this in
To use image transparency with SuperContainer, such as with a .png file, you must add "?style=noapplet" to the end of your supercontainer URL. Using this mode, you will not have drag and drop capabilities, so if you need this, you can have one web viewer on one layout without this parameter for dragging and dropping, and then the other web viewer on the layout that needs transparency. Consider that SuperContainer will not automatically detect width and height in this mode, and so you will also need to add "width=x&height=y".
Example: http://yourServer/SuperContainer/Files/path/to/files?style=applet&width=250&height=275
If you want to store the name of an uploaded file into a FileMaker field, first ask yourself whether it's really necessary. The way that SuperContainer is designed, FileMaker does not need to know the filename in order for the user to upload, download, view, print, or delete the associated document. However, FileMaker does need the filename in order to do searches on it.
If you decide that you need to store the filename in a field, there are two approaches, which both involve the optional SuperContainer Companion Plugin.
Run SuperContainer on a Mac in standalone mode, by executing SuperContainerServer.jar file
Set Variable [ $setBaseURL ; SCSetBaseURL() ] Set Variable [ $files ; SCScanDirectory( pathToDir ) ] Set Variable [ $counter ; 1 ] Loop Set Variable [ $upload ; SCSetContainer( folderPath ; MiddleValues ( $files ; $counter ; 1 ) ) ] if [ $upload = "ERROR" ] Show Custom Dialog [ "EROR" ; SCLastError ] End If Set Variable [ $counter ; $counter + 1 ] Exit Loop If [ $counter = ValueCount ( $files ) ] End Loop
One of the original design goals of SuperContainer was that it would work without requiring any plugins. This led to a series of decisions:
Some of our customers do know the names of the files that they are storing, and it seems natural to them to store many files in a single folder. In this case, we make the following recommendations: