These release notes accompany the Tolven Installation Guides
Select all of the tolven projects in Eclipse Package Explorer view as shown in the installation guide here. Right mouse and select Team > Synchronize. This will selectively update your source code from CVS and not disturb any local changes you may have unless you specifically select override and update. You will be pulling source from the most current versions (HEAD) of files in CVS. This is a constantly moving target and so you have little assurance of the stability of the code (although you are assured of seeing the latest code).
We tag source code nightly so that you now have the option of pulling a slightly more stable "snapshot" of the source code. These snapshots are labeled with a B, the year, month, day, hour and minute of when the snapshot was done. To pull a snapshot rather than the current version of source code is simple in Eclipse. (Be sure you have no uncomitted local changes). Select all of the tolven projects in the Package Explorer, right mouse Team>Switch to another Branch or Version option. Select Select the tag from the following list and choose the tag you want to download from under Versions. This will adjust your source code environment backward or forward to match that tag. (Tags are listed below along with the notes about that release, most recent first).
Selecting an older tag than the one you've used won't have any effect on the database or LDAP servers. So you may experience backward compatibility issues. Neither forward nor backward compatibility are promised between low-level builds. Nevertheless, we will try to warn you when this is a possibility and suggest a remedy if at all possible.
New libraries are sometimes added to the build. See this section of the developer install for the complete project-to-library matrix so that your Eclipse Package Eplorer can do proper error checking..
When you install Tolven, you run an Ant target that creates a new ant-build.properties file. During development, we may add new properties (and sometimes delete properties) from this file. While we update the ant-build.template file, we do not update the ant-build.properties file since you may have made local changes to it. Therefore, you will need to manually add any changes made to template/ant-build.template into your resources/ant-build.properties file. Alternatively, you can copy template/ant-build.template contents to resources/ant-build.properties and repeat the adjustments you might have made to the file when you first installed.
We'll also tell you in the release notes below when a change is made to this file and/or the tolven.properties files.
[New as of B20061018-0245]
The tolven.properties file contains settings used by Tolven at runtime.
The edited properties are then immediately available to the application.
*Warning: Changing the tolven.properties files in the jboss directory does not change the tolven.properties file in the top-level tolven/resources directory. Ideally, you should maintain the top-level tolven.properties and then copy it to the jboss deployment directory using deploy-from-stage..
Security and privacy have been designed in "from day one" and we continue to evaluate and improve Tolven security features.
We want to reimind the reader that Tolven and Tolven installations use many layers of protection. One particular security issue is usually not a direct route into the system but rather a vulnerability at "some level." We usually try to make this clear by using terms like "If an attacker were able to get to X point, then...."
We also ask you to understand if we briefly delay release of certain security issues to public forums until a fix is available and trusted sites have had a chance to install them.
The following is in reverse chronological order, the most recent first. These are high-level notes here. For (a lot) more detail, consider adding yourself to the Tolven CVS mailing list. Being on this particular list will cause you to get an email for each checkin (I recommend setting up your mail client to move these to a separate folder upon arrival. Then you can puruse them at your leisure). You can of course unsubscribe if it turns out not to be for you. Also consider adding yourself to the list for email notification when the Tolven forums are updated.
Each account has it's own copy of metadata for the application. By policy, Tolven does not modify this metadata unilaterally. This allows the account owner to decide when to initiate a change to their menu structure. A few weeks ago, Tolven added a temporary feature to the Customize screen that allowed the account administrator to update the metadata for that account from another named account, presumably an account that has the latest and greatest metadata (no actual patient data is used). This feature has been deprecated.
The permanent feature, which is more restrictive, uses the account template specified in the account type as the exemplar for that account type. The Account title of that template account is displayed in the link inviting the user to update the metadata.
This feature is also used when creating completely new accounts. However, if no account template is specified, then factory preset metadata is used.
The system administrator then sets the account number of this template account into the templateAccount column of the corresponding AccountType. This makes the template account the account used when updating individual accounts.
Here are two scenarios where this feature is used:
Scenario 1: When a user creates a new account, a list of account types is presented. If an account type in that list specifies a template, than that template will be used to create the metadata for that new account, otherwise, factory preset metadata will be used. The factory preset mechanism provides the means of "boostrapping" the metadata for an installation. the system admin can select any account as the template for that account type.
Scenario 2: The system administrator creates a new account or updates some existing account's menu structure. Demo data or even real patient data can be used in this account, it will not be copied to a target account. The Title of the account should reflect the nature of the the template. For example, "Account template approved 3/14/2007". the account type of template must match the account type containing the reference to the template.
Note: Updating meta data is always additive. Existing data is never deleted or hidden by a metadata update. An exception is intermediate navigational menus which may be removed if they would lead no nowhere.
Note: While this change is not critical, it will require a manual change to the JBoss configuration for existing installations wishing to add it.
Previously, an error 403 would automatically redirect to the login page. This was a problem for AJAX elements which would not get the error message (if it was legitimate) nor would it handle login properly when a session had expired and the user needs to login before proceeding to the requested page.
The error 403 is caused by insufficient space to hold the post body until the user logs in again after the session expires.. This change increases the buffer used for this purpose so that 403 errors no longer occur. (Tolven uses JSF which uses large hidden fields thus frequently hitting this limit).
server.xml under the tolven project contains the change. But you will need to edit the running server.xml in the JBoss directory. Simply add the
maxSavePostSize="-1"
attribute to the <connector> that defines the HTTPS (SSL) port and restart the JBoss server.
Menu data (patient lists, result and observation lists, worklists, etc) now update automatically when the database shows a change. Each instance of each kind of list now has an entry in a new table that keeps a simple version number of the collection. Each time an entry is added to or changed in a list, the version number for that list is incremented. When a list is downloaded to the broswer, the version number is also downloaded. The browser then initiates a query asking if any of the lists it currently contains have changed and if so, the browser either makes note of the fact or immediately updates the list (of the list is currently visible).
While not yet enabled on the mobile interface, it is likely to operate the same way.
It is very important for performance that you add an index to the new table that is created to support this capability.
1. After synchronizing, deploy the new ear file. Doing so will create a new table in the app schema called menu_data_version.
2. Using PqAdminIII, the command-line SQL tool, or another SQL tool, create a unique index on this table:
CREATE UNIQUE INDEX mdv_index1
ON app.menu_data_version
USING btree
(account_id, element);
Note: The table will populate automatically as new menu data is updated. No migration is required.
tolven.invitation.replyTo=http://mydomain.com:8080/Tolven
Notice that the contents of this property is now truncated down to the context root. This is essentially the URL that will be used to tell users what to bookmark in order to find the tolven login page. On a production system, you can eliminate the port such as:
tolven.invitation.replyTo=http://mydomain.com/Tolven
Invitations and some pages now use this property as the base for other links. for example, an invitation email now contains a link like this:
http://mydomain.com:8080/Tolven/public/activating.jsf?invitationId=1234
The logo file name and the CSS is now accessed via TolvenUser. This allows more flexibility in application behavior where more than one sponsor may be involved. While TolvenUser won't normall have anything to say about the logo and CCS (it simply defers to AcountType), the opportinity is there.
AccountType is now the place where the logo and css is derived. There are no longer any ephr vs echr sdecisions handled in scripts.
Developers note: Please honor the css settings established in portalTemplate.xhtml.
Most options at the bottom of the page are either removed of moved to the top of the page. portalTemplate.xhtml, the main application template for Tolven, has been cleaned up substantially.
Tolven is now using the bouncy-castle library for encryption management. Also, tolven is now using swing for a new GUI-based pre-deployment configuration tool. jsch is used for secure copying when deploying tolven to remote systems. Add the following lines to ant-build.properties if they are not already there:
jsch.location=${tolven.location}/lib/jsch
swing-layout.location=${tolven.location}/lib/swing/swing-layout
bouncy-castle.location=${tolven.location}/lib/bouncy-castle
If you are using Eclipse, then you should also add these libraries to the Eclipse package explorer. See the developer install for the complete project-to-library dependency matrix.
Several new data entry features have been added:
Any number of notices can now be displayed on the login page. Each notice has a displayed Effective date as well as hidded show-from and show-to dates that control when the notice will be displayed. Since the notices are in the database, this allows notices to be "post dated": created before they are displayed.
A new mechanism to force the user to answer certain questions before being able to login has been added. This would be things like terms of use, critical notices, "opt-in" or "opt-out" questions.
Questions can take the form of radio, check, drop list or multi-select.
There is no GUI for these yet but some test questions can be created in the database by uncommenting the call to initializeQuestions( ) in org.tolven.web.TolvenContext
If you navigate to the Patient's Tab of a newly created Account, it will have a "Menu" sub page and on that a NewPatient option. This will launch the Wizard to create a new patient. There are still some rough edges that nead to be cleaned up, including the method to launch it, the duplicate check, etc.
Changes have been made to the TRIM XSD which means that older trim-based observations are no longer valid and we're not providing a migration path given that this is still alpha software. These new feature support "slots" deeper into HL7 DataTypes. For example, AD, EN, and even simple types like II allow separate specification of behavior for indicidual Datatype components. ValueSets are now also properly represented in TRIM documents. These changes allow the UI to derive most of the structure of a wizard/drilldown page from the TRIM definition and leave only look and feel to the UI.
Finally, new facets have been added: The <label> facet specifies the UI "prompt" for entry fields. The <set> facet can be used to initialize attributes to a default value during instantiation, such as defaulting in the current time for an observation.
After synchronizing with CVS, there will be a new library dependency, on Bouncy Castle. You will need to update your ant-build.properties file with the line:
bouncy-castle.location=${tolven.location}/lib/bouncy-castle
The updated ant-build.template will contain this new line. The library itself will be downloaded from the CVS synchronization.
Bouncy Castle provides SSL and digital certificate functions previously provided by openSSL. Unlike openSSL, Bouncy Castle is written in Java and thus is more portable and avoids OS-specific quirks. Security is improved because fewer temporary files need to be generated and command-line execution is avoided thus reducing exposure to potential areas of abuse.
We will remove the openssl library from the distribution in the future.
Passwords are now hashed with SHA-1 and a 64-bit salt. No immediate change is required in LDAP. As passwords are added or changed, they will be stored in the new format.
A salted one-way hash like SSHA is very secure. Assuming an attacker could gain access to the LDAP database†:
See test.org.tolven.security.hash.SSHATest.java for an example (This is a unit test for the SSHA encoding method)
Add the JUnit library to tolvenSecurityCommon project (right mouse over project, Build Path > Add Library > select JUnit).
TRIM now holds a serialized dump of "form data". While not terribly important after the TRIM is submitted, this data is closer to the raw information entered by the user and thus is a better place for temporary storage before the TRIM is finalized. For example, even invalid data can be saved prior to submission, and therefor can be restored if the user should be interrupted.
In a dramatic simplification of the wizard XML format, a number of tags have been added, all with the <wiz:> namespace prefix:
<wiz:step/> <wiz:body/> <wiz:group/> <wiz:certainty/> <wiz:yesno/> <wiz:radio/> <wiz:check/> <wiz:integer/> <wiz:question/> <wiz:info/> <wiz:help/>
Wizard skip logic added (previously skip logic was brute force directly in the page). Several predicates added in the first batch:
| gt | Greater than supplied parameter |
| is | equals |
| isTrue | answer is true |
| isFalse | answer is false |
| isAnswered | question has been answered |
| isNotAnswered | question not answered |
| isNotFalse | question not answered or answer is false |
| isNotTrue | question not answere or answer is true |
Previously, the notices on the loging page were embedded directly on that page. The login page now uses an indirect means of indicating where the notices are by using a property in tolven.properties:
tolven.notice.uri=/notice.xhtml
As with other properties, this setting can be changed without stopping the application server.
A notice.xhtml file has also been included in the kit. This new file can contain static text, as before.
Also, a new database table (core.notice) has been added that provides dynamic text to be displayed on the login page. There is no GUI for maintaining this table yet.
This new set of methods is still in testing so is not used in the install process yet. In fact, one of the purposes of this new code is to separate configuration of certificates from software installation. The new code is added in the tolvenSecurityCommon projects.
This code adds a new library to the build process which means for an existing development environment, you'll need to update ant-build.properties (ant-build.template has the new line).
jsch.location=${tolven.location}/lib/jsch
Thanks to Joe for creating this new Java-based credential-management function.
Some recent changes caused a performance regression which has been resolved. To take advantage of the performance fix in an existing installation, paste the following changes in a PgadminIII SQL window and execute it:
DROP INDEX app.md_index3;
CREATE INDEX md_index3
ON app.menu_data
USING btree
(menustructure_id, lower(string01::text), lower(string02::text));
CLUSTER md_index1 ON app.menu_data;
The user can now select to receive eMail generated by Tolven in HTML or straight text format.
A few pages were getting 404 Page not found errors. These have been corrected.
The temporary Glasgow coma score is now persisted poperly and appears in the Observation menu.
Refreshing the TRIM used by a specific account can be done by checking the checkbox at the bottom of the Customize page and submitting. There was a bug in that it would duplicate previous TRIM entries in the "New" menu. Now, it removes old entries before adding the TRIM entries.
(Note: This process is temporary -- the system will eventually send an notification to the account when new TRIM is available).
The Tolven Mobile Client now uses MIDP 2.0 instead of the newer MIDP 2.1 which is not supported by many mobile devices yet. This means that most recent Motorola, Nokia, Blackberry, and Sony/Ericsson phones should run Tolven's mobile client although we hav tested very few of these devices.
Added a new, consistent look for "simple pages", those pages not part of the main AJAX-based application such as login, account and user preferences, select account, etc.Also, a number of obsolete and duplicate pages have been removed - this should reduce the confusion about which page does what. A few pages were moved to more appropriate locations and one or two pages were renamed to better describe their purpose.
Page flow also changed slightly. For example, a more descriptive page now displays if a new user attempts to login for the first time without using the link provided in the activation email.
If you had experiences error 403, typically after the session times out, those should now be gone.
The wizard mechanism now handles errors more consistently. If any errors are returned by thr application during upload, the last page gets a list of the errors and the submit button is disabled. Each question now contains a field where errors assocuated with that particular question are displayed.
The wizard pages now support navigation to individual fields rather than just the page. This allows, for example, the list of errors on the last page to link directly back to the problem.
We are migrating some tables out of the public schema. In this case, the JMS tables are now created in a new schema called jms. If you run the tolven-database-init.sql script (no harm done if the schemas already exist), it will create this schema. But it you are upgrading, you may just want to manually create the jms schema with PgAdminIII. (select the Postgres database, right mouse, New Schema...).
Accounts created before the new encrypted messaging was added can't be the target of an encrypted message until some user of that target account logs in at least once: The digital certificate used for message processing is created automatically upon login. Note: It's not likely that many people will experience this and never will for new installations.
The planned encryption capabilities of Tolven are now complete. All documents at rest, both in the document store and while in transit between accounts are encrypted. We are currently reworking the installation procedure relative to digital certificates but this will have no effect on the operation of the system relating to security.
Because of Tolven's "no exceptions" design, a lost password on an account with only one user means the encrypted data in that account is lost forever. For this reason, it is a good idea to make sure there is more than one user in an account. Clinical accounts will almost always have more than one user but for personal accounts, it may be a good idea to allow a trusted family member, an administrator or agent to also be a member of the account so that they can login to the account if needed.
[Developer install only] The following instructions assume that you want to preserve your current environment.
Alternatively, you can start with a fresh developer install (JDK, openLDAP, postgreSQL, JExplorer and Eclipse itself can remain as-is, but in Eclipse, either delete or rename the current workspace and start a new workspace - File > Switch Workspace... ). Otherwise, proceed as follows:
In either case, you will be re-establishing a new security infrastructure with new certificates.
1. In Eclipse, create two new Java projects and then synchronize them from CVS.
Each project needs the user library: jboss-client.
In addition, tolvenCommonWeb needs to be dependent on the tolvenSecurityCommon project.
2. Synchronize all other projects using Team > Synchronize to get all the latest code from CVS.
3. In ant-build.properties, add the following new lines:
mdb.username=mdbuser
tolven.security.mdb.salt=efghabcd
tolven.security.mdb.iterations=13
tolvenSecurityCommon.location=${tolven.home}/tolvenSecurityCommon
tolvenSecurityWeb.location=${tolven.home}/tolvenSecurityWeb
4. In ant-build.properties, remove the tolvenSecurity project build, it is no longer used:
# obsolete tolvenSecurity.location=${tolven.home}/tolvenSecurity
Also, close or remove tolvenSecurity from the Eclipse workspace. (Right mouse tolvenSecurity, select Close Project)
5. tolvenEJB was dependent on tolvenSecurity which is now obsolete. In the project build properties for tolvenEJB project (select tolvenEJB, right mouse Build Path > Configure Build Path..., remove the dependency on the tolvenSecurity project and add the tolvenSecurityCommon project.
6. Completely delete the tolven-jboss-4.0.4.GA directory which is probably under the c:\tolven-HEAD directory.
7. In your Eclipse Ant view, unzip-tolven-jboss
8. stage-init-all - this should now ask for 7 passwords in this order (if you want to use the defaults):
tolven, secret, tolven, mdbuser, tolven, postgres, tolven
9. And then in the Ant view, deploy-from-stage.
10. ldap-init (openLDAP needs to be running),
11. If not already started, make sure postgreSQL and openLDAP are running.
12. No NOT start jboss yet (we used to have you run jboss and then deploy but you must deploy fist now)
13. In your Eclipse Ant view, deploy
14. Start JBoss
Tolven should up as soon as the build completes and the JBoss deploy sequence completes in about 2 minutes (check the JBoss console to be sure it deployed correctly).
Message payloads are now encrypted so that, should they come to rest in a queue on disk, the payload cannot be interpreted. the mechanism is analogous to document encryption but uses different keys. One significant difference between document decryption and message decryption is that for a document, the user is present and therefore their password can be used to protect the private keys involved. When a message is processed, the user is not present and thus no password is available to protect the private keys. Instead, a technique is used where the system administrator provides a password that is involved in the decryption of messages. This is combined with per-account private keys so it is somewhat similar to a safe deposit box "two key" system. Unlike documents, messages are generally short-lived and so system administrator passwords can be changed frequently to limit possible insider access to protected data.
When new data is entered into the wizard, it is now possible to select another account for the data to be routed to in addition to the user's account. For example, sending a blood glucose measurement taken at home to the physician. Two things are required for this to work:
1. The account must have established a relationship with other accounts, such as the personal account establishing a relationship with the doctor's office. This is done in "Preferences" Edit Account Profile. Add accounts to the "Account Exchange - Send" - this is unilateral for the moment - if you want to send to the other guy, the other guy has no say". This will be strenghened soon so that the receiver has to acknowledge and aggree to the exchange.
2. The Patient must be known to the receiver. To do this, select the patient you want to the other party (eg the doctor's office) to know about and go to Personal > Providers. When you select a provider, it will send a copy of that patient's record to the provider. Shortly, this will be enhanced in two ways. a) the sender will be able to decide what gets sent b) the receiver will get a chance to decide if they want to accept it and if so, if it matches an existing patient.
The Family Generator can be called directly without it generating any data inside the Tolven database. An example program is provided.
In addition to synchronizing all of the usual modules from CVS (including the new tolvenSecurity module, see previous release note below).
Once synchronized with the latest source code (and the JBoss security-service.xml configuration change noted in the release note below), deploy Tolven (in the Ant view of Eclipse) and restart JBoss.
If you haven't done so already, download (File > New > Project from CVS) or synchronize (Team > Update) the tolvenClient project from CVS.
There is a new test program in this project called TestFamilyGen.java that will call into the Tolven data generate and return FamilyUnits (which contain Family members, each of which is composed of a VirtualPerson). There is a readme.txt file in the tolvenClient project directory with library and JNDI instructions. The client program (TestFamilyGen) does not have to be on the same system as the server but the jndi.properties files will have to change to do so.
The test program displays most of the data generated on the console and looks something like this:
Zangl family at 7757 Church Drive, MARATHON, NY 13803 MOTHER: Mona Lucy Zangl F May 4, 1984 CHILD: Robert Charles Zangl M Jun 7, 2006 CHILD: Francis Jody Zangl F Jul 5, 2002 Babiarz family at 4439 Mangham Way, WHITE HALL, MD 21161 MOTHER: Joyce Maritza Babiarz F Jul 31, 1962 FATHER: Joe Earl Babiarz M Dec 17, 1964 CHILD: Cindy Jordan Babiarz F Jun 1, 2006 CHILD: Terry Valerie Babiarz F Jan 31, 1994 CHILD: Sylvia Mildred Babiarz F Oct 18, 1994 Lynch family at 4187 Kenner Road, CALUMET PARK, IL 60643
MOTHER: Lynn Ernestine Lynch F Sep 19, 1905
A security change has been released to CVS that fixes a problem with timeouts. For example, pausing for around 30 minutes should either continue to work or log you out, depending on the session timeout setting. Instead, it was causing decryption problems. This has been fixed but the fix requires a manual change to your jboss configuration (new installations are OK).
After updating from CVS, you should see a new file in tolven/jboss-config called security-service.xml
If you've just updated from CVS, it needs to be manually copied to something like:
C:\tolven-HEAD\tolven-jboss-4.0.4.GA\server\tolven\deploy
Then restart JBoss.
The gmail mail server requires that the mail client talk to it via SSL on port 465. The JavaMail configuration in
tolven-jboss-4.0.4.GA\server\tolven\conf\props\tolven.properties
should look something like this:
mail.smtp.host=smtp.gmail.com mail.transport.protocol=smtps mail.smtp.socketFactory.port=465 mail.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory mail.smtp.socketFactory.fallback=false mail.smtp.auth=true
However, the Tolven demo configuration prevented this from actually working.
By default, Java contains a list of legitimate root certificates from the likes of Verisign and Entrust. However, the demo configuration for Tolven overrides this in tolven-properties-service.xml in the jboss deploy directory.
javax.net.ssl.trustStore=f:/tolven-alpha4/tolven-jboss-4.0.4.GA/server/tolven/conf/tolvendev-jboss-cacerts.jks
This cacerts file only contains the self-signed certificate roots needed for demo purposes until a real certificate is purchased from a commercial source. So the solution requires mixing real and self-signed certificates.
To fix this problem manually in an existing Tolven configuration, you need to import the real cacerts into the demo cacets file (not the opposite, though, because that would create a security hole): In the following, the passwords provided are the defaults for both tolven and java. In a command window:
cd C:\tolven-HEAD\tolven-jboss-4.0.4.GA\server\tolven\conf
keytool -importkeystore -destkeystore tolvendev-jboss-cacerts.jks -srckeystore c:\jdk1.6.0\jre\lib\security\cacerts Enter destination keystore password: tolven
Enter source keystore password: changeit
Then restart JBoss
A new CVS module must be extracted into Eclipse (or whichever IDE you use) for inclusion in the Ant build task that creates tolven.ear file. The module is:
tolvenMobileClient
To do this in Eclipse: File > New Project....
Open CVS
select Projects from CVS
Hit Next >
Select the Tolven sourceforge CVS host and path (same as the other Tolven projects).
Select Use an existing module
select tolvenMobileClient module.
You'll need to download and install Sun's Wireless Toolkit 2.5 as well.
Two new CVS modules must be extracted into Eclipse (or whichever IDE you use) for inclusion in the Ant build task that creates tolven.ear file. The two modules are:
tolvenMobileServer
tolvenBrowse
To do this in Eclipse: File > New Project....
Open CVS
select Projects from CVS
Hit Next >
Select the Tolven sourceforge CVS host and path (same as the other Tolven projects).
Select Use an existing module
select tolvenMobileServer and tolvenBrowse and you may also select the tolvenMobileClient module if you want to try building the mobile client from source. (No instructions yet, but I use Sun's Wireless Toolkit 2.5).
These changes are needed for the new security configuration. If you were considering reinstalling "from scratch," now would be a good time to do it. Otherwise, if you have not upgraded since late January, but you want to now, then follow these instructions.
Although it appeared to be controlled by metadata, the page that controls the nine-panel patient summary was ignoring the metadata. Now it correctly determines what to display and in what order from metadata.
The allergy warning icon is now only displayed if there are allergies for the patient. The count of allergies is maintained in the patient menu data item thus a special query is not needed. However, this means the evaluator must keep the number updated.
TRIM templates can now be uploaded to Metadata using the LoadTRIM client (in the new tolvenClient module). It temporarily requires a hard-coded username, password, and account id. It uploads all *.trim from the directory it runs in.
Among other things, TRIM entries can now be displayed in a "menu" of data entry (wizard) forms. However, data entry itself is not yet complete.
Several changes have been made to the PHR to improve the user acceptance. Allergies, medications and observation done by the patient have been added. The data generator has been expanded to support these added data types.
The flow and layout should be clearer now. Separate pages for different functions.
Previously, MenuData referenced attached documents (docBase) as if they were components, using direct navigation, eg
DocBase doc = menuData.getDocument( )
Such an approach usually suggests lazy loading so that the document is only accessed when needed. However, docBase is subclassed. EJB3 (or at least Hibernate) appears not to support lazy loading when subclassed entities are required. In any case, eager loading yields completely unacceptable performance. Therefore, only the document Id is now stored in MenuData.
As a result...
The file tolven/jboss-config/login-config.xml has changed. It can be redeployed to jboss by selecting the ant target deploy-jboss-from-stage.
You may have a foreign key constraint left over from a previous version. It must be removed or MenuData inserts which do not have a document associated, will fail on this constraint. Using pgAdminIII, under the app schema in the postgres database, select the menu_data table. Under constraints, remove the document constraint.
Because of the addition of the jboss-rules library, replace the lower part of resource/ant-build.properties starting with the line:
# Normally, these don't change
with everyhing in the template/ant-build.template file from that same point down. You will see that the jboss-rules library has been included in the list.
In the source code, the data generator is now more streamlined and at the same time tests more of the full data path. Previously, the data generator was directly updating some MenuData (indexes). Now, the data generator simply creates CCR documents and "sends" them to Tolven. These documents are received by a background task (org.tolven.doc.bean.Evaluator) and processed into Tolven using the same code as any real message would use.
Tolven is in the process of creating data entry templates known as archetypes. The underlying structure is based in HL7 V3 RIM and datatypes. This yields two different HL7 RIM packages in Tolven: org.tolven.rim is primarily for messaging, and org.tolven.trim ( templated RIM) used for Archetypes. These objects contains a slightly more granular representation of RIM objects and datatypes. They also allow constraints and specificity needed for data entry. While not yet complete, this note is to make you aware of the coming changes in the area of data entry and "fine-grained" representation of clinical concepts. More information can be found under Architecture Briefs here.
Under the Demo tab, the Debug > Documents list has been changed. Previously it showed documents owned by the account the user is logged into. Now, it shows documents owned by any account the logged in user is a member of. This is a forced security violation for demo purposes only. Normally, a user is not allowed to see documents (or anything) in accounts other than the one they are logged into. This query shows that if that restriction were breached, documents in an account other than the account the user is currently logged into, even if that user is a member of the other account, will not be viewable or computable because the document is encryped. (Note: the encryption feature is not retroactive so existing accounts and users may still find plaintext documents).
The JMS used by Tolven is now configured to be transactional. That is, messages are coordinated with database activity such that a message is not sent until the database transaction it is part of is committed. Similarly, when processing an inbound message, the message is not removed from the queue until the database transaction commits. This behaviour is desired because it avoids inconsistencies between messages and the database.
One difference resulting from this approach is that messages are not sent during a transaction (only if and when the transaction commits). Since most transactions are brief and do succeed, this subtle difference shouldn't be visible. If any code needs to send a message "on the fly" even if the transaction itself rolls back, a separate queue will need to be configured using a non-transactional JMS connection factory (JBoss documentation shows how).
All patient data is now processed via reliable messaging whether from an external source or from a Tolven application. This has several desirable features.
This approach is used because Tolven favors adding additional processing at "update time". This minimizes processing at "query time," which cannot easily be hidden from the user as features are added. This is especially true as rules get more complex such as putting patients on disease lists, looking for alerts, recruiting for clinical trial candidates, etc.
1. The data generator creates data for a personal (ePHR) account but the evaluator currently doesn't populate any visible menus.
2. Radiology reports are created by the data generator but the evaluator currently does not display them on any eCHR screens.
3. Recent lab results are not being added to the New activity lists.
This will be corrected as soon as possible.
postgres-config/indexes.sql can be loaded into pgAdminIII (or the command line tool) to improve query performance. This version of the file adds two indexes to app.menu_data.
Now that the data generator can load any number of patients without crashing, a new tolven.properties value has been added:
tolven.gen.patient.max=1000
This value will limit the number of patients that can be generated at any one time. If you want to add this limit to tolven.properties, heed the advice above regarding changes to tolven.properties.
Also, the data generator is now limited to two threads. This avoids starving the application server for web (interactive user) traffic. The thread count is hard coded - see org.tolven.gen.bean.GenDriver.java to adjust or remove the thread limit.
Since there is no way to be sure an initial user is authentic without email activation, a new feature has been added to the process: When a new login is created using email activation, the underlying invitation is now expired after a certain elapsed number of seconds ( specified in tolven.properties as tolven.register.expiration).
tolven.template has a default of one hour:
tolven.register.expiration=3600
This means that if the user doesn't actually login within one hour following registration, the LDAP entry for that user is deleted and the invitation is marked as obsolete. This feature is necessary in case a user creates an incorrect email address or password. Thus, if the user simply waits one hour after a failed registation attempt, they can start again.
If the value is 0 or the property is not defined, then invitations do not expire.
This feature is also needed to avoid hogging ids. For example, without this feature, bad@guy.com could prevent good@guy.com from registering by simply trying to register with good@guy.com and a password that good would never guess.
To add this property to an existing installation, be sure to edit tolven-jboss-4.0.4.GA/server/tolven/conf/props/tolven.properties and restart the server.
As of Nov 28, significant changes to the menu data for the ePHR and eCHR configurations require that existing users create new demo accounts after they login. The login page contains the same warning.
The test data generator is now called through a MessageDrivenBean. A new jboss queue definition is created for the queue.
For an existing installation, copy the new file gen-queue-service.xml from tolven/jboss-config to tolven-jboss-4.0.4.GA/server/tolven.deploy/jboss-messaging.sar and restart jboss to create this queue.
This queued approach to data generation allows a new account or request to create additional test data on the account admin page to complete immediately. It also guards against transaction timeouts by breaking the requests into smaller transactions. The user should be aware that as a result of data generation occuring in the background, new data may arrive while logged into the application.
The data generator, which now runs in the background, runs faster in part because it no longer generates personal accounts for each clinic patient. You can easily create a personal account with a small family. This is a temporary situation. The data generator is being reworked so that families will contact the clinical account in order to "become" patients.
The background data generator currently creates and loads a large number of families in parallel. If the generator is running in the same app server as the web server, it significantly slows down user performance. This is temporary.
Up until now, accountType (echr-clinical and ephr-personal) were largely hardcoded. This build includes the first major change to move account type to metadata - ie in the database. This requires a migration step for existing installations which is handled automatically in a new application-scope module that handles one-time initialization tasks of this sort.
A number of other account-type-related features will be moved to this meta-data in the near future.
After a new user is created, the user should be brought to the create-account form. Instead, the user was left on a one-line selectAccount page in Mozilla browsers. This is now fixed.
You may notice some new pages and links related to data entry. This work is prototype at this point, intended for usability testing. This is not production-ready code.
With PostgreSQL, it is critical to turn on autovacuum in data/postgresql.conf. We've noticed that in certain situations, a significant performance reduction can occur if vacuuming is not done frequently, especially after the data generator runs.
This build marks the release of the tolven-alpha4 installer.
The installer dependended on JAVA_HOME being set. This dependency has been removed.
DOS line endings had not been removed from deployTolvenEAR.sh causing the installer to fail in the deployment phase.
This tolven-alpha4.jar installer includes all changes described below
For current installations, you must make a change to your configuration or tolven will stop working
Previously, the tolven.properties file was included in the tolven.ear deployment which meant that to change a parameter such as mail server credentials or login options required a re-deploy. It also meant that tolven.ear files were not portable between application servers. To remedy this problem, tolven.properties has been removed from tolven.ear. Instead, it is now deployed separately, within the deploy-from-stage ant target.
For those with an existing developer's installation, you have two choices:
1. Run stage-init-all and deploy-from-stage ant targets and then bounce postgreSQL, openLDAP, and JBoss.
2. If you do not want to disturb the current deployed configuration, including credentials, you will need to do the following:
An advantage of this approach is that properties can be change without interrupting operations. Here's how that is done:
The new properties are immediately available to the application.
Registering a new user (via email activation) wasn't creating an account thus leaving a blank selectAccount screen. The user now sees two new links that allow the user to create a personal or clinical account. Note that the personal account will have no data in it. Therefore, the only realistic account to create is clinical. you should then ask that account to create test data. In addition to populating the clinical record, the test data will also create populated personal records.
Sponsorship provides a means to control new registrations. It is a completely optional feature. If not active, users are free to register a new login without restriction. With Sponsorship enabled, the administrator of an account (the issuer) asks the system for a code which they can distribute as they see fit. Anyone with that code can then create a new Tolven login. The issuer does not need to know the user's login id. The new user is not a made a member of the issuer's account.
Tolven Invitations are different from Sponsorships: Invitations are direct communications between known Tolven users.
The only connection between the issuer and any users that use the code from that issuer is that the issure can get a list of each user's email address, first and last name that used the code to create a Tolven login. The issuer has no access to the user's data in any way.
A new tolven.properties property has been added to support sponsorship. It's name and default value is:
tolven.register.referenceRequired=false
If true, users will be required to provide a "reference code" in order to create a new Tolven Login. (The code is not required to login).
Before setting this flag to true, bootstrapping is needed. Don't set this flag to true until you've logged in, created an account, and in the account administration page created at least one sponsorship reference code. Make a note of this code so you can hand it out to other people. Once you set:
tolven.register.referenceRequired=true
all subsequent registration requests will require a valid reference code. Once a user login is created, the reference code is no longer needed, it is not required to login. But other users may be able to use the same code.
Turning sponsorship off (tolven.register.referenceRequired=false) and on is allowed. When turned off, references already created will be retained but new references will not be needed or asked for.
When returning from AccountAdmin or User Preferences, or Customization, the user is now returned to the main application rather than to the selectAccount page, which was a security issues.
There were some javascript errors, only visible if you allow debugging in IE 6, that have been removed.
If you had trouble changing the root password of LDAP from the default and having trouble getting JBoss to connect, it is now fixed.
Tolven seems to be having trouble running on Fedora Core 5 (FC2, FC3 and FC4 are OK). We have a workaround and will share it if you need it. We hope to resolve the problem soon. Of course if you have Tolven working on FC5, we want to hear from you.
The IzPack installer generator scripts are now checked in. To create a Tolven installation kit, you must install IzPack (IzPack is GPL so Tolven won't include it in the product and does not have any operational dependencies on IzPack). You are not likely to need this capability unless:
Use the Ant build script tolven/installer/build.xml (easiest way is to open it in the Eclipse Ant view). tolven requires a couple source code change to be made to the IZpack kit which can be applied by using the update-IzPack-with-tolven-src Ant target (just one time). That same buildfile can then generate an Installer and run it.
A new line has been added to ant-build.template but this requires a manual update to ant-build.properties. Simply add the following line somewhere in the ant-build.properties file:
commons-lang.location=${tolven.location}/lib/commons-lang
The account title is displayed in the header of the page. If the user has Account Administration permission, an [Admin] link is also displayed. The account name can be changed, data can be generated, etc.
When creating an account, the user has the option of creating a clinical account and/or a personal account. The ePHR has a slightly different configuration which is more appropriate for personal use. It has a different color scheme from the clinical personality.
When new patients are created, the patient is added to the clinic (as usual) and (now) the patient is also created as a user in an ePHR account. Families are created. For example, if husband and wife are both added to the clinical account, then a family account is also created in which the two adults and perhaps their kids records are stored.
The data generates user accounts for each adult patient created. If the name of a patient in the clinical account is sam watson then his user account and password will be:
sam.watson
Sam will have a PHR account typically named something like Watson Family Account in which Sam and his wife will be users and have their medical records. If they have kids, they too will have records in the family account but probably won't have login user ids.
Suggestion: Create new patients in a clinical account. Inspect the patient list noting one or two patients with some interesting data. Log out. Log in with one of the patient's first and last name (as shown above) to see the personal view of that patient.
For someone doing a new install, a new schema will appear in the postgres database. If you're upgrading, you can see the contents of this new schema by manually adding it using the pgAdminIII tool. Go to the postgres database, right mouse on the schemas line and select New Schema. The name of the schema should be ctom. The next time you restart jboss or deploy Tolven, a number of new tables will be added to the database under this new schema. The tables are not currently being used except for some testing so you can ignore this schema.
In a chicken-or-egg scenario, we (actually Joe) checked in the source for the new Tolven platform-independent GUI installer. The new installer eliminates a number of steps and shortens the installation time. But this isn't the installer, it is the code that creates the installer. Look for an announcement of the first Tolven installation kit soon.
The ant script that copied LDAP credentials, *.pem, was not copying them from the correct location. This has been fixed.
The install script is designed to use existing credentials if they already exist. The first place where this approach is used is for the PostgreSQL clients such as PGadminIII. this behavior is controlled by the ant-build.property:
tolven.stage.use-existing-pg-client-cert=true
Previously, setting this flag to true would imply that there were existing credentials. No credentials would be created. Now it means use existing credentials if they exist, otherwise it creates new credentials.
The JBoss application server and messaging service are now a bundled library within the Tolven install. This removes a couple pretty major and error prone steps from the install process. However, for existing installations, there's some work you'll have to do.
The download for this build will take a bit longer than usual: it includes a 43MB zip file containing JBoss that will be added to the tolven/lib directory.
Here's what you need to do for this build to work on an existing install:
You can delete the old Jboss installation (eg c:/jboss-4.0.4.GA) if you wish.
* The password answers, if you use those suggested in the install guide, are: 1) tolven, 2) secret, 3) tolven, 4) postgres, 5) tolven
[Not Recommended] If you download this build (or anything newer) but defer the procedure above, then before deploying, you'll need to make a small, temporary change: edit tolvenEJB/conf/persistence.xml and change DefaultDS back to tolven-ds, save it, then deploy.
In this release, the in-memory database commonly used as a placeholder for a real database, has been completely removed from the jboss configuration. At the same time, the tolven datasource configuration was renamed from tolven-ds back to DefaultDS so that all components (JMS, Timer, Quartz, etc) not just tolven, know to use the official database.
Once you have upgraded to this version of the software and stage-init-all has been run at least once , you can run the following ant target sequences at any time, taking into account undeploying tolven.ear and shutting down the servers before starting.
Sequence A (Create new credentials and staged configuration):
Sequence A refreshes the system to its original configuration based on settings in ant-build.properties, but with new credentials. PostgreSQL data and LDAP data are unaffected. Only the stage directory is deleted and then populated with new credentials. Therefore, running this sequence alone has no affect on a running system, only the stage directory. You can review the tolven/stage directory to insure everything is in order before deploying.
Sequence B (deploy staged changes to servers):
Sequence B deploys the configuration from the stage to the servers. It will copy configuration files from the stage directory to the LDAP, PostgreSQL and JBoss servers. Say you installed a new LDAP server and reconfigured ant-build.properties and tolven.properties if needed to point to this new installation. This sequence will ensure that all of the servers are configured properly according to the stage, including the new LDAP server. This target does not add, modify or delete any data stored inside LDAP or PostgreSQL servers. Nor does it do any data migration.
Sequence C (Change passwords and/or password encryption):
In Sequence C, stage-init-merge-credentials is the task that protects any passwords that are used to authenticate each of the servers to each other. It uses a salt and hash algorithm to encrypt passwords. This sequence doesn't modify the certificates. Running this sequence will reset the passwords and how they are encrypted. It then deploys those changes to the servers.
Sequence D (Create new certificates, set the passwords protecting them, deploy the results to the servers):
The new target in Sequence D is stage-init-generate-credentials which, as the name implies, creates a completely new set of credentials, rests the passwords that protect those credentials, which is required, and then deploys the results from the state to the servers. If you omit the deploy-from-stage step, then the changes will be standing by in the stage for when you decide to deploy-from-stage. Reminder: deploy-from-stage is about configuration files whereas the deploy target deploys the tolven application to JBoss.
Sequence E:
Added more echos to the process. Removed the download task which wasn't working anyway and is no longer needed.
The login page has two different registration links, one for a normally activated login and the other creates a demo user without needing email activation. Two tolven.properties have been added which allows you to configure either or both of these options off. (Turning both off means users can only login to pre-existing accounts). For example, the following settings remove the email-activation step.
tolven.login.create.demoUser=true
tolven.login.create.activatedUser=false
The two kinds of user registration pages are now separate pages with no check boxes or options. The fields are now customized to the type of registration. For example, creating a demo user account has a separate username (which is NOT an email address) and an email mail address field which is not verified. The full email-activation page, on the other hand, requires an email address as user id and it verifies the address via email.
The circled links can now be separately controlled by options in tolven.properties.
The existing registration form.. Notice the "skip activation option" is removed and no longer needed.
Creating a new demo user avoids email activation.
Technical changes: Instead of the invitation id being queued, the whole invitation is now queued as an object and persisted during the sendInvitation onMessage process. This eliminates transaction synchronization issues and is better suited to distribution of this background process. This should fix intermittent activation issues.
The default context root is /Tolven (eg http://mydomain.com/Tolven). you can change it to anthing you want including "/" (the leading "/" is required).
To change the tolven context root, do the following:
As shipped, Tolven listens on port 8080 for HTTP and 8443 for HTTPS.
To change to port 80 and 443 so that the URL doesn't require a port specification, you will need to ant-build.properties and also tolven.properties.
In tolven/resources/tolven.properties, replace 8080 with 80 and 8443 with 443.
Do the same in tolven/resources/ ant-build.properties
After editing these two files, you'll need to:
Added a checkbox to the SelectAccount page that will cause demo patients to be generated as the user logs into the account. This can be repeated: Each time the user checks the box while logging in, 100 more patients will be added to the account.
The "Generate test data" option has been removed from the registration form. This checkbox was not active but was misleading.
An arbitrarty number of random patients can also be added in the Account Administration form (you get to this form from the User Preferences form).
When displaying dates and times, Tolven uses the following algorithm to determine which timezone to use:
If you specify the timezone in tolven.properties, use the fully specified timezone format such as one of the following for correct daylight savings time handling:
tolven.timezone=America/Los_Angeles tolven.timezone=America/Phoenix tolven.timezone=America/Denver tolven.timezone=America/Chicago tolven.timezone=America/New_York tolven.timezone=Europe/London tolven.timezone=Europe/Paris tolven.timezone=Asia/Singapore tolven.timezone=Australia/Sydney etc
A bug uploading the user's photo with Firefox has been fixed. Also, the user preferences screen has been rearranged a bit. If the user is allowed to administer the account they are logged into, the user is offered a link to administer that account such as to change the account title.
A new account administration page has been added. This allows an account administrator to view users allowed to use that account, to change the administrator flag on those users, and to add new users to an account. (Note: A user is not a patient - they are completely separate although in some cases can be the same person).
If the account administrator is a demo user (see below), then that user is only allowed to add other demo users to the account. Demo users being added will be validated but are not revealed in a list.
[This will be added in the next build]If the account administrator is not a demo user (user id of the administrator is a real, activated email address), then only other activated user can be invited to join the account. This official method of inviting users requires that the user to be added receives and accepts an invitation to join the account. The invited user may already exist in Tolven or may be a new user. The person doing the inviting is not allowed to know if the invitee already exists in Tolven or not. The only indication if the invitation process was successful or not is if the invited user receives the invitation, creates a tolven account if not already done, and accepts the invitation.
On the register new user form, if the "demo" flag is set (skip the email activation), a permanent flag is set in the user's record. Setting the demoUser flag false means emails will never be sent to that user for any reason.
This new column requires a one-time initialization. I've included a simple script that looks for an embedded @ in the UID field to indicate if the account is a demo account or not and sets the flag accordingly.
update core.tolven_user set demo_user = false where uid like '%@%'; update core.tolven_user set demo_user = true where uid not like '%@%'; select * from core.tolven_user;
Or, you can unconditinally set all accounts to be demo accounts, as follows.
update core.tolven_user set demo_user = false; select * from core.tolven_user;
If you do not initialize this column, Tolven will throw an error when logging into an existing account.
If you use PGadminIII to do this, select the Execute arbitrary SQL Queries button
And paste or enter the SQL to execute. Press the green arrow to execute.
Data Grids now supports column value supression. Each sorted column can have it's own range of columns that participate in suppression. The first row of any table never supresses column values. See five/dispats.xhtml for an example of how it's setup (the changes are in rico.js). The following shows the disease column with supressed values.
The data generator now varies the variability of result values in lab scenarios. Thus, one patient might have values in a tight range throughout the scenario while others might see wild swings in certain results. See DiabetesGen.java for an example.
Hitting the enter key on a filter field no longer navigates to an arbitrary pane. Since filters are activated by time, the enter key now has no effect in the filter fields.
Previously, the data generator only generated index data. In the case of personal info (name and address) for the patient, CCR is now used. This technique demonstrates a round trip of CCR XML data into and back out of Tolven's document store. A demo-only XML menu has been added that allows the user to see the CCR associated with the current version of the patient demographics.
Additional CCR validations have been added. Validation errors will be thrown as CCRException and may reference the relevant section of the standard. The XML schema covers many structural constraints but the written standard specifies a number of other constraints).
There is a noticeable delay (1-2 seconds) the first time the first user after a server boot accesses any particular XML schema as large as CCR. This is a one-time cost per binding context (Tolven has three at the moment: CCR, RIM, and Admin). Since server reboots should be rare, it is being left as is.
Moved to JAXB 2.0.2 release.
On Firefox, opening, closing, and then reopening that same patient would not display the summary properly. This was due to the close of a patient not removing all traces of the patient from the browser and so a subsequent display would think parts of that patient's record was already displayed. Note: This was not a security problem, logging out or closing the browser unconditionally removes everything from the client system.
Garbage characters have been removed from the title bar display, especially when a patient was in focus. The null characters were showing as a series of small boxes.
This ant target in tolven-securty was not working properly.
> The JBoss server no longer shuts down cleanly. You'll need to force it to stop (Close button + End Now) We're looking into this.
> Filters on the various lists do not require you to hit the enter key. If you do hit the enter key, unpredictable things occur.
> The installation script has changed. The init-external-dependencies Ant target will
The Installation Guide will be updated to advise you that Ant may not have access to the Java compiler. To remedy this: Window>Preferences. Under Ant>Runtime, under the classpath tab: Open Global Entries and add something like
f:\jdk1.5.0_06/lib/tools.jar
if a tools.jar is not already there.
> This build fixes a problem introduced in the last build where Tolven is unable to connect to the LDAP server when creating a new user (or updating user preferences). If you're not experiencing this problem, there's nothing to fix. If this build is your initial download, you won't need to worry about it.
The change is to remove one line and adds two lines in:
jboss-4.0.4.GA/server/tolven/deploy/tolven-ldap-service.xml
The first <mbean> in that file should look like this (just paste this over the one that's there). Leave the other <mbean>. It won't be used but must be present. Notice the embedded ldap password. If yours is different, use that password.
<mbean code="org.jboss.naming.ExternalContext"
name="jboss.jndi:service=TolvenLDAPContext,jndiName=tolven/ldap">
<attribute name="JndiName">tolven/ldap</attribute>
<attribute name="Properties">
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url=ldaps://localhost/
java.naming.security.principal=cn=Manager,dc=tolven,dc=com
java.naming.security.credentials=secret
</attribute>
<attribute name="InitialContext">
javax.naming.ldap.InitialLdapContext
</attribute>
<depends>jboss:type=Service,name=TolvenSystemProperties</depends>
</mbean>
This is a temporary fix - returning to a plaintext password for LDAP. The connection itself is still secure and not affected by this change.
> Security password prompts. The password prompts in the ant build target init-external-dependencies.xml can be a bit confusing. It will ask for three passwords, sometime more than once. If you used the same passwords as suggested in the install guide then:
Database password: postgres
LDAP password: secret
Keystore passwords: tolven
This is a one-time script. you will not need to rerun it when you pull fresh source code and redeploy.
> The installation step that requires you to manually change changeit to tolven (the keystore password) in two file is still required. We'll post whern this requirement is no longer needed.
> An error would often occur when a session timed out after about 5 minutes. Errors usually had something to do with transactions. This problem has been corrected.
> This link often messes up the radiology results page. Fixed. Navigating from the summary to full list now works as expected.
This page displays empty but will contain activity for the patient.
The demo data generator will now only put recent activity on the New Activity list (occuring within the last ten days or so).
Added a new library, jfreechart, which is used to graph lab results. Follow the gen procedure to create some data so you can see the first configured chart (which happens to be for lipids). This graph feature is preliminary: It is slow (0.250 seconds on my system is slow by Tolven standards) and is cached in a flat file instead of the database. Also, configuration is not yet exposed in the UI.
If you're updating from a previous build, this library needs to be added to your ant-build.properties file. Just paste:
jfreechart.location=${tolven.location}/lib/jfreechart
in a new line somewhere in that file.
The generation procedure has expanded to include some new scenario-generating capabilities. This won't be documented for a while but you can get a bit of an idea how it works by looking at the example in
tolvenEJB\src\org.tolven.gen.bean\DiabetesGen.java
If you're installing fresh, you won't realize that some of the plain text passwords have been removed from configuration files. There are now just two more to go and they should be gone soon.
If you are updating, you may want to do a full tolven-security build and tolven/init-external-dependencies as described here in order to see the results of the improved security configuration. Or, if security is not critical right now, you can just leave all of the certificates and password files alone and do not run the init-external-dependencies Ant target.
Most of the source modules were updated this weekend. These changes were clerical - no functional impact.
© 2006 Tolven Inc.