This document explains the gateway's configuration system in detail. After reading this document you will know how the configuration system works, what configuration options are available, and how to change the values. The developers have chosen sane defaults, so if you're running the example or compiling the example from source, you can skip this document.
Every setting that the developers think someone would want to configure is stored in the config directory. This includes everything from the cascading style sheets used in the portal to database connection information to WSDL URLs.
When the modules are compiled and packaged the files in the config directory are copied into the modules' src directories. By now you've probably realised that any configuration change requires a recompile and re-deployment. This isn't optimal and is being corrected in a future release. But please be aware that any other state that wants to use this software will need to modify and recompile it anyway, so it isn't that much extra work. This is because it is impossible for the Vermont Department of Taxes to implement the gateway in such a way that it could be used out of the box by any other state because each state has its own way of storing tax information and processing returns.
Look in the config directory. There will be two sub-directories state and host . The host directory contains configuration information for each host that which you wish to deploy to. Currently there are two example host configurations. The localhost example contains configuration options to connect to a Hypersonic SQL database running on localhost. The other example, prod01 contains configuration options to connect to a MySQL database running on a remote server.
The state directory contains state specific configurations. These directories include a Constants.java file that allows the user to tweak nearly every possible setting. Use caution when changing these values. The directories also include a localization file that you can use to add your own state specific strings, add additional translations, or override existing translations. Finally, there are portal style files (images and css).
After changing these settings to your liking, you must recompile. See Building from source for details.
The configuration system described below hasn't been fully implemented yet. It didn't make the cut for the 3.0 release. Unless you're running a development snapshot, these instructions don't apply to you.
This document explains the gateway's configuration system in detail. After reading this document you will know how the configuration system works, what configuration options are available, and how to change the values.
Before explaining how it works, it is helpful to have an understanding of the problem trying to be solved. We will use an example throughout this section to help explain things. The example is the e-mail address used for e-mail notifications. When something important happens to the gateway, it sends an e-mail to an administrator.
The easiest way to specify an admin e-mail address directly in the program itself. This has its drawbacks. A user has to manually edit the source code, recompile, and re-deploy when changing an e-mail address. This is too much work and has the potential to be painful for non-programmers. So this solution is not good.
Since building and deploying are not good options, the e-mail address needs to be changeable at runtime. To ensure that the address is persistent across application server crashes and reboots, it needs to be stored in a database. This has its drawbacks too. When the database is down, the program doesn't know what to do because it can't access its own configuration.
The solution is a 3 level fail over system. The first level is the database. Options are stored there and easily changeable at runtime. If the database is down, corrupted, or deleted, the configuration system fails over to the second level. The second level is a properties file that exists within the application archive. It contains settings for a specific deployment. If the file is missing, incomplete, or corrupted, the configuration system fails over to the third level. The third level is a set of hard coded default values in the program source code.
| option | default value |
| server.sstp.wsdl | http://localhost:8080/gateway/services/EFileServiceSoap?wsdl |
| server.sstp.sreg.test.wsdl | https://dev.sstregister.org/services/sstregservice.asmx?WSDL |
| server.sstp.sreg.prod.wsdl | https://www.sstregister.org/services/sstregservice.asmx?WSDL |
| server.sstp.processor.lazyprocessing | false |
| server.sstp.test.user | TESTUSER1 |
| server.sstp.test.pass | TESTERXX |
| server.sstp.fipscode | 99 |
| server.sstp.mail.host | localhost |
| server.sstp.mail.from | Unknown User <noreply@localhost> |
| server.sstp.mail.to | Admin User <root@localhost> |
| server.sstp.mail.subject | Transmission Arrived |
| server.sstp.mail.body | A transmission has arrived at the gateway. |
| server.sstp.mail.enabled | false |
| server.sstp.vt.batchsize | 50 |
| server.sstp.vt.batchbase | 60000 |
| server.sstp.vt.batchmodulus | 1000 |
| dbtest.pass | CONGRATULATIONS 200 OK |
| dbtest.fail | TEST FAILED |
| server.sstp.demo.enabled | false |
| server.sstp.demo.user | GATEWAY99 |
| server.sql.vt.wsdl | http://localhost:8080/gateway/services/SQLServiceSoap?wsdl |