MSS Code Factory 2.1 Release History

2015.06.23 MSS Code Factory 2.1.12904 Refactored CFBam 2.2 model

The CFBam 2.2 model has refactored the ServerProc specifications such that there is now a ServerMethod table from which ServerProc, ServerObjFunc, and ServerListFunc derive. The new ServerObjFunc and ServerListFunc specifications can now specify an arbitrary RetTable which defines the type of return value they provide.

Eventually this will be used to provide read-like semantics for the Funcs, allowing them to return relatively arbitrary data sets instead of just a boolean "DataChanged" flag as with the Procs.

2015.06.10 MSS Code Factory 2.1.12881 Tweaked CFBam 2.2 model

Rather than calling the ServerProc contents just "Body", I renamed it to "JProcBody" in keeping with the other customization attributes of the models. After all, some day I do intend to support languages other than Java, so it'll be necessary to specify which language a body is for.

2015.06.09 MSS Code Factory 2.1.12878 Corrected defect in Swing code

There was a missing dereference for a Relation in the AttrJPanel code, which has been corrected. It was only discovered because I finally have some sample code that chases a full 4-level PopDep specification.

2015.06.09 MSS Code Factory 2.1.12876 CFBam 2.2 model enhanced

The CFBam 2.2 model has been enhanced with the new elements and objects required to specify server procedures, which is the feature I'm working on adding to 2.2/2.3. There is also a possibility that 2.1.12868 had a packaging error, so you should use this version instead.

2015.06.05 MSS Code Factory 2.1.12868 Rebuilt with JDK 8

Along with rebuilding with JDK 8, a couple of warning suppressions have been added to the rule base so that the XMsgRspn and XMsgClient layers now compile without complaint.

2015.06.05 MSS Code Factory CFCore 2.1.12867 Rebuilt with JDK 8, error corrected

There was a missing function in the log implementation for CFCore which has been corrected.

2015.06.05 MSS Code Factory CFLib 2.1.12866 Rebuilt with JDK 8, many warnings cleaned up

With the shift to JDK 8 for the next versions of MSS Code Factory, I took the time to clean up a plethora of warnings in the CFLib 2.1 code while making sure there were no deprecated or unchecked conditions in the code.

2015.06.01 MSS Code Factory 2.1.12863 Promoted to stable and plans for 2.2/2.3

I've decided to make 2.1.12863 my "stable" release, and begin work on the next features I want to add with the 2.2 code base.

2015.05.31 MSS Code Factory 2.1.12863 Service Pack 2 released

MSS Code Factory Service Pack 2 adds support for an XMsg-based HTTP Swing Prototype GUI client, replacing the older client-server implementations.

The client now implements an import facility based on the SAX loader dialects, which lets you import an entire file as a single transaction at the server end, improving overall import performance while detaching the import process from requiring data center access.

Full CFTip privacy is implemented by the HTTP client. Note that at this time there is the possiblity of a man-in-the-middle attack wedging a fake server between the client and the real server, because there is no verification of the certificate chain for the server key implemented at this time.

You can no longer add or delete clusters using the GUI. Normally there are only two clusters in existence: system and the default cluster for the collection of service hosts.

2015.05.31 MSS Code Factory 2.1.12861 Completed removal of Cluster Add/Delete support for Swing prototype GUI

The final vestiges of the Add/Delete support for clusters has been implemented and tested.

I've decided against making similar changes to the Tenant Add/Delete support at this time (mainly 'cause I'm just feeling too lazy to work on it at this time and I want to get the service pack out the door today.)

That leaves the manufacturing of security initialization import files before I issue the service pack.

2015.05.30 MSS Code Factory 2.1.12859 Corrected error in XMsg response XSD

There was a missing "Type" suffix in the XSD for XMsg response documents. I still need to remove the "Delete Cluster..." menu item in the View/Edit window for clusters. Then I can move on to dealing with Tenants.

2015.05.30 MSS Code Factory 2.1.12858 Disable Add and Delete for Cluster in Swing Prototype GUI

I disabled the "Add" and "Delete" functionality for Clusters in the Swing Prototype GUI.

2015.05.30 MSS Code Factory 2.1.12856 Rebuilt with CFLib 2.1.12855

Just a refresh to keep things in sync.

MSS Code Factory 2.1.12855 Corrected production of encoded character sequences

I was mistakenly using an API to convert a (presumedly decimal) character to a numeric value instead of just casting to get the character code to be emitted for XML. I've also eliminated the use of the formatter objects, which should further improve the performance of the conversion. Just tweaks and fiddling, but it's been bugging me for a day or two that the code wasn't quite right.

MSS Code Factory 2.1.12853 Remote file imports work with CFLib 2.1.12852

The latest and greatest.

2015.05.28 MSS Code Factory CFLib 2.1.12852 Another minor bug fixed

@ has to be passed through unmolested.

2015.05.28 MSS Code Factory 2.1.12851 Repackaged with CFLib 2.1.12850

This latest version of CFLib corrects some parser tracebacks that can occur when there are problems parsing an XSD before the log is initialized.

2015.05.28 MSS Code Factory CFLib 2.1.12850 Chased down an old bug with the SAX Parsers

If the log was not properly initialized, the SAX parsers could throw exceptions during their messaging callback invocations, which weren't allowing for a null log.

2015.05.28 MSS Code Factory 2.1.12848 Repackaged with CFLib 2.1.12847

The code factory has been rebuilt and repackaged with the latest CFLib 2.1.12847.

2015.05.28 MSS Code Factory CFLib 2.1.12847 Corrected emission of numeric character elements

The XML string formatters now properly convert a character code to a numeric value, and from there format it as a decimal integer in an &999; XML attribute string. By some fluke, today was the first time that particular piece of code has ever fired.

2015.05.28 MSS Code Factory 2.1.12845 Added code to load file contents for import

The file contents have to be loaded before they can actually be imported.

2015.05.28 MSS Code Factory 2.1.12842 Life, the Universe, and Everything: Latest rules cleaned up

There were still some occurances of CFDbTest from migrated code in the rule base which was causing CFSecurity 2.2 to fail to build. Those occurances have been replaced by $SchemaName$ as appropriate.

CFSecurity now builds cleanly and is awaiting packaging.

CFDbTest 2.2 will be refreshed shortly.

2015.05.28 MSS Code Factory 2.1.12840 FileImport window ready for testing

The FileImport window is ready for testing. I'll be refreshing the code base for CFSecurity next, and using that client running in an Eclipse debug session against a back end CFDbTest 2.2 XMsg server also running under an Eclipse debug session.

2015.05.28 MSS Code Factory 2.1.12838 Code defect corrected; CFDbTest 2.2 builds clean now

There was a problem with the specification of a message logger that didn't implement the new getBacklog() interface method in the request server. This has been corrected.

2015.05.28 MSS Code Factory 2.1.12836 fileImport() signature now returns string log contents

The log contents resulting from the import parse are now returned by the various fileImport() implementations. The XMsgRspnHandler has seen the addition of a LogContents attribute which is used to capture the output provided by a RspnFileLoaded message.

I'm ready to start working on the import window itself.

2015.05.28 MSS Code Factory 2.1.12834 SchemaObj.fileImport() method added and wired

I've added an ImportFileRqst message that takes a file name and a text body as parameters, and an ImportFileRspn message that contains a text body for the parser output. These exist as the elements RqstFileImport and RspnFileLoaded in the request and response XSDs, respectively.

Then I need to add the appropriate wiring to the request and response XMsg formatting layers.

I've added the RspnFileLoaded element handler and wired it to the response parser.

I added the RqstFileImport element handler, and wired it to the request parser.

The RqstFileImport processor instantiates an XML SAX Parser, using the SecCluster and SecTenant the parameter Authorization to apply the FileContents argument to the parser.

Any log messages produced by the parse are captured and sent back to the client, although the client currently doesn't pass back that information to the caller. (It will eventually.)

I've also wired the accessor methods from the SchemaObj to the backing store implementation of the fileImport request processing.

Note that the SAX Loader is capable of parsing any of it's referenced SchemaDefs as well as the main SchemaDef of the project. This allows you to import lookup data from component applications.

2015.05.27 MSS Code Factory CFLib 2.1.12833 Added getBacklog() method to logging interface and implementation

I need to be able to access the backlog from a server-side SAX XML Parse in order to complete the processing implementation.

2015.05.27 MSS Code Factory 2.1.12831 Regression test of PostgreSQL SAX Loader passed

The regression testing and corrections for the PostgreSQL SAX Loader has been regresssion tested and now loads the cluster and tenant information as specified through the updated command line argument parsing.

Now the loader truly provides a data import facility for Cluster and Tenant owned information.

2015.05.27 MSS Code Factory 2.1.12829 Cluster and Tenant now restricted by SAX Loaders

The SAX Loader's Cluster argument is now restricted to "system" or "default", and the Tenant argument subsequently restricted for a "system" Cluster as well (the "system" Cluster only contains one Tenant, the "system" Tenant.) The Tenant must exist within the Cluster prior to running a loader session for that Tenant; you cannot create a Tenant with this implementation of a SAX Loader.

Loading the client configuration object now clears the buffer variables for re-resolution by the next invocation of their getters.

The client configuration file is refreshed/reloaded when opening a login window.

2015.05.26 MSS Code Factory 2.1.12827 20-entry Server URL history provided

The client configuration file object has been modified to store an ordered list of ServerURL entries, keeping the most recently used entry in position 0. The list contains up to 20 entries (0..19.)

The Swing prototype GUI Login form has been updated to display this information in an editable combo box for the ServerURL. It allows the entry of arbitrary new Server URL values, posting the most recent entry to the client configuration file whenever a new entry edit is complete, and using the selected Server URL to establish the connection to the server.

2015.05.19 MSS Code Factory 2.1.12825 Use combobox for Cluster in Login form

The Swing GUI prototype login form now uses a combo box to let you choose between the default and system clusters. If you choose "system", the Tenant is forced to system as well and made read-only. If you choose "default", you are allowed to specify a Tenant.

2015.05.15 Programmer's Notes

Before I issue the next service pack, there are a few items I'd like to address.

I want to modify the GUI so that the Cluster is a choice box between "system" and "default", initially set to "default", as those are the only two valid values. If "system" is selected, the tenant should also be forced to "system" and made read-only. [completed 2015.05.19 2.1.12825 MSS]

The client configuration file object has been modified to store an ordered list of ServerURL entries, keeping the most recently used entry in position 0. The list contains up to 20 entries (0..19.) [completed 2015.05.26 2.1.12827 MSS]

The Swing prototype GUI Login form has been updated to display this information in an editable combo box for the ServerURL. It allows the entry of arbitrary new Server URL values, posting the most recent entry to the client configuration file whenever a new entry edit is complete, and using the selected Server URL to establish the connection to the server. [completed 2015.05.26 2.1.12827 MSS]

Next I want to do some enhancements for the XML SAX loaders. [completed 2015.05.27 2.1.12831 MSS]

As with the GUI, the Cluster argument needs to be restricted to "system" or "default", and the Tenant argument subsequently restricted for a "system" Cluster as well. Selecting either cluster needs to store the cluster to be used in the SAX parser data, and whenever a Cluster is encountered during a SAX parse, that selected cluster needs to be used instead of the one specified by the SAX data. [completed 2015.05.27 2.1.12831 MSS]

Similarly, the specified Tenant needs to be used instead of the encountered Tenant. [completed 2015.05.27 2.1.12831 MSS]

This will allow the creation of generic data load sets that can be imported to any Cluster/Tenant name space. In particular, I want to be able to generate security initialization data that can be loaded for a new tenant rather than having to construct the security information by hand as you currently have to do. [completed 2015.05.27 2.1.12831 MSS]

Once that's done, I'm going to look into the feasability of adding a password argument to the SAX loaders, and enforcing user/password verification. While I don't want to get away from the configuration file specifying the account and password for connecting to the database, I *do* want to provide at least some minimal validation that someone running the import tools is authorized to do so. I also want to capture a session entry that owns all the history data for the load process. [cancelled, will not do for this service pack, if ever]

The SAX loaders are only intended to be runnable from within the data center. I presume that the database server is only accessible to machines from within the cluster, not machines in the department or office, much less the user community on the internet. My architectural model is that all user access to the database is to be performed from a client application, not from a directly connected client. [nothing to do; just notes]

I'm going to add an "Import" facility available from the GUI. [completed 2015.05.30 2.1.12856 MSS]

I've added an ImportFileRqst message that takes a file name and a text body as parameters, and an ImportFileRspn message that contains a text body for the parser output. These exist as the elements RqstFileImport and RspnFileLoaded in the request and response XSDs, respectively. [completed 2015.05.27 2.1.12834 MSS]

Then I need to add the appropriate wiring to the request and response XMsg formatting layers. [completed 2015.05.27 2.1.12834 MSS]

I've added the RspnFileLoaded element handler and wired it to the response parser. [completed 2015.05.27 2.1.12834 MSS]

I added the RqstFileImport element handler, and wired it to the request parser. [completed 2015.05.27 2.1.12834 MSS]

The RqstFileImport processor instantiates an XML SAX Parser, using the SecCluster and SecTenant the parameter Authorization to apply the FileContents argument to the parser. [completed 2015.05.27 2.1.12834 MSS]

Any log messages produced by the parse are captured and sent back to the client, although the client currently doesn't pass back that information to the caller. (It will eventually.) [completed 2015.05.27 2.1.12834 MSS]

Next up is wiring accessor methods from the SchemaObj to the backing store implementation of the fileImport request processing. [completed 2015.05.27 2.1.12834 MSS]

I created and wired a FileImport window for the GUI that uses the SchemaObj.fileImport() method. Ready for testing. [completed 2015.05.28 2.1.12840 MSS]

I disabled the "Add" and "Delete" functionality for Clusters in the Swing Prototype GUI. [completed 2015.05.31 2.1.12861 MSS]

I want to modify the Tenant forms so that you can only add Tenants to the default cluster, not the system cluster. The system cluster is a special case and should never have user data associated with it. I don't look forward to implementing this. It's going to be an ugly snarl of rules after seeing what I had to do just to disable/remove code for the Clusters. Now I need to implement special-case code for Tenant tables instead of just adjusting default behaviours. [cancelled/deferred]

I'm not sure how long it will all take to do, and there is no guarantee I won't change my mind about incorporating some of these features, but that's the plan for now.

2015.05.15 MSS Code Factory 2.1.12823 Leaking connections fixed

I've added a SchemaPooledObj which derives from SchemaObj, but does not disconnect the backing store during a logout. This prevents the leaking connections that I was seeing with the web services. CFDbTest has been used to exercise and verify the new code.

2015.05.15 MSS Code Factory 2.1.12821 HTTP Client debugged

The HTTP Swing Prototype GUI client can now connect to an XMsg request web service, and process the database I/Os for the session. The connection of a downlevel client such as CFSecurity talking to a CFDbTest server has also been tested.

There is still some cleanup I want to do before the next service pack, but this build is ready to use.

I suspect the database wrapper pool is leaking connections, though -- when I login again, the cnx is null after retrieving the connection from the pool. That indicates that the logout is disconnecting the backing store for the database. That shouldn't be happening.

However, it only results in performance issues, not a failure of the code. I'll work on it later before the next service pack.

2015.05.14 MSS Code Factory 2.1.12820 HTTP Client ready for testing

The HTTP client code clean compiles and has been partially tested (just with a bogus server URL, which causes an appropriate error dialog to be displayed.)

The client doesn't successfully log in to the web server yet, but it will soon enough.

The various database-specific Swing GUIs will no longer run and should be removed from your projects. The Swing HTTP GUI takes over for all of the databases, switching the system over to the web client approach that has been my goal for the past year or so.

2015.05.03 Programmer's Notes

I just caught a lucky break. It turns out that http://hc.apache.org/httpcomponents-client-ga/ does just what I need: provide a simulate browser client with cookie/session support for Java. It shouldn't take nearly as long as I'd expected to web-enable my client GUI.

2015.05.01 MSS Code Factory 2.1.12818 X(ml)Msg servers now respond in the correct dialect

The dialect document for an X(ml)Msg response now properly identifies the document associated with the request, rather than defaulting to the hard-coded schema definition of the server. This will allow clients of downlevel projects (e.g. CFSecurity) to talk to a server that imports or references their schema definition.

Of course there are limits as to how many features you can import into a given schema, due to limitations of Java itself. Should Java ever make a wholesale switch to 64-bit attributes including code page sizes, it would be possible to import a virtually unlimited set of schemas to a given corporate deployment project.

However, that day has not come yet.

2015.04.29 Programmer's Notes

There is a flaw in the X(ml)Msg implementation right now. The responses are hard-coded to use the server's primary dialect when responding to an XMsgClient.

That is incorrect behaviour. The document root element of the request message parsing should parse out the Rqst portion of the root element name, and apply the $SchemaName$ to an attribute of an XMsgSchemaFormatter instance. The response preamble needs to retrieve that attribute and use it to prepare the XML document header of the response such that the response is in the same dialect as the request was made in. This will allow, for example, an implementation of the CFSecurityXMsgClient to talk to any project manufactured by MSS Code Factory, as all projects at a minimum extend CFSecurity 2.2 (which is released under a BSD 3-clause license, as are CFInternet 2.2 and CFCrm 2.2.)

The response postamble/end-document tag writer also need to use the attribute associated with an XMsgSchemaFormatter instance.

The XMsgSchemaFormatter instance will be associated with an XMsgRqstHandler, which is already wired throughout the XMsgRqst implementation as the container for the element handlers, so the new attribute can be referenced from anywhere in the implementation.

A new instance method will be added to the XMsgRqstHandler, getSchemaName() and setSchemaName(), which will get and set the value of the component XMsgSchemaFormatter instance attribute.

All references to the schema name in the response formatting code will then be modified to use the current value of XMsgRqstHandler.getSchemaName() instead of hard-coded values as are currently specified.

The request handler will need to be modified to parse out the SchemaName of the request root document element, and apply that mixed-case value to XMsgRqstHandler.setSchemaName(). As long as the request document element root element has a name following *Rqst, it's response document will reference the client application's interface specification.

For example, the CFSecurity client application would issue requests and expect responses within the CFSecurity namespace defined by the CFSecurity schema specification. The server-side envelope and request processing code would initialize the XMsgRqstHandler.setSchemaName() to the top-level schema name of the deployed application specification -- for example, "CFDbTest".

On each request made by the CFSecurity client application, the "CFSecurity" schema namespace would be applied and referenced throughout the processing of the request, including any exception processing that occurs after the schema name has been applied.

2015.04.29 MSS Code Factory 2.1.12816 ICFLibThrowableFormatter interface implemented

The $SchemaName$XMsgRqstHandler has been updated to implement ICFLibThrowableFormatter, and to wire itself to the CFLibEnvelopeHandler that it is associated with whenever the envelope handler is specified. There are no changes required to higher level code such as the database-specific mains or the HTTP request processing page handler. There should no longer be unreported exceptions producing empty responses except for bad security key handshake data. But as long as you're relying on the CFLib implementation of the handshake, you should be safe from having to deal with empty responses.

2015.04.29 MSS Code Factory 2.1.12815 Switched to CFLib 2.1.12814

The factory and the manufactured code have been updated to reference CFLib 2.1.12814 instead of 2.1.12803. Next I'll modify the rules to make use of the new callback added to the envelope handler so that all possible exceptions are reported back to the client. Only an invalid envelope document should result in empty documents being sent back to the client once the changes are complete.

2015.04.29 MSS Code Factory CFLib 2.1.12814 Added ICFTipThrowableFormatter processing

The interface for an exception-formatting callback has been defined and wired to the CFTip runtime library code. There should no longer be any cases where exceptions caught by the system are not passed back to the client as application exceptions appropriately encrypted by the Envelope processing code.

If you don't submit a valid Envelope for processing, of course there are undefined exceptions produced, but there is no way to avoid that. Sooner or later there just isn't enough information available to define a valid response, and an empty page has to be sent instead.

2015.04.16 MSS Code Factory 2.1.12812 Service Pack 1 repackaged to correct licensing

Service Pack 1 of MSS Code Factory 2.1 brings transport independent privacy into the code base, and corrects some defects that were discovered during the development of the new code. The common portions of the new code have been tested using PostgreSQL, and the changes made to the top-level PostgreSQL Swing GUI prototype mains have been propagated to the other databases (the only difference between each of them are the names of the configuration files and the initial values applied to the configurations.)

The repackaging of service pack 1 changes the licensing on the core projects (CFSecurity, CFInternet, and CFCrm) to a BSD 3-Clause license, which is better suited to allowing users of the tool to restrict the licensing on their manufactured code as they see fit. The Apache 2.0 license apparently does not allow more restrictive licensing.

The core libraries/jars CFLib and CFCore remain under an LGPLv3 license, as they are not remanufactured or modified by MSS Code Factory to produce an application's code.

2015.04.16 MSS Code Factory CFBam 2.1.12811 Extended license text to 4000 characters

The restrictions on the license text have been manually extended to 4000 characters; the database creation scripts are unlikely to work as a result for most of the databases. Proper replacement of the StringCol specifications with TextCol specifications has been done for CFBam 2.2.

2015.04.16 Programmer's Notes

Hmmm. It would seem I'm going to have to re-license my core Apache projects under the BSD 3-clause license.

https://www.apache.org/licenses/GPL-compatibility.html

https://www.gnu.org/philosophy/license-list.html

I think this http://directory.fsf.org/wiki/License:BSD_3Clause would be a better license, as my sole goal for the Apache-licensed core projects (CFSecurity, CFInternet, and CFCrm) is to require that credit be provided.

I think what I really need to do is provide a "LicenseCredit" attribute in my models, where the "LicenseCredit" text is automatically included in the headers produced for any project which imports the model. I don't that will happen until the 2.2 release, though.

The older Apache licenses (1.0 and 1.1) are not compatible with the GPLv3, but the current 2.0 version is. However, the Apache organization does not allow it's software to be redistributed under a more restrictive license, an interpretation which is incompatible with my goals. That's what is leading to my plan to relicense the core projects.

The core CFLib and CFCore libraries can remain under the Apache v2.0 license because they do not get modified during the manufacturing process; it's the CFSecurity, CFInternet, and CFCrm project licenses that are of a concern.

I may be releasing a "Service Pack 2" in short order just to address these licensing concerns, as well as to implement a minor change to the CFTip interface that would capture and report on any exceptions that occur during the request parsing process, not just the request *processing* process as happens currently.

When an exception occurs during parsing of a request, CFTip currently responds with an empty document, giving no feedback to the client application. I don't like that. There should always be information provided about any problems that are encountered.

You should also be aware that the current implementation of CFTip might be susceptible to a man-in-the-middle attack, because the certificate chain of the server is not verified. So one could insert a server between you and the actual provider of the service that provides it's own public key to your client, decrypts your messages, and forwards them to the actual server for processing, receives the responses, decrypts them, and then re-encrypts them using it's own private key to forward to you.

This isn't a design flaw; it's just that I don't intend to implement certificate validation until I have dealt with implementing an actual web-based deployment. For environments which don't deal with the web, but which rely on MQ Series or some such for messaging, it should be just fine.

2015.04.13 MSS Code Factory 2.1.12808 Service Pack 1

Service Pack 1 of MSS Code Factory 2.1 brings transport independent privacy into the code base, and corrects some defects that were discovered during the development of the new code. The common portions of the new code have been tested using PostgreSQL, and the changes made to the top-level PostgreSQL Swing GUI prototype mains have been propagated to the other databases (the only difference between each of them are the names of the configuration files and the initial values applied to the configurations.)

Please, download and enjoy.

2015.04.13 MSS Code Factory 2.1.12806 Correct Base64 encoding

The rules now specify to use "new String( Base64.encode( val ) )" instead of "Base64.encode( val ).toString()".

2015.04.12 MSS Code Factory 2.1.12804 CFTip now works with the PostgreSQL Swing GUI prototype

The CFDbTest 2.2 Swing GUI prototype for PostgreSQL has been used to debug the CFTip processing. You can now log in to the database, log back out, and log in again. A quick run-through of the navigation windows works as well.

There are far too many changes made to the code to itemize in detail -- it was a 12 hour day of debugging.

2015.04.12 MSS Code Factory CFLib 2.1.12803 CFTip has been debugged

It was a very long day, but the CFTip encryption processing has been debugged and is now functional.

2015.04.12 MSS Code Factory 2.1.12801 Login processing reworked to support CFTip

The login processing has been reworked to support CFTip. The code is almost ready for testing at this point; I think I still need to query the server information as part of the Swing GUI prototype login form processing in order to be able to issue a login request.

I also want to switch the Cluster field of the login form over to a choice box with "default" initially selected, and "system" as the other option. You are no longer allowed to specify multiple clusters for a deployment, so unless you are explicitly logging in to the system cluster, you should get logged in to the cluster that has been configured for the deployment during the security manager system password initialization process.

If you are logging in to the system cluster, you'll have to specify "system" as the tenant. I'm going to leave that as a free-form text field so the user can specify the tenant during a default cluster login.

Note that the new method interface used by the XMsg login processing throws "not implemented" if you try to use it directly with a client-server database application; you'll need to code your own validation of the user information if you're doing real client-server applications, because I don't want to bury the login processing code in the database layers themselves.

2015.04.12 MSS Code Factory CFLib 2.1.12800 Added DeviceName to CFTipClientHandler

The CFTipClientHandler now retains the DeviceName so it can be used to prepare the login request messages.

2015.04.07 MSS Code Factory 2.1.12798 Corrected defects in Security Manager

The security manager was not coded quite right for initializing the system cluster and system password (there was a nested system session problem.) This has been corrected, and the CFDbTest 2.2 Security Manager and XMsg Request WARs now function properly.

As of this set of changes and testing, my Linux box has now been completely restored for development work under Ubuntu LTS 14.04.2.

2015.04.05 MSS Code Factory 2.1.12797 Rebuilt with latest jars

MSS Code Factory has been rebuilt and repackaged with the updated Ubuntu jar files and the latest rebuilds of CFLib and CFCore. I don't know where the speed increase came from, but it just produced CFDbTest 2.2 in 4.5 minutes instead of the 7 it used to take under Debian Wheezy. Cool. A free performance boost with no more effort than a system reinstall and a rebuild.

2015.04.05 MSS Code Factory CFCore 2.1.12796 Updated with latest Ubuntu jar files

CFCore has been rebuilt with the latest version of CFLib (2.1.12795) and the updated versions of Log4J and Commons Codec provided by Ubuntu LTS 14.04.2.

2015.04.05 MSS Code Factory CFLib 2.1.12795 Updated with latest Ubuntu jar files

The Ubuntu 14.04.2 release updates Log4J to 1.2-1.2.17, and Commons Codec to 1.9. Commons IO and Xerces are unchanged.

2015.04.05 MSS Code Factory CFLib 2.1.12794 Rebuilt under Ubuntu LTS 14.04.2

CFLib has been rebuilt using the latest Open JDK 7 and Eclipse OEPE Kepler 12.1.2.1 under Ubuntu LTS 14.04.2. The jar files have not been refreshed with the latest versions deployed by Ubuntu as of yet, as I haven't installed everything I need yet. It also looks like Log4J might have been repackaged as commons-logging, which will require more changes than I might like. I'll also have to check the jars that are delivered with this release of Eclipse; I'd rather rely on keeping in sync with those or the jars for the Tomcat 7 release supported by Kepler, as that's what would be in a web container for testing. I don't want to use downlevel jars just to avoid work.

2015.04.05 Programmer's Notes

I re-installed my Linux box with Ubuntu LTS 14.04.2 because I've been having too much instability with Debian's latest NVidia drivers, and I can't figure out how to back out to an earlier release. Not that the how of that matters at this point as I've already nuked the box and am already in the process of restoring the tools and code repositories I need. The main reason for this programmer's note is to test my SSH keys for github pushes.

Annoying. A new config for git to squelch a message. Testing to see if it's squelched.

2015.03.29 MSS Code Factory 2.1.12792 Web interface for submitting CFTIPEnvelope requests debugged

The CFTIPEnvelope Request submission form has been debugged and now send plain text exception identification and traceback information when there is an error processing the LoginRequest or AppRequest Payload, such as a decryption error.

The ServerInfoRequest is properly responded to with a text/plain document comprising of an XML response message suitable for processing. This is the only plain-text response the server normally produces; any other occurances indicate exception handling was invoked by the server, and that the exception message in the response text should be displayed to the user.

The builds now expect commons-io-2.4.jar to be in the runtime path for all executables, and CFLib has been updated to version 2.1.12791.

2015.03.29 MSS Code Factory CFLib 2.1.12791 CFTIPEnvelope parser now uses the log object to report exceptions

When an exception is detected by the attempt to parse data, the CFTIPEnvelope parser now properly reports the exceptions to the log output stream associated with the parser. The call stack should now show up in the HTML response text to inform the user as to how and why the parse of their request failed.

The client side code will therefore need to be modified such that if the client receives a response that isn't properly encrypted with the session AES256 key, it defaults to treating the response as plain text to be displayed to the user. Empty responses should be treated as raising exceptions in the client as well, as the server *normally* responds with an XML XMsgRspn message body, converted to a byte array, encrypted with the AES256 session key, and then wrapped as base-64 encoded data.

At least, that's the plan.

2015.03.28 MSS Code Factory 2.1.12789 XMsgRequestXml processing page now expects XML text

Instead of expecting a base-64 encoded blob, the XMsgRequestXml processing page now expects the submitted message to be a CFTipEnvelope XML message, which subsequently contains a base-64 encoded message body being submitted.

The raw response from the processing of the message is passed back to the client as the plain text response to the POST of the form data for processing.

GET just returns a user interface form for doing test data submissions. The client web interface implementation will never be doing GET processing, only POST submission of message bodies for processing.

2015.03.28 MSS Code Factory 2.1.12787 XMsgRequestXml processing page ready for testing

The LoginRequest and AppRequest pages have been consolidated into a Request page which instantiates a CFTipEnvelopeHandler for the client session, initializing it's attributes with the shared server information instance maintained by the $SchemaName$XMsgSrvWarApplicationListener. This should ensure that the overhead of key generation is handled by the first page request processed, and rely on the shared values of those keys for all subsequent processing.

2015.03.27 MSS Code Factory 2.1.12785 There are now separate XMsg LoginRequest and AppRequest forms

The dual-communications channel nature of the LoginRequest and the AppRequest redirecting to each other based on the state of the Authorization has been coded. I haven't gotten anywhere near as far as decrypting the code block with the appropriate key information, as I haven't stored the client session key information in the server yet. I need to actually implement the new login XMsg request/response processing and propagate down to the database layer as appropriate.

2015.03.27 MSS Code Factory 2.1.12783 Stubbed in an XMsg Request WAR

The $lower SchemaName$xmsgsrvwar$PackedVersion$ project source tree has been added to the manufactured project JEE support. Only an AppRequest handler has been stubbed so far. The AppRequest handler expects there to be an authentication in effect for the server session. The AppRequest handler decrypts the request body using the client AES256 session key registered at login time, handles the request, and encrypts the response using the client AES256 session key registered at login time.

A LoginRequest handler needs to be coded as well. The LoginRequest expects the request to be encrypted with the Server's RSA2048 key instead of the client's AES256 session key. Processing of the encrypted login request includes assignment of the most recently submitted client AES256 session key to the logged in session. All responses to the client will subsequently be encrypted using that key, including the response to the login request message itself.

In both cases, the response XML is encrypted using the client AES256 session key and then encoded as Base64 text, responding to the request with a text/plain type instead of text/html. The raw Base64 encoded response will be sent as the response body instead of XML or HTML markup.

2015.03.26 MSS Code Factory 2.1.12781 Security Manager implementation in sync with client

The Security Manager web interface is now in sync with the code as implemented by the PostgreSQL Swing Prototype GUI. All of the forms for the web interface have been modified so that they rely on the new SysCluster singleton object, which is now initialized while setting the system password for the cluster.

The Security Manager AddDevice form has been updated to expect and validate an uploaded RSA 2048 public key encoded as a Base64 object, such as provided by the last stage of initializing the client key information in the PostgreSQL prototype Swing GUI implementation.

The run scripts for the PostgreSQL prototype Swing GUI implementation have been corrected.

The code has been used to test uploading of a client key to the server.

2015.03.19 MSS Code Factory 2.1.12779 Public device key displayed for copy-paste

The public device key is now displayed after it is retrieved from the keystore so that you can copy-paste the device information to the web forms of the Security Manager. Next I need to make sure that the Security Manager accepts the values as produced by the GUI.

Then I'll work on fleshing out that cluster initialization through the Security Manager system setup forms.

2015.03.19 MSS Code Factory 2.1.12777 Public and private keys loaded for device

The public and private keys for the configured device name are now loaded from the JCEKS key store, with prompting for passwords as appropriate. The forms to prompt for the passwords are auto-launched when the application starts, and exit the application if they are cancelled out of. You must know the passwords for the keystore and the device key in order to use the application at all.

Next I need to add and wire a form to let the user copy-paste the public key information for the device to the Security Manager web forms.

After that, I need to dive into the Security Manager web forms again for a while, as I haven't finished initializing the latest system data that specifies the cluster the server is supposed to be participating in. I had to manually initialize that data to proceed with my GUI changes recently, which reminded me to get off my butt and finish the code for that feature.

Once the server side code is ready and I've re-initialized a PostgreSQL installation to verify that the forms work, I'll shift back to the client side for a while to code the new methods for processing logins, with appropriate changes to the login form.

One of the changes I want to make is that if you log in as system (the default), the GUI should auto-prompt you with a list of tenants you are authorized for so you can choose which one you want to work with. That'll take a bit of coding, though, as I'll want to create some database-level stored procedures for performing the query for that list of tenant names. With that in mind, I'll be pre-initializing the Tenant attribute of the login form to "system" at some point, and pre-loading the Cluster with the server information values. System administrators still need to have the option of manually specifying the "system" cluster, though.

I'll also be adding a cluster-picker drop-down to the login form, though it will initially be populated with the hard-coded value "inmemory" and left as read-only. I just want to prepare the framework of the code to query the server information and apply it to the Cluster name automatically whenever a server is selected. In the future, this will be a list of http URLs backed by a list in the client configuration file, and when you pick one or enter a new one, that URL will be probed for a server information request instead of using the hardcoded data that I'll be using at this point in time.

I did have to give up on implementing custom code to create self-signed client device certificates. You'll have to use the Java "keytool" to create RSA 2048 certificates (self signed is fine.) Don't forget to specify "-storetype jceks" and to make sure you're working with the keystore specified in the client configuration file. The name of the device should be used as the alias for the key you create.

I do still auto-create the keystore itself, though if the key is not found in a newly created keystore, you're given instructions on how to create a self-signed RSA 2048 key and the application exits.

2015.03.18 Programmer's Notes

The open device key window is ready for testing after the create device key window is updated to actually create the key and launch a window to prompt for the keystore password to save the new key. For now it's only been tested to ensure that it opens the create device key window automatically if there is no public key for the device in the keystore (which doesn't require a password to retrieve, so it's easy to check.)

Next up: fleshing out the create device key window and adding the prompt for the keystore password to save it.

2015.03.18 MSS Code Factory CFLib 2.1.12776 Rework pieces of CFTip

Pieces of CFTip have been reworked to use a session AES 256 SecretKey instead of a public/private key pair generated by the server (the client is expected to generate the key and send it with the login request.)

The code for accessing the key store to get the client device key has been removed; that will be handled by the application itself.

Note that you must use an RSA key for the client device key; RSA is hard-coded throughout CFTip.

2015.03.18 Programmer's Notes

The rules currently produce a clean build that lets you walk through the dialog process of an application startup. However, you need to "Cancel" when prompted to open the device key, as that currently triggers a clone of the Open/Create Key Store dialog back-end code.

Once I've updated device key forms to create proper RSA 2048 device keys, I'll have to add another window to prompt for the keystore password to save the new key pair (appropriately hostname-username-public and hostname-username-private.) Only the private key should be secured by a password. Anyone with access to the key store should be able to read the public key for the device.

2015.03.13 MSS Code Factory 2.1.12775 KeyStore now properly initialized

The form conversation for CFDbTest's Swing prototype GUI now uses the client configuration file data to open or create the KeyStore as appropriate. If you cancel out of opening or creating the key store, the application exits so that you can modify the client configuration file by hand (yes, I should have forms for editing the attributes of the client configuration file, but it is only a prototype, not a full-featured application.)

2015.03.10 MSS Code Factory 2.1.12773 ServerInfo now properly initialized

The ServerInfo is now properly initialized for the CFDbTest 2.2 PostgreSQL Swing GUI prototype. For the most part this past day has been spent exploring different options for how to use the Java encryption APIs, which included switching to RSA 2048 keys instead of AES256 keys, as AES is a symmetric algorithm and I want the communications to rely on public key algorithms like RSA instead.

A hardware accelerator for generating RSA key pairs is a must for deployment with any significant number of users.

2015.03.10 MSS Code Factory CFLib 2.1.12772 Corrected error in ServerInfo XSD

The CFTip server information XSD has been corrected. The algorithm name for key generation has also been changed from "AES-256" to "RSA", as the intent is to use public/private key pairs, not symmetric encryption.

2015.03.08 MSS Code Factory 2.1.12770 Client configuration file wired for PostgreSQL GUI

The PostgreSQL GUI client prototype now properly initializes the client configuration file and sets a reference to it in the Swing schema object so that it can be referenced.

The client configuration file normally specifies $HOME/.msscfjceks as the name of the keystore to be used by the client device, but that can be over-ridden on a per-application basis, as each application has its own .schemanameclientrc file.

Next I need to modify the PostgreSQL GUI client so that it does the server side initialization before launching the GUI main frame -- once the code is eventually shifted to a web client, that initialization will be done by the corresponding JEE server, so I don't want to embed the code in the GUI itself. All that is really involved is generating the server key, although I do expect that to take a few seconds to process, so I'll have to do some console messaging so the user doesn't think the GUI is hung. (I don't want that initialization to be displaying GUI dialogs because that requires embedding server initialization code in the GUI.)

2015.02.07 Programmer's Notes

I need to load the .schemacf client configuration file from the user's home directory, and initialize it if it doesn't already exist.

Next I need to check for the existence of the jceks key store file referenced by the .schemacf file (.cfkeystore in the home directory by default.) If it doesn't exist, I need to use the GUI to prompt the user as to whether they wish to create the keystore file, or exit the application to edit the .schemacf reference to point to a different keystore file.

If the keystore file exists, I need to display a window to request the password for the keystore, and open it with that password, exiting the application if the user enters an invalid keystore password three times in a row.

Once the keystore is open, I need to probe it for stripped CFDev-hostname-username-public and CFDev-hostname-username-private entries, where the stripped hostname-username is the device name. You are not allowed to change the device name in the client. The device is the device; you're not allowed to masquerade.

By "stripped", I mean [a-z][0-9] with a leading alphabetic, coercing uppercase to lowercase and replacing all other characters with underscores.

If the key pair doesn't exist, again I'll display a window prompting the user to either create the key pair or exit and edit the .schemacf file to point to a different keystore file.

Once the key is generated or found to exist, the user is prompted for the key's password, which is used for the private key. The public key will either have the same or no password; I don't know if a jceks keystore will let me specify a null password for a key. If it does, I won't be specifying passwords for the public keys.

That will give me the information needed to finish initialization of the client handler object before the GUI is displayed.

Seeing as the server is in-process, I'll need to initialize the ServerInfo through code for now. That's pretty trivial to do, though it does mean that there is a new server key for every run of the client GUI. C'est la vie.

For now, I'll add a server-URL choice box to the client, and modify the .schemacf file to keep a list of the 10 most recent server URLs entered for populating the list. Whenever the user picks a server, I'll issue a ServerInfo query to that server as the server's public key is needed for encrypting any login requests. This really is going to be placeholder code, though, because the only server that will be supported until I implement the web messaging layers is the in-process server. Maybe I'll just make that field read-only for now after I test the URL history code, and pre-populate the URL history in the .schemacf with the "inprocess" server name.

Then I'll want to add a GUI window for displaying the device name and public key of the client. This has to be available at any time, so the user can copy-paste the fields to the Security Manager web interface forms.

After that, I'll focus back on the Security Manager server, and finish the support for entering a cluster URL and description while initializing the system password, and inserting the appropriate Cluster and SysCluster objects as the system user.

I think I had already flipped the server's device key code over to supporting the formats I intend to use in the client, so that leave me ready to test copy-pasting the device name and device public key from a client instance to the security manager forms to verify that the process works.

Then and only then will I be ready to deal with the actual login code and message format changes required for it. You can scroll down for more details about that process in earlier programmer's notes. I'll not repeat that info at this time. I'm just sorting it out in my head as to what I need to do next.

2015.02.07 MSS Code Factory 2.1.12768 CFDbTest 2.2 Swing PostgreSQL client stitches together security objects

The security objects provided by CFLib's Tip package are now integrated with the Swing prototype GUI for PostgreSQL, though they are not properly initialized yet and there is quite a lot of work remaining before I can even think about testing any of the code.

I've also removed the XMsg Loaders from the system. The new security framework doesn't play nice with command line tools, and you should really be using SSH to get into the server cluster and running the SAX loaders from there, not an XMsg client from a desktop. If you need to import data from the desktop, upload it to the server and wire together a SAX parser instance over the loaded data in your application server. Don't try to run loads from the client; a document load should either load as a single transaction or be rejected entirely, not partially loaded as would happen with the old XMsg loaders.

2015.02.05 MSS Code Factory 2.1.12766 CFDbTest 2.2 now builds cleanly

Errors as to which version of Base64 should be used were corrected in CFLib and rebuilt into CFCore to resolve problems with the CFDbTest 2.2 builds. The rules were fleshed out for the client-side integration of CFTip. The XMsg code for this build does not work, of course, but it clean compiles, so it's a good snapshot point.

2015.02.05 MSS Code Factory 2.1.12765 Refreshed license and copyright for 2015

The licensing and copyright information for MSS Code Factory 2.1 has been refreshed for 2015, along with all of the defined models.

2015.02.05 MSS Code Factory CFCore 2.1.12764 License changed for 2015 from GPLv3 to LGPLv3

The license headers for CFCore 2.1 have been updated for 2015, changing the license from the GPLv3 to LGPLv3, and correcting the contact information for commercial use.

2015.02.05 MSS Code Factory CFLib 2.1.12763 Refresh licensing information; still LGPLv3

The licensing file headers of CFLib 2.1 have been updated for 2015. Among the changes is correcting the contact information for commercial use.

2015.02.05 Programmer's Notes

No, I better stick to the original plan and work on the web client implementation before I divert myself with new functionality. Maybe what I'll do is use a 2.2 release to add the new functionality, or even 2.3, similar to the way I've leapfrogged between a .odd release being used to manufacture a .even release, with the .odd release as one that's expected to be used by the public while the .even releases are just used for the sole purpose of manufacturing the next .odd without adding new functionality.

2015.02.05 Programmer's Notes

I've been sitting around, high as a kite, free from a migraine, and just free-flowing thoughts about how I could implement this scripting engine.

First and foremost, I've decided that instead of forward-declared variables, what I'll use is "declare" and "deferred" variables. Both will declare the instance with a null initial value, but their usages will be a little different.

You won't be allowed to refer to a deferred variable in the right hand side of an assignment expansion, only as the receiving left-hand-side variable. I just don't want to get into the hassle of deferred calculations like a spreadsheet does, nor variable dependency trees required to implement same.

Any expansion which references a deferred variable will be replaced by a deferred reference object that identifies the variable needed. When the scope of the rule declaring the deferred variable is exiting, the value of the deferred variable will be used to expand the deferred rule.

Generally, I'm assuming that the expansion in question is a format output specification, because you're not allowed to reference the deferred variables in the right hand side of evaluations. I can't think of any other cases where deferred expansion would apply given that constraint.

Some of the evaluations I want to provide are new instance creation, calculation assignments/evaluations, and binding of create/read/lock/update/delete verbs for the different object types defined by a model.

In the event that you just want to do calculations in a rule body, there is nothing preventing you from packing together a bunch of business logic GEL rules with an empty string body for the expansion itself, so that will be your equivalent to a procedure declaration: an expansion rule producing an empty body.

Note that the engine binds generic objects to the evaluation stack during the processing of bindings. I intend to implement similar functionality for assignments, so assignments will actually produce a functional object result of the left-hand-side variable's value, similar to the way the last statement processed by Erlang is the result of an Erlang function.

This means you'll be able to declare pure functions similar to procedures by simply making sure the expansion does nothing but declare functions, access variables, readers, etc. and ends with an assignment specification. This will be handled as a special case of the engine: if the result of an expansion is the empty string, and the last GEL rule evaluated was an assignment, the current value of the left hand side is bound to the output of the expansion. This means that all expansions will now produce output objects, not just the binding evaluations.

To prevent that behaviour in a rule body, just add an expansion of $empty$ to the end of the rule, and you'll still get an empty expansion, but with the expansion string empty as the output object. (Yes, everything will return an object reference. General expansions return the expanded string as their object.)

There won't be a way to tell the difference between the return of a string variable and a string expansion during runtime, but I think I can live with that. I can't think of any cases where the rules would have to know any difference between the two.

One thing that isn't going to be allowed is the return of lists. Only atomic data types, object instances, and object (primary) keys can be returned by a "function".

2015.02.05 Programmer's Notes

I've had an idea knocking around in my head for some time now.

With the latest enhancements that were made to the core engine, the performance of MSS Code Factory is now fast enough to be used for things like report generation, but there are some key features missing from the processing model for that to happen.

Specifically, there is no way of dealing with unknown values, such as the total number of employees, which might appear as a page footer, but which isn't known until the end of the data processing. As far as I know, most report generation engines deal with that by buffering the whole report output and rewriting the required fields/values when they become available.

Simple in concept, except for the fact that I based all of the output for the engine processing on appending to a StringBuffer.

What I want to do is add the concept of variables to the engine, with declarative tags for each of the core data types (Int16, Int32, Int64, String, Double, etc.) If I'm going to go to that effort, I'll also want to be able to declare higher level objects so I can implement a proper scripting language. So I'd want to be able to declare things like primary keys of objects, object instances/references and lists of objects.

But what gets interesting is the need to forward-declare variables and have them in an unknown state during processing. So I'd like to also have the modifier tag "forward" for all variable declarations.

The scope of a declaration would be the GEL expansion that declares the variable. It would be in-scope until the processing of that expansion is complete and exits. As I'm a big believer in type-safe processing, all variables would have to be explicitly declared.

When a forward-declared variable is encountered in the processing rules, instead of evaluating it's encompassing GEL expansion, the system would have to bind a runtime instance of the rule referencing the variable to the output of the expansion. When the variable is subsequently declared during processing, it would scan the buffered output of the expansion so far, and evaluate the placeholder expansions, pasting their results into place in the ever-growing output.

So to deal with the case of a departmental sub-total, for example, you'd declare the sub total variables as forwards in the beginning of the expasion rule for processing the department, reference that variable with expansions during processing, and then explicitly re-declare the variables at the end of the department processing. The re-declaration would add the variable to a "re-evaluate" list for the encompassing rule.

You'd then have your GEL execute statements performing any further calculations on the newly declared variables, and as the rule finishes processing it's GEL expansion for the department, the re-evaluate list would be applied to the placeholder expansions of the result.

Note that this means you can declare a variable as forward, immediately declare it's instance, do your processing and inline calculations to update the variable, and then count on the result being applied at the end of the expansion, rather than with volatile values during the expansion. This is particularly important for being able to implement something like a sub-total calculation, because you want to initialize the sub-total to zero and then add the values from individually processed objects as they pass through the GEL engine process.

The very topmost expansion of a file would then be able to check for any unresolved forwards and throw exceptions accordingly. I don't want to try to allow variables to be declared any higher than a file expansion because there is no where to output an expansion that isn't being written to a file.

I still need to give this some more thought, but I think I'm on to a fun little side project to work on after the transport independent privacy implementation. I'll probably even put off the implementation of the web client communications until after I work on this. It's just been so long since I had anything really new to work on; fleshing out the framework is all old hat stuff that I've done before. I've written all kinds of reporting code over the years, but I never really thought about writing a reporting or scripting engine before.

The last piece of that scripting engine puzzle would be to create a JSP-style interpreter page service that uses the engine to expand a rule set. That would require figuring out how to create function declarations for the pages, so that the arguments of the page/function could be passed in from the client as servlet attributes.

The end result of all that would be a page/report processor that could be used to author generic business reports in whatever document format you choose to use as the output of a GEL interpreter/engine instance in a WAR format.

One catch is that such a page engine would have to specify all the rules for expanding the page, or I'd have to allow for some sort of explicit rule-file-include syntax, so that the page itself could be defined as a single file in the servlet space. When the page processes, it would instantiate an MSS Code Factory engine, load the "any" rules, and then load the page file. The page file would be expected to declare a "top" rule/function as an entry point for the expansion. The page file variable declarations would be processed, and then the engine would have to apply the servlet arguments to the defined page variables, ignoring any cases where there were no matching page variables.

I'd also want to bind the read-by-index, update, and other actions on objects to the scripting engine, so that actual business processing could be done during the expansion. Otherwise how would I be able to read-by-index the object I want to report on?

2015.02.03 MSS Code Factory CFLib 2.1.12762 Enhanced CFLib ICFTipResponseHandler

The additional interface methods used by the XMsgClient implementation have been added to the response handler interface, including getExceptionRaised(), getLastObjectProcessed(), getListOfObjects(), getDeleted(), and setDeleted().

2015.02.02 MSS Code Factory 2.1.12760 Added SysCluster to CFSecurity 2.2

The SysCluster object is a singleton that is a component of one and only one Cluster -- the one that will be created and initialized as part of the system password initialization in the Security Manager web interface.

The sample configuration for Tomcat now has an example configuration for the SSL support, and the CFDbTest 2.2 Security Manager WAR web.xml now specifies that it must be mounted using https.

A seperate WAR will be created for the XMsgRequest servlet in the future, and will be mounted over http, as the bodies of the requests will be using CFTip to ensure the privacy of their contents.

CSEC, CSIS, GCHQ, and the NSA all claim they're only interested in "meta data." If that's the case, they shouldn't mind me being paranoid and securing application data as thoroughly as I know how to do. After all, I only spent 30 years in the bowels and trenches of enterprise programming in the military, telephony, banking, and financial industries, so I've never learned anything about security and how to use encryption. No, no, not I. :P

That said, I will be uniquely identifying the hostname and username used to connect a client application to the web messaging services. You will not be allowed to change the name of the device -- you have to copy-paste the device name and the Base64-encoded public key for the client to the Add Device form provided by the Security Manager web interface.

My primary target is the enterprise systems I know so well. You will be identified. Your access will be secured. Depending on the options chosen in the business application models, your every change to the data may be tracked by history tables accessible to the system and database administrators.

Rogue employees can run, but they can't hide.

2015.02.02 Programmer's Notes

The client will initially expect to find a .cfkeystore in jceks format in your home directory. If it is not found, the client will prompt you to create it, asking for a double-entry password for the key store file.

At that point, the .appcf file will have been created, and you can edit it's contents to reference an existing jceks key store file if you so choose, provided the path to that file is static. This allows for the use of USB sticks and other such devices to hold the .cfkeystore.

If the keystore file specified by the .appcf is found, you will be prompted for the password used to access the system keystore on application startup. The value will be retained by the client in memory. Not the greatest security approach, but if you've got somebody embedding rogue code or doing memory scans to access the process memory, you have bigger problems to worry about than I care to deal with.

The next step is to generate an alias name for the keystore in the format "CFDev-CleanHostname-CleanUsername-public" and "CFDev-CleanHostname-CleanUsername-private". In the event that one or both keys are not found by those alias names, you will be prompted to create the key pair, providing a double-entry password for securing the keypair.

If the alias is found, you are prompted for the key password, and the key pair is loaded into the CFTip client access object as the device keys.

Only pure ASCII alpha-numerics will be allowed for either name.

A new object has been added to CFSecurity 2.2, the SysCluster object. This object is a singleton that will be created after the system cluster is configured by the (to be modified/updated) form used to initialize the system password in the Security Manager. All other code will be modified to force the security cluster to that of the SysCluster.Cluster relationship. Instead of using a servlet global parameter via JNDI, I will use the SysCluster instead for the web forms. So once you've entered the http URL to the XMsgRequest servlet (to be coded in the relatively near future), and specified a description for the cluster being initialized through the web forms, no other cluster will be allowed to use that database instance.

One cluster, one database server.

2015.02.02 MSS Code Factory 2.1.12758 Corrected defect in Add Device page

The Security Manager Add Device page was not properly initializing the Cipher instance. However, seeing as the client code for providing a source for the copy-paste of the client's public key has not been coded yet, the point is moot -- you could only successfully add a device if you created some custom code.

Also, all the client code that is used to leverage the security and new login techniques has yet to be coded. There is no need to remanufacture your code unless you want to see proper error message responses for the Add Device page instead of tracebacks.

2015.02.01 MSS Code Factory 2.1.12755 Remove BouncyCastle dependency

Rather than relying on BouncyCastle to handle the device keys, I've opted to switch to Java encryption APIs. This has meant dropping the PGP encrypted emails, but that wasn't working in the first place so it's no loss.

I've completely stripped BouncyCastle from my system, save for the installation downloads I have squirreled away in case I need them some day.

2015.02.01 MSS Code Factory 2.1.12753 Replaced anchors with JavaScript onclick actions for Security Manager

I was using an obsolete form of button links in an effort to avoid JavaScript dependencies for the Security Manager web interface, but that syntax is no longer supported by Firefox/Iceweasel, so it has been converted to onclick JavaScript events.

2015.01.31 MSS Code Factory CFLib 2.1.12752 Added support for device key lookup from keystore

The client handler for CFTip now supports the specification of a KeyStore with automatic creation of an empty key store if it does not exist, creation of device keys, iteration/listing of device names, and retrieval of device keys. Note that under this implementation, three passwords will be required for the keystore, the device key, and the server login.

2015.01.31 MSS Code Factory CFLib 2.1.12751 Initial coding of CFTip complete

The initial coding of the Transport Independant Privacy support has been completed and is ready to be integrated with the manufactured code and tested through the client-server GUI prototypes. Once that's complete, I'll work on the web messaging support for a new web-client GUI prototype and server.

The odds are there are bugs and oversights in CFTip at this point.

2015.01.25 Programmer's Notes

I'm stalling a bit on making too much progress with the code because I haven't decided on exactly how I'm going to layer TIP into the system. I know I want to wrap all the request messages in CFTIPEnvelope messages, which carry a payload of a Base64-encoded BLOB of crypto data.

There are three messages allowed by the envelope: AppRequest, LoginRequest, and QueryServerInfo.

QueryServerInfo has no detail data at all. It just triggers a plain-XML document response from the server specifying the URL of the cluster, the cluster name, the cluster description, the schema name, the schema description, and the public key used to send login requests to the server. It will also include a list of the schemas imported by the main schema installed to the cluster. This list lets the client filter the list of applications it presents for the cluster based on the intersection of the application schemas the client understands and the application schemas supported by the server.

A LoginRequest contains a payload that was encrypted using the public key of the server as returned in response to QueryServerInfo.

An AppRequest is encrypted using the public key of the public/private key pair produced by the server in response to a successful login.

All responses to requests sent from the server to the client are Base64-encoded crypto blocks encrypted with the public key the client sent to the server in its login request, with the sole exception of the response for QueryServerInfo, which is sent in plain-text.

The contents of the crypto-block encrypted by the client's public key is in turn a crypto-block encrypted by the server's private key for the session, which can be decrypted by the public key that was sent to the client in the successful login response. This double-encryption prevents man-in-the-middle attacks on the responses, while the session private key used to encrypt the application requests from the client ensures that the requests did, indeed, come from the client.

Because the XMsg request parser in the server can deal with requests for any of its imported schemas, any client supporting one or more of those schemas can connect to the server and be used for the desired schema. Thus a generic CFSecurity application client can connect to any cluster that relies on CFSecurity (which is all of them.) A customized CFAcc client can connect to any server implementing CFAcc, so you can provide a slick user interface for the application without worrying about what else the server might support.

I've temporarily defined the cftip-22-envelope.xsd in CFDbTest 2.2's XMsg Rqst schema set. Once I'm done prototyping and debugging the TIP layer, I'll shift that XSD and the rest of the TIP implementation to CFLib, after which you will require BouncyCastle to be installed for all MSS Code Factory applications.

2015.01.23 Programmer's Notes

Now that I can create and initialize accounts through the Security Manager, I need to rework the login processing and implement the transport-independant privacy (TIP) support.

With TIP, all communications to the server will be encrypted independantly of the transport mechanism in use. In order to accomplish this, the transport must provide the concept of a connection or session for the client, whether through connection ids, cookies, or some other mechanism.

The first step is to create a security envelope XSD that defines two request transactions: LoginRequest and AppRequest. Both will look very similar at the XSD level, as they are just unrestricted text fields that will be populated with Base64-encoded data. The difference is in the encryption used to encode the request.

The LoginRequest will be encoded using the published public key for the server. There has to be a public method for retrieving that public key, which for a web server deployment will be accomplished by having a servlet that returns the public key of the server using BouncyCastle to encode it.

When a client issues a LoginRequest, it will encode a normal XMsg login request which will be reworked/enhanced to specify the user/account name, the device name, an SHA-512 hashed password that is encrypted using the private key for the device, and a public AES-256 key to be used for sending responses back to the client.

The encryption of the hashed password ensures that the server can only authenticate login requests that were encoded by a registered device. This also hides the hashed password from prying eyes should the server's private key for logins be cracked or stolen.

After a successful login, the server will retain that public AES-256 key it received from the client and generate a public/private AES-256 key pair for communicating with the client. It will hang on to the private key in its session data, and prepare an XMsg response that includes the BouncyCastle-encoded public server key, the SecCluster, SecTenant, and SecUser information. Initially the user will be logged in the the "system" tenant. In addition, the client will be provided with a set of SecTenant instances to which it is allowed to switch its session context. The message gets encrypted with the public key the client had provided (which is retained by the session data), Base-64 encoded, and sent back to the client without the overhead of an XML wrapper (i.e. it's just a Base64 document.)

The client decodes the Base64 document and decrypts it using the private key it generated for this session. It holds on to the server's generated public key, sets its authorization data, and presents the user with the list of SecTenant instances to choose from.

Once the user selects one of the SecTenant instances, an AppRequest will be issued to the server with the new XMsg request ChangeSecTenant. The AppRequest is encoded in a similar fashion to the LoginRequest, except that the public key provided by the server for this session is used to perform the encryption. Thus the bulk of the communications between the client and the server is performed using the generated keys.

The server makes sure that the SecTenant was "system" for the session, and changes the SecTenant of the authorization for the session to the desired tenant, responding with SecTenantChanged, which includes the new SecTenant information for the client's cache and authorization objects. The only user that is allowed to change *to* the "system" SecTenant is the "system" user. Everyone else is only allowed to change to a different SecTenant once and once only for a login session.

We now have a fully established login session, and the user is allowed to proceed with their work.

In the event that a login request fails, the response message is encrypted using the public key provided by the client, but the session is not authorized and therefore the public key is not retained by the server. Nor does the server generate a public-private key pair in this case.

If the ChangeSecTenant request fails for some reason, the response error is sent using the public key provided by the client, and the client session is automatically logged out and disconnected to save server space.

Initial coding of the TIP layers will be performed with the existing client-server XMsg applications, so it will be used by all of the database implementations.

Only after TIP has been coded and tested will I begin work on the last piece of the web client puzzle -- implementing a web server based communications layer to transmit the encoded TIP requests and responses.

2015.01.22 MSS Code Factory 2.1.12749 Security Manager tested

The Security Manager user interface has been tested using CFDbTest 2.2 and Apache Tomcat 7.0.

2015.01.22 MSS Code Factory 2.1.12748 Added the various .git files to manufactured projects

The .gitattributes and .gitignore files for the projects have been added.

2015.01.22 MSS Code Factory 2.1.12747 Added JEE HTML Security Manager interface

The code for the JEE HTML Security Manager interface has been added, but has not been compiled nor tested yet. I'll be adding a number of .git* files soon as well; the first ones are in the $schemaname$smwar$version$ code tree.

2015.01.10 MSS Code Factory 2.1.12744 Database scripts corrected, CFSecurity 2.2 updated

The database creation scripts have all been tested with the changes made to CFSecurity 2.2, and the Security Manager prototype in CFDbTest 2.2 has been updated to incorporate the changes to SecUser.

There are no longer separate Html and App passwords, as it's my intent to double-hash the passwords in the Security Manager forms (TBD.) That way the client applications can hash the password entered by the user to protect it from interception until I have all of the encryption code working.

Once I've made a couple more changes to CFDbTest 2.2's Security Manager prototype (especially the double-hashing), I'll be ready to convert that prototype into rules so that security managers can be produced for all of the applications manufactured by MSS Code Factory.

Due to the errors in the previous release's database creation scripts, you really should download this update and apply it to your project.

2015.01.01 MSS Code Factory 2.1.12736 Added SecUser.[App|Html]PasswordResetUuid to CFSecurity model

The optiona UUID attributes AppPasswordResetUuid and HtmlPasswordResetUuid have been added to SecUser in the CFSecurity 2.2 model. Corresponding duplicate indexes have been created as well.

CFDbTest 2.2 now implements the HTML Password Reset request processing using the HtmlPasswordResetUuid. Similar code will be used by the web application client layers when they're coded.

2014.12.31 MSS Code Factory 2.1.12734 Added SecUser.EMailConfirmationUuid to CFSecurity model

The optional UUID attribute EMailConfirmationUuid has been added to SecUser in the CFSecurity 2.2 model. A corresponding duplicate index has been created (the index has to allow duplicates because most rows will have a null value for this attribute, as their email address will have been verified.)

CFDbTest 2.2 has been refreshed with this model change, and the Security Manager prototype web interface has been migrated from CFDbTest 2.1 for continued evolution and development.

2014.12.31 MSS Code Factory CFDbTest 2.1.12731 Added email confirmation skeleton

This is an outline of the email confirmation process. The workflow has been tested and is what I want for a "first cut." Next I need to update the CFSecurity 2.1 model to track the generated email confirmation UUID in the database with an optional ConfirmationUUID for the SecUser object, a non-unique index by that attribute (it has to be non-unique because multiple rows have a NULL value after their email address has been confirmed), and then I can flesh out the details of this new code by clearing the confirmation UUID to null when you click on the link.

Once that's done, I'll revisit the application pages to check whether a login attempt is for an account that has been confirmed, and re-issue the confirmation email if they try to log in with an unconfirmed id. Until you confirm your email address, you will not be allowed to log in.

Once you do confirm your email address and the confirmation id has been cleared to null, the ConfirmEmailAddressHtml page will redirect you to the login page.

With any luck, I'll have it done by midnight. Just for giggles.

2014.12.22 MSS Code Factory All 2.1.12730 Manufactured by 2.0.12726

The builds for 2.1 have all been refreshed to capture the hash function fixes for the core objects. This will be the last full refresh of the 2.1 projects. With MSS Code Factory 2.1 in production, the manufacturing focus will shift to the 2.2 projects.

2014.12.22 MSS Code Factory 2.1.12729 PRODUCTION

MSS Code Factory 2.1 is now ready for production as the version of CFDbTest 2.2 it produces has passed its regression tests. I am comfortable that the latest iteration of CFCore 2.1 has squashed the hash/map bugs that were plaguing the code.

It takes 7 minutes for 2.1 to produce CFDbTest 2.2 on my aging P4 3.8GHz single-core system. It used to take over six hours on my Core i7 laptop. 7/360 is roughly 1.9% of the execution time. And that's neglecting the fact that the Core i7 processor cores are 3 times as fast as the one on the P4, so the ratio is really more like 7/1080, or 0.6% of the total run time. I'm content with a 99% runtime reduction.

2014.12.22 MSS Code Factory CFCore 2.1.12727 Applied hash key corrections

The hash key corrections have been applied to the CFCore object hierarchy by MSS Code Factory 2.0.12726.

2014.12.22 MSS Code Factory 2.1.12725 Beta 2

There were fundamental problems with the implementation of equals() and compare() for the bowels of the code produced by the system. This had not been uncovered until the recent shift to HashMaps, which exercised the broken code.

Beta 2 produces code that builds properly; Beta 1 did not.

2014.12.21 MSS Code Factory 2.1.12724 Beta 1

The rules and models have been refreshed, and a run of CFDbTest 2.2 produced the code with no obvious errors. It only took 4 minutes and 30 seconds to do so, compared to the six hours plus that it used to take with 2.0. So I didn't quite get the 150 fold improvement I saw at first.

But to be fair, my poor laptop seems to be getting drive-IO bound.

2014.12.21 MSS Code Factory All 2.1.12723 Refreshed by 2.0.12721 Service Pack 3

All of the 2.1 projects have been refreshed by MSS Code Factory 2.0.12721 Service Pack 3, rebuilt with the latest versions of CFLib and CFCore, packaged, and will be available for your perusal as soon as the uploads are complete.

Note that the rule base and models for MSS Code Factory 2.1 have not been refreshed yet; this release only includes updates to the core engine itself. Thanks to judicious manipulation of the CFCore 2.1 model, performance of MSS Code Factory 2.1 is roughly 150 times as fast as 2.0.

I'll be focusing on getting MSS Code Factory 2.1 release-ready next. I want that performance!

2014.12.21 MSS Code Factory CFDbTest 2.1.12722 Regression tests passed

The regression tests have been passed for PostgreSQL with the new List interfaces, and the prototype security manager web interface has been updated to use it as well (there were a whole two lines worth of edits to get the security manager up to date with the interface changes.)

2014.12.21 MSS Code Factory 2.1.12720 Double full circle: Performance tuning complete for CFCore 2.1

This release of MSS Code Factory runs on the performance-tuned version of CFCore 2.1. As a result, it can load and pre-compile to GEL runtime the entire rule base during initialization, which will help reduce memory fragmentation during execution by ensuring that all the static resources that were eventually created incrementally by the 2.0 runtime are created as one big sequence of allocations early in the execution of the system.

Compbined with the garbage collector sweep that is executed every 100 files, I believe this version of MSS Code Factory will substantially out-perform its 2.0 counterpart.

The rules it is using are somewhat dated for the CFDbTest 2.2 production test run, but the point is to see whether a substantial amount of time is saved over the six-plus hours that the run used to take.

On the presumption that the garbage collector sweep will keep the memory tidy and compact, the testing is going to be run as a single task, rather than a sequence of per-toolset tasks as had to be done with 2.0. It's been a couple of years since I've been able to do full-job runs -- it would be nice if those days are back. Being able to do that again is really a pre-requisite for multi-threading the factory. There is no point allowing multiple threads to run if you can't even do a full run without encountering performance problems due to memory fragmentation.

The performance improvement is just insane. In a matter of less than ten seconds, the code for DB/2 LUW database, SQL Server, MySQL, and Oracle were created. There was an error in the PostgreSQL rules that caused things to fall over. With 2.0, it takes about 45 minutes to an hour *per database* to manufacture the same code.

In 2 minutes on my aging P4 3.8GHz single core system, which is about 1/3 the speed of a core on the i7 based laptop, I was able to produce the entire DB/2 LUW database creation script set for CFBam 2.1. That job used to take close to two *hours* to run on the laptop. So we're looking at a 150:1 performance improvement, give or take a bit.

2014.12.21 MSS Code Factory CFCore 2.1.12719 Major refactoring and restructuring

The internal relationships used for the GEL runtime have been restructured to use independent relationship key attributes instead of sharing the TenantId and CartridgeId of the object. With the latter, some of the attributes were non-null so the ORM code would try to resolve the null relationship against the database, finding no matching lookup. (I really should check for that and throw an exception.)

But this means that when the GEL instruction table grew to ginormous size by pre-compiling all the rules on load, the performance of those lookups started taking enough time that I noticed they were happening. This release of CFCore should perform much, much faster than the previous iteration. The interface of CFCore has not changed, so you can just drop this update into an existing deployment, editing startup scripts as appropriate.

The code for CFCore 2.1 now uses the new List interface, which replaces the old SortedMap interfaces for returned result sets when reading objects by duplicate index. The lists are sorted in natural order by ascending primary key, but the SortedMap implementations Java provides were proving too heavy for a general purpose interface. As it is, I really shouldn't bother with sorting the result sets at all, but I do hate a disorderly data world. I like some predictability and the option of making a few assumptions about the data I see -- like that its unique within a data set.

The changes for the general purpose Java code have been written, but are completely untested. I'll be working through getting CFDbTest 2.1 into a clean-building state before issuing the next refresh of MSS Code Factory 2.0, which will incorporate the fixes for the general purpose Java ORM interface. At that point, I'll be ready to manufacture the code for the affected layers of all the 2.1 projects and distribute the refresh.

2014.12.20 MSS Code Factory All 2.1.12717 All of the 2.1 projects now use Map/HashMap

The performance tweak of using Map/HashMap has been applied across the board to the 2.1 projects.

For my next performance tweak, I'll be switching from the SortedMap returns for the duplicate keys of an object interface to a List. In reality, the List will be a SortedSet, but I don't want to go through the implementation overhead of an actual implementation of a SortedSet for the query results. It's far faster and more efficient to build an array, sort it by primary key, repackage it as an ArrayList (sorted by natural ascending order of primary key), and pass back the ArrayList as a List interface.

However, that's going to require changing a lot of code that *uses* the return values from those methods, so I'm not doing it just yet. I want some sleep first. :)

2014.12.20 MSS Code Factory CFCore 2.1.12715 Switched over to Map/HashMap

With the larger size of the maps being created when pre-compiling all the rules (there are a lot of GEL fragments created when you do that), the performance issues surrounding the use of SortedMap/TreeMap became overwhelming. Switching the core Java code over to using Map/HashMap wherever possible not only addressed the problem, the engine is now faster with all the rules precompiled than it was before (after the slightly longer load/setup phase, that is.)

2014.12.20 MSS Code Factory CF All 2.1.12714 All 2.1 project security models refreshed by 2.0.12713

All 2.1 projects have been refreshed with the code produced by MSS Code Factory 2.0.12713, with the possible exception of CFCore itself (I should do a refresh build of MSS Code Factory 2.0 to make sure the changes to the CFCore model are published properly and available.)

The enhancements to the object models to support the security code I'm prototyping in CFDbTest 2.1 have been applied to all of the projects, so they're ready to receive their web interfaces as soon as I convert the prototype code to rules (likely several more days, possibly even more than a week until that's done. I want to have the prototype fleshed out completely before I convert it to rules -- it's faster and easier to edit prototype code with Eclipse than manufactured code through the rule base and job runs.)

The CFDbTest 2.1 prototype code has the outline of the web interface for initializing the "system" account password on first use, logging in to the security manager web interface, creating an account, creating security devices, selecting the default security device, deleting security devices, and logging out of the web interface.

I still need to add password reset requests (both HTML/Web and Application passwords), support for changing the password on request, and support for cancelling a password change request in case it was spoofed somehow.

After that, I need to start with basic security emails issued via a Java Mail resource, so you can configure the mail server to use easily and the reply-to account information for the messages that get sent.

Then I'll be ready to add the encryption support for the security emails. Emails regarding security will be sent encrypted by the public key for the user's default device. Once I've got that working for password resets, I'll be changing the create account forms to provide for the specification of the default device name and public key upload as part of the account creation process. So even the initial account registration email will be sent encrypted by the user's public key.

If I'm going to bother implementing security, I'm going to do the best job of it that I can in light of recent events regarding secure computing in the modern age.

Once I've got all those back-end services coded and prototyped, I'll work on getting that security manager web interface converted to rules, and manufacture an update of the resulting code for all the projects. This current release has the database changes that future code will require, so 2.1.12714 just prepares for that secure future.

After that comes the application interface/web XML messaging client.

Once that's ready to go, the client-server swing interface prototypes will be dropped. The long term goal has always been a web deployment. I'm *almost* there.

2014.12.20 MSS Code Factory CFCore 2.1.12712 Starting work towards multi-threading the engine

Working towards being able to pre-compile the GEL at the time the rule is loaded, rather than doing the compiles on the fly as-needed. That way *all* of the GEL expansions will have been populated, which means they're providing a stable memory image that can be safely read by multiple threads without a need for further updating of the objects (which would require synchronized APIs if the memory image weren't stable.)

This is step 1 towards being able to multi-thread this beastie of mine.

2014.12.19 MSS Code Factory CFDbTest 2.1.12711 Security model enhanced by remanufacturing

The CFSecurity 2.1 model has been updated to add a Description to Cluster, password reset attributes for the SecUser object, and the addition of a DevName attribute to a SecSession. Last but not least, a ProxyUser parent has been added to SecSession, so that when artificial jumps into a system.system.system session occur, there is tracking as to *who* is responsible for that leap into the system data space.

The device name of a SecSession is *not* a lookup key, because it will be set to "web" for security manager interface logins, and it will not be legal to specify "web" as a device name in the Add Device form in the future. (There are a lot of rules and checking I need to go back and implement once I'm done fleshing out the skeleton of the interface. If you allow garbage in, you get garbage out.)

I'll also be modifying the interpretation of the $SchemaName$Cluster environment variable used to deploy the WARs to specify the cluster name, followed by a single space, followed by the description string for the cluster. I'd rather get that description from the environment rather than having to add a form and a step to the server initialization/registration process.

I've implemented the SHA-512 password hashing for the security manager HTML password. As long as you deploy the WAR over HTTPS instead of HTTP, you should find the security of the HTML interface quite acceptable, rough though it is. There is a lot left to code -- the skeleton for HTML and application password resets, initializing the application password to the HTML password for one-time use in changing the application password, cancelling password resets by entering the existing password, and password change forms. I'm going to hide the application password values behind a double-blind of taking an SHA-512 hash at the client and applying another SHA-512 hash to that at the server as the password for an application user. So you won't be able to *set* the application password through the security manager web interface, only reset it to whatever your HTML password is. We don't know what it is, we don't want to know what it is. La la la la la.

2014.12.19 MSS Code Factory CFLib 2.1.12709 Shifted time base to 1970.01.01

1970.01.01 00:00:00 is Java's "0" date-time value in milliseconds, so I've changed the time fields to use that instead of 2000.01.01 as their base. That may break MySQL again; time will tell.

I'm going to switch the history tables over to keying by such a value so I can quickly and easily persist millisecond timestamps to the database for history sequencing and redos. Millisecond recording is important for ensuring that the individual creates, updates, and deletes performed during the servicing of a request are ordered by some ascending value to capture their sequence of execution.

In order to make this "go", I'll need to modify the standard argument set for the stored procedures of all the databases to take a 64-bit secStamp time value, provided by the JDBC client layer when invoking the stored procedure.

2014.12.19 MSS Code Factory CFDbTest 2.1.xxxx Underling CFSecurity model enhanced.

The CFSecurity 2.1 model has been updated to add a Description to Cluster, password reset attributes for the SecUser object, and the addition of a DevName attribute to a SecSession. Last but not least, a ProxyUser parent has been added to SecSession, so that when artificial jumps into a system.system.system session occur, there is tracking as to *who* is responsible for that leap into the system data space.

The device name of a SecSession is *not* a lookup key, because it will be set to "web" for security manager interface logins, and it will not be legal to specify "web" as a device name in the Add Device form in the future. (There are a lot of rules and checking I need to go back and implement once I'm done fleshing out the skeleton of the interface. If you allow garbage in, you get garbage out.)

I'll also be modifying the interpretation of the $SchemaName$Cluster environment variable used to deploy the WARs to specify the cluster name, followed by a single space, followed by the description string for the cluster. I'd rather get that description from the environment rather than having to add a form and a step to the server initialization/registration process.

I've implemented the SHA-512 password hashing for the security manager HTML password. As long as you deploy the WAR over HTTPS instead of HTTP, you should find the security of the HTML interface quite acceptable, rough though it is. There is a lot left to code -- the skeleton for HTML and application password resets, initializing the application password to the HTML password for one-time use in changing the application password, cancelling password resets by entering the existing password, and password change forms. I'm going to hide the application password values behind a double-blind of taking an SHA-512 hash at the client and applying another SHA-512 hash to that at the server as the password for an application user. So you won't be able to *set* the application password through the security manager web interface, only reset it to whatever your HTML password is. We don't know what it is, we don't want to know what it is. La la la la la.

2014.12.18 MSS Code Factory CFDbTest 2.1.12707 Default device selection added

You can now set the device to use as the default for the user, and are no longer have links to let you delete the default device (you could craft the URL by hand if you were twisted, and it the system will leave you with no default device, but you'd have to work at it.)

2014.12.18 MSS Code Factory CFDbTest 2.1.12706 Account creation, device creation, and device deletion added to .war

I've added the forms for creating new accounts, creating new devices for an account (and assigning the first device created as the default device for the user), and also implemented device deletion.

Next I need to add facilities for changing the default device for a user, and for editing/changing the public key associated with a device.

Then I'll need to enhance the device creation and edits to verify that the submitted public key is valid and can be converted to a usable object by Java's security APIs. Right now it's just a multiline text blob that doesn't get used for anything.

2014.12.17 MSS Code Factory CFDbTest 2.1.12705 Session lifecycle servlets coded and deployed as .war

The bin directory of the installer now includes a .war file ready for deployment to the container of your choice.

You'll need to install the database driver for your backing store to your server's lib directory, and create a couple of global resource entries for your server:

<Resource driverClassName="org.postgresql.Driver" maxActive="20" maxIdle="10" maxWait="-1" name="CFDbTest21Connection" password="blah" type="javax.sql.DataSource" url="jdbc:postgresql://127.0.0.1:5432/cfdbtst21" username="postgres"/>
<Environment name="CFDbTest21PoolClass" type="java.lang.String" value="net.sourceforge.msscodefactory.cfdbtest.v2_1.CFDbTestPgSql.CFDbTestPgSqlSchemaPool" override="false" />

Then, create a deployment context passing along your global resources:

<Context docBase="cfdbtestwar21" path="/cfdbtestwar21" reloadable="true" source="org.eclipse.jst.jee.server:cfdbtestwar21">
<ResourceLink name="CFDbTest21PoolClass" global="CFDbTest21PoolClass" type="java.lang.String" />
<ResourceLink name="CFDbTest21Connection" global="CFDbTest21Connection" type="javax.sql.DataSource" />
</Context>

Install the .war file to your server, and as long as you've created your database instance, you're ready to start the server. The index.html for the server's mount point will redirect you to a form for setting the "system" user's password.

Once you've set the "system" user's password, you can log in as "system". The password is stored as an SHA-512 value encoded as Base64 in the database, so the only time the password exists as plaintext is during transmission from the form and subsequent processing. When it comes time to deploy production systems, you'll need to make sure the .war is mounted for HTTPS access only.

All you can do now is log out, of course, which destroys the schema cache that was being held by your session.

You should only see the page for setting the system password when you first open any of the servlets on a system that has had a fresh database installation done. If you try to directly navigate to the form used for setting the password, or submit a raw POST to the handler, it will simply redirect you to the login form for the security subsystem.

2014.12.17 MSS Code Factory CFDbTest 2.1.12704 Database connection established from Servlets

The EAR has been removed from the project. The PostgreSQL-specific WAR has been removed from the project.

The server configuration is now used to specify CFDbTest21ConnectionPool (which I have bound to the PostgreSQL driver), and CFDbTest21PoolClass (correspondingly set to net.sourceforge.msscodefactory.cfdbtest.v2_1.CFDbTestPgSql.CFDbTestPgSqlSchemaPool) and the WAR carries all of the database-specific variants of JDBC with it instead of having multiple installations, one per database.

At this point in time, I've got a login page wired to retrieve a backing store instance from the pool, use it, and return it to the pool. Along the way, it issues a redirect to a page that will be used to set the initial system account password before you're allowed to do anything else.

Realistically, this was the hard part. The HTML pages and their processing are pretty trivial compared to getting the stack working.

2014.12.16 MSS Code Factory CFDbTest 2.1.12703 Database scripts back in sync with code

The database scripts are now back in sync with the JDBC code for CFDbTest 2.1. Now I can work on the custom template code for the HTML security interface.

2014.12.16 MSS Code Factory CFDbTest 2.1.12702 Interim build, database scripts do not match

You can't run this build because the database scripts don't match the back end, but it's a clean build of the manufactured code via ant.

Now to deal with the template/custom code in the WARs. Once I have all my templates done, I'll turn the .java files from the WARs into rule-based configurations and manufacture them to bind together the pieces of an application that relies on public key cryptography to secure communications with an end user and to verify the identity of said user. There is nothing to prevent a user from sharing a device id's key amongst several devices via USB key or some such approach if they so choose. I just haven't looked into the details of how that would be done; I'm content to generate and register a different key for each device.

I've taken the first steps of registering a 2048 bit public DSA key for my msobkow@sasktel.net email when accessed from my "Groo" Linux workstation. At some point I'll copy the keys over to the Windows laptop as well, so it can decrypt messages meant for the Linux box. (I don't like the idea of being locked into any one piece of potentially-someday-failing hardware.)

Similarly, I'll generate keys on the Windows laptop, and share them with the Linux box so the Linux box can read messages meant for the laptop.

At some point I'll need to start messing around with a Java Wallet. Ideally I want you to have to sign-on a server during startup to access the private key for the server within its cluster. Remember that all messages from clients to the server have their message bodies encrypted with the cluster's public key, so only the cluster servers can read the messages. However, all client-facing servers (i.e. Tomcat and JEE application servers) in the cluster need to use the same key pair as the other nodes of the cluster. The key presented to connecting clients has to be consistent.

Right now I'm just using GPG, which leaves the private key files accessible to anyone with root access to a given box. That's not secure enough. I want to make sure all keys are stored in an encrypted wallet. Hopefully the Java Wallet APIs can be made to use the KDE Wallet application, the Gnome Wallet (I presume Gnome 3 has a wallet), and, in the worst case, GPG files in the home directory of the user (not recommended for systems where more than one person has sudo access, or knows the password for root.) I'll need to investigate wallet options for Windows 7 as well -- I'd like to hook into the same wallet management tree that Git and FileZilla have access to.

2014.12.15 Programmer's Notes

I'm embarking on the next phase of my pet project: web interfacing.

The obvious first step is to create the installation framework: an EAR (Enterprise Application Resource) of WARs (Web Application Resource), incorporating all the manufactured code needed for each.

So far I've got my ant-produced .jar files wired in to the EAR for deployment. I'm a bit iffy on whether I need to explicitly import the Apache Commons Codec, Log4J, and Xerces jars -- I *think* I inherit those from the web container environment (i.e. They're available/loaded by default in most JEE environments, or are supposed to be installed as system resources rather than application resources.)

The first thing I'll need to code is a page template that redirects you to the login page if no session Authentication has been established yet. I'll be fleshing out my CFSecurity 2.1 model and implementation as I go.

What I want to do is provide an HTML interface over HTTPS to maintain accounts, device keys, and confirmation email account identification. You will not be able to access application data through the HTML interface I intend to provide.

  1. You land on the login page, which lets you manually log in to the system's HTML page environment. Initially, you have to register for a new account with an email address, a device name, a public key, and an HTML session password. The new account has the email address associated with the device, and the device with the public key you registered, and your HTML session password is hashed and stored in the database. An encrypted email is sent to the address using the public key to encrypt the contents. It contains a link to a confirmation page that activates your account after you enter the HTML password.
  2. Every user is a tenant, so once the account is confirmed, a new tenant is created for your email address, and your login is initialized as the tenant administrator. This is set as the default tenant for the account.
  3. The email address used for logins does not need to remain the same throughout the lifetime of an account. The confirmed email address is used to set the account's MailtoEMailAddress. All emails sent to that address by the system will be encrypted using the public key for the default device specified by the account. It is very important not to lose the private keys for your default device, because you can only change the default device while you are able to decrypt the confirmation email. You cannot change your default device after the fact without contacting tech support. You should always have at least two devices registered, so that you can use the alternate device keys if you lose your primary device. Yes, it involves waiting on hold...
  4. If you log in to the HTML page environment again, you have the option of uploading additional device keys with unique device names, removing supported devices and their keys, changing the email address associated with your account, and changing the HTML password. Each of these operations sends an encrypted confirmation email to the email address before the change is enabled.
  5. The cluster's public key should be configured to encrypt all HTTPS connections to the HTML page environment. Under no circumstances should the HTML page environment interface be made available over HTTP without encryption.

Now let's consider the client application logins now that we've got a registered user with a public encryption key. The client application submits a web form that contains a X(ml)Msg request encrypted using the cluster's public key. A GET request to a standard address is used to retrieve the public key for the cluster before any requests are issued to the cluster. All messages sent to the cluster are encrypted using the cluster's public key. The only request that the client issues which is not so encrypted is the GET request for the cluster's public key.

  1. Now that you have an account you can log in from the web application client. You specify your email address and the device name you're connecting from (the device name will have a .rc file default used to populate the field in the application's login page.)
  2. If you haven't already opened your wallet, the Java Wallet APIs are used to open your wallet in order to retrieve the private key for the email address/device combination. You could also store your password for the login in the wallet, I think.
  3. You take a secure hash of your password and encrypt it using the private key for the device. The client application submits the email address, the device name, and the hashed and encrypted password.
  4. The server looks up the public key for the email address and device name, and uses it to decrypt the password hash. The password hash is then hashed again on the server side, and the resulting value is compared to the password stored in the database. If there was no application password set yet for the account, and you are connecting from your default device, the one you just submitted is used to initialize it. Note that I don't do "password confirmation" for this initialization of the password. I'm going to assume you can type.
  5. Password changes will confirm a double entry of the new password; only the initial password setting is not so configured. Should you lose your password, you'll have to contact tech support for a password reset so you can enter a new password from your default device. You can change your application password from any registered device after you've logged in to the application.
  6. The Authentication will be enhanced to carry the public key of the login. All responses to the client will be encrypted using the public key specified.
  7. Initially, your session will be logged into your personal tenant. You can change it later.
  8. The login response provides the session authentication information to the client's session object, which resides on the server. The client never has access to the Authentication object itself. That's entirely server-side code. However, the client is told which cluster and tenant it has connected to, so the public key for the session is used to encrypt the "login success" XML document and send it back to the client.
  9. A customized query will need to be created that identifies all the tenants for which your account has a group membership. Membership in a group is sufficient to indicate that you're allowed at least some access to that tenant's data. Any time after you've logged in, you can change tenants to one of those listed by the customized query. In the SecSession table, each time you change tenants the old session is terminated and a new one initiated for the new tenancy binding. All information cached by the server and the client are cleared when the tenant is changed, so that you have no stale/secure data from the previous tenant hanging around. For the GUI, that also means the copy-paste buffer has to be cleared to empty.

Note that as I develop this code, I'm also going to have to start manufacturing some security initialization scripts for the tenants and clusters. There has to be a ClusterAdmin and a TenantAdmin group for each that can be initially set to include the new account for a Tenant, which grants them full access to all data owned by the Tenant. Part and parcel of that will be some changes to the SAX XML loader such that the command-line parameter Cluster and Tenant are used to override any values in the loaded file, so that the specification of the Cluster and Tenant can be use to load a security initialization XML document into a Tenant after the Tenant is created.

I'll have to figure out how to load that document into a newly created Tenant automatically at some point as part of the account creation process.

A composite business application model can answer to requests from a web client written to any of its component models. Thus you can use a CFSecurity 2.1 web client to maintain your security keys and passwords for any application deployment. The key is going to be ensuring that the necessary security servlets are produced to the appropriate $schemaname$ear$version$, $schemaname$[database]war$version$, and $schemaname$war$version$ are produced so that all applicatons share the same security screens and remote messaging methods. This will also be the first time I exercise the X(ml)Msg layer customization tags, so I may find I have to go back and add something more yet.

Remember, I have no intention of developing a web interface in HTML. My goal is merely to support account setup and maintenance through security HTML screens, and process X(ml)Msg requests from the client application. To me, the web is just another messaging transport layer.

2014.12.14 MSS Code Factory 2.1.12700 Rebuilt with refreshed code

There are changes to the CFBam 2.1 model in the MSS Code Factory 2.0 Git archives, but a release will not be posted just to share those changes. Similarly, the code has been checked in to Git for CFBam 2.1, but a repackaging hasn't been done because only the layers used by MSS Code Factory 2.1 have been refreshed.

Use the versions of the CFBam .jar and src.zip files from the 2.1 java/bin directory for your builds of this code, or pull fresh updates via Git.

MSS Code Factory 2.1 is an internal development release. You should use the 2.0 builds for production systems, and the 2.1 code that those builds produce.

2012.12.13 MSS Code Factory CF* 2.1.12699 The published 2.1 projects have been refreshed and packaged

The published 2.1 projects including CFSecurity, CFInternet, CFCrm, CFDbTest, CFAcc, CFAsterisk, CFEnSyntax, and CFFreeSwitch have been refreshed by 2.0.12696, rebuilt using CFCore 2.0.12698, and repackaged. CFBam 2.1 is being refreshed again with corrections for the MSS Code Factory 2.1 build itself.

MSS Code Factory 2.1 is for internal use; use 2.0 for production systems.

Since 2014.12.05, an additional 13,545,302 lines of code have been created. Over 8 days, that works out to 1,693,162 lines of code per day. 70,548 lines per hour, 1,175 lines per minute, or 19 lines a second. Now that would take some furious typing by quite a large horde of junior programmers using editors instead of MSS Code Factory. And I got most of that all done in the last 30 hours of the 8 days using a laptop that costs under $1,000.

Project Prior Total Lines New Total Lines Lines Added
CF main 2.0 326,563 353,473 26,910
CFLib 2.1 18,653 18,653 0
CFCore 2.1 283,107 283,642 535
CFSecurity 2.1 778,400 854,474 76,074
CFInternet 2.1 1,206,519 1,326,834 120,315
CFCrm 2.1 1,714,301 1,882,484 168,183
CFAcc 2.1 2,116,354 2,327,511 211,157
CFAsterisk 2.1 1,573,490 1,736,767 163,277
CFBam 2.1 11,970,454 13,641,094 1,670,640
CFDbTest 2.1 5,757,749 6,527,548 769,799
CFEnSyntax 2.1 1,401,042 1,539,320 138,278
CFFreeSwitch 2.1 2,066,931 2,267,065 200,134
TOTAL 19,213,563 32,758,865 13,545,302

2012.12.13 MSS Code Factory CFCore 2.1.12698 Refreshed build with code produced by 2.0.12696 SP2

CFCore 2.1 has been refreshed by MSS Code Factory 2.0.12696. The core objects used by CFCore are all manufactured; less than 5% of the code for the package is hand written.

2014.12.12 MSS Code Factory CFDbTest 2.1.12697 Test suite for 2.0.12696 SAP/Sybase ASE 16.0 support

This is the complete test suite for SAP/Sybase ASE 16.0, including support for Chains.

2014.12.11 MSS Code Factory CFDbTest 2.1.12695 Test suite for 2.0.12694 with Sybase ASE 16.0 support (Chains TBD)

The Chains are not implemented yet, and there is a known bug with Sybase ASE and client-side SQL (see 2.0 release history for details), but most of the CFDbTest 2.1 regression tests for Sybase ASE 16.0 pass with this build.

2014.12.07 MSS Code Factory Distribution 2.1.12687 The 2.1 distribution has been remanufacutred by 2.0.12684

The 2.1 distribution has been remanufactured by 2.0.12684 and rebuilt with debug information enabled. Even MSS Code Factory 2.1 itself is now built with debug enabled.

2014.12.07 MSS Code Factory Core Distribution 2.1.12685 The 2.1 core distribution projects have refreshed by 2.0.12684

The core 2.1 distribution projects (MSS Code Factory 2.1, CFSecurity 2.1, CFIternet 2.1, and CFCrm 2.1) have been refreshed and updated to use the latest code provided by MSS Code Factory 2.0.12684.

2014.12.05 MSS Code Factory 2.1.12682 Stop producing log files

The generation log file has to be created and deleted to avoid sucking back memory with the backlog buffer, but seeing as I've been running MSS Code Factory in parallel, the log files haven't even been glanced at for a couple of years because I know they're garbage.

Use tee to save the stdout and stderr streams of the manufacturing process instead.

2014.12.05 MSS Code Factory 2.1.12680 Corrected CFCrm 2.2 model

The CFCrm 2.2 model did not properly specify IsXsdContainer="true" for four relationships of the model, the same as was discovered for CFCrm 2.1.

2014.12.06 MSS Code Factory 2.1.12677 Corrected defect for Relationship imports

The IsXsdContainer attribute wasn't being carried through properly by the SchemaRef element's import of a referenced SchemaDef.Table.Relation. Without the correct values in place, the code produced for the SAX structured object parsers was incorrect, because it wasn't properly considering imported relationships to be XML element containers.

Quite frankly, I don't know whey the code worked for 2.0/2.1 in the first place and was only detected when using 2.1 to produce and exercise CFDbTest 2.2. Obviously something changed, but what? The rules were just ported forward, and so was the engine code. The only thing that makes sense is that the value initializations for the boolean requiredIsXsdContainer attributes of the buffers were defaulting to true instead of false, causing *all* components relationships to be considered and evaluated as possible XML element container relationships. Given the way I determine whether a given instance *can* be an element of a container element, it's entirely possible that my code was just successfully filtering out candidates that should never have been XSD elements in the first place. It *is* pretty thorough in its consideration of the class hierarchies being evaluated.

2014.12.06 MSS Code Factory 2.1.12675 Repackaged with corrected run scripts

The testing had only been done with Eclipse, so I didn't notice until now that the launcher scripts for 2.1 weren't correct. They needed to search the package path "v2_1" not "v2_0".

2014.12.06 MSS Code Factory CF* 2.1.12674 Repackaged with CFCore 2.1.12672

With CFCore 2.1 debugged, I thought it might be an idea to repackage and ship the code with the fixes in place.

2014.12.05 MSS Code Factory 2.1.12673 Initial testing complete: it produces code

The initial testing and debugging is complete. 2.1 now produces code.

2014.12.05 MSS Code Factory CFCore 2.1.12672 Second bug fix for CFCore 2.1

The second bug fix for CFCore 2.1 required modifying the model in the 2.0 distribution to specify the custom code for GEL Boilerplate instances. They weren't overloading the expansion methods properly.

2014.12.05 MSS Code Factory CFCore 2.1.12670 The first bug fix for CFCore 2.1

The table instances were being initialized by the superclass, so the overloaded factory methods weren't getting invoked.

2014.12.05 MSS Code Factory CFCore 2.1.12669 Shifted from s1genkb-1.9 to cfgenkb-2.1

The schema parsers and XSDs have been refreshed to reference cfgenkb-2.1-* instead of s1genkb-1.9-* for grammar names.

2014.12.05 MSS Code Factory 2.1.12668 Initial clean build

This build is completely untested at this point, but it only took a little over an hour to migrate the MSS Code Factory 2.0 code to 2.1. There were, of course, a lot of edits, but most of those were handled by the EditJava.bash script and its accompanying edits_to_apply.ex script in the java directory of 2.1.

2014.12.05 MSS Code Factory CF* 2.1.12667 All 2.1 projects now available for download

All of the 2.1 projects have been manufactured by MSS Code Factory 2.0.12666, built, packaged, and are ready for download.

It took just short of 29 hours to manufacture CFBam 2.1 with a single thread on my laptop (I was doing other projects at the time, so I couldn't use my three-part jobs, which cut the time to about 10 hours.)

The 2.0 project itself started on 2014.11.18, so in 17 days, a grand total of 19,213,563 lines have been integrated, migrated, merged, updated, manufactured, built, tested, packaged, and released to production for download. That works out to 1,718,444 lines per day, 71,601 lines per hour, 1,193 lines per minute, or 19 lines per second. My fingers are tired. :P

Project Prior Total Lines New Total Lines Lines Added
CF main 2.0 0 326,563 326,563
CFLib 2.1 0 18,653 18,653
CFCore 2.1 0 283,107 283,107
CFSecurity 2.1 0 778,400 778,400
CFInternet 2.1 0 1,206,519 1,206,519
CFCrm 2.1 0 1,714,301 1,714,301
CFAcc 2.1 0 2,116,354 2,116,354
CFAsterisk 2.1 0 1,573,490 1,573,490
CFBam 2.1 0 11,970,454 11,970,454
CFDbTest 2.1 0 5,757,749 5,757,749
CFEnSyntax 2.1 0 1,401,042 1,401,042
CFFreeSwitch 2.1 0 2,066,931 2,066,931
TOTAL 0 19,213,563 19,213,563

2014.12.04 MSS Code Factory CFFreeSwitch 2.1.12665 Added to the 2.1 model and build set

CFFreeSwitch 2.1 has been manufactured and its code built and packaged.

2014.12.04 MSS Code Factory CFEnSyntax 2.1.12664 Added to the 2.1 model and build set

CFEnSyntax 2.1 has been manufactured and its code built and packaged.

2014.12.04 MSS Code Factory CFAsterisk 2.1.12663 Added to the 2.1 model and build set

CFAsterisk 2.1 has been manufactured and its code built and packaged.

2014.12.04 MSS Code Factory CF* 2.1.12662 build.xml and packaging corrected

The 2.1 projects had a bad target specification for the Swing MySQL package. This has been corrected, the build refreshed, and the packaging updated for each of CFSecurity, CFInternet, CFCrm, CFDbTest, and CFAcc 2.1.

2014.12.04 MSS Code Factory CFAcc 2.1.12660 Initial release

The Code Factory Accounting model has been migrated to 2.0 and the corresponding 2.1 code has been manufactured and built.

2014.12.04 MSS Code Factory CFCrm 2.1.12658 Initial release

The Code Factory Customer Relations Management model has been migrated to 2.0 and the 2.1 code has been manufactured and built.

2014.12.03 MSS Code Factory CF* 2.1.12656 Latest code manufactured by 2.0.12655 Alpha 1

CFSecurity 2.1, CFInternet 2.1, and CFDbTest 2.1 now are equivalent to the 2.0 release of the same, as MSS Code Factory 2.0.12655 Alpha 1 completed the migration of the rule bases to 2.0.

2014.12.03 MSS Code Factory CFSecurity, CFInternet 2.1.12654 Refreshed by 2.0.12652 with SQL Server support

SQL Server support has been added to CFSecurity 2.1 and CFInternet 2.1.

2014.12.03 MSS Code Factory CFDbTest 2.1.12653 Test suite for 2.0.12652 SQL Server support

The migrated SQL Server database scripts and JDBC implementation passed their CFDbTest 2.1 regression tests.

2014.12.02 MSS Code Factory CFSecurity, CFInternet 2.1.12651 Refreshed by 2.0.12649 with MySQL support

CFSecurity 2.1 and CFInternet 2.1 have been refereshed by MSS Code Factory 2.0.12649, adding support for MySQL.

2014.12.02 MSS Code Factory CFDbTest 2.1.12650 Test suite for 2.0.12649 MySQL support

The migrated MySQL database creation scripts and JDBC implementation passed their CFDbTest 2.1 regression tests.

2014.12.02 MSS Code Factory CF* 2.1.12648 Code Factory binding added to build

The MssCF code bindings have been added to the builds for the CFSecurity, CFInternet, and CFDbTest 2.1 projects.

2014.12.02 MSS Code Factory CFCore 2.1.12646 Initial test release of CFCore 2.1

The core functionality encapsulated in the MssCF package of CFCore has been migrated from 1.11 to 2.1, along with the migration of the business logic from 1.11's GenKbBLObj layer to the Java customization elements of the CFCore 2.1 model itself. The changes made to the MssCF code were relatively trivial compared to the modelling effort.

2014.12.02 MSS Code Factory CFCore 2.1.12644 Initial build of manufactured code only

The custom code from CFCore 1.11 has not been migrated yet; this is just a build of the manufactured code base.

2014.12.01 MSS Code Factory CFSecurity, CFInternet 2.1.12641 Updated with Oracle support

The Oracle support code has been manufactured and built for CFSecurity 2.1 and CFInternet 2.1.

2014.12.01 MSS Code Factory CFDbTest 2.1.12640 Test suite for 2.0.12639 Oracle support

The migrated Oracle database creation scripts and JDBC implementation passed their CFDbTest 2.1 regression tests.

2014.12.01 MSS Code Factory CFSecurity, CFInternet 2.1.12638 Refreshed core jars with DB/2 LUW support

The CFSecurity 2.1 and CFInternet 2.1 distributions have been updated with DB/2 LUW support.

2014.12.01 MSS Code Factory CFDbTest 2.1.12637 Test suite for 2.0.12636 DB/2 LUW support

The DB/2 LUW JDBC, SAX Parser main, and X(ml)Msg loader mains all passed their regression tests. DB/2 LUW is now ready for use.

2014.11.30 MSS Code Factory CFDbTest 2.1.12635 Test suite for 2.0.12634 PostgreSQL support

The PostgreSQL and X(ml)Msg layer testing for CFDbTest 2.1 has been passed. The PostgreSQL migration is done.

2014.11.30 MSS Code Factory CFSecurity, CFInternet 2.1.12632 Clean build of PostgreSQL support

The database creation scripts and a clean build of the JDBC code for PostgreSQL are now available for CFSecurity 2.1 and CFInternet 2.1.

2014.11.30 MSS Code Factory CFDbTest 2.1.12631 Clean build of CFDbTest 2.1 PostgreSQL support

The CFDbTest 2.1 PostgreSQL database creation scripts run properly, and the JDBC layer along with the mains for SAX and X(ml)Msg loaders compile as well. I just need to migrate the launcher scripts so I can exercise the PostgreSQL database implementation to make sure it works correctly, then I'll do the runs for CFSecurity 2.1 and CFInternet 2.1.

Tomorrow.

2014.11.29 MSS Code Factory CF* 2.1.12625 Refreshed with java+xmsg support by 2.0.12624

CFSecurity, CFInternet, and CFDbTest 2.1 have all been remanufactured by MSS Code Factory 2.0.12624, adding support for the Java X(ml)Msg layers.

2014.11.28 MSS Code Factory CFInternet 2.1.12622 Refreshed by 2.0.12619

The latest code manufactured by MSS Code Factory 2.0.12619 has been built and packaged for CFInternet 2.1.

2014.11.28 MSS Code Factory CFSecurity 2.1.12621 Refreshed by 2.0.12619

The latest code manufactured by MSS Code Factory 2.0.12619 has been built and packaged for CFSecurity 2.1.

2014.11.28 MSS Code Factory CFDbTest 2.1.12620 Test suite for 2.0.12619

CFDbTest 2.0 now passes all of the RAM SAX Loader tests.

2014.11.28 MSS Code Factory CFDbTest 2.1.12618 Clean-building structured SAX XML parser code

This is a clean-building version of the structured SAX XML parser code with the appropriate main for running the parser with a RAM storage module. This is sufficient for me to be able to bring over some of the CFDbTest 2.0 test data and scripts to verify that the 2.1 code actually runs properly, at least for in-memory data.

2014.11.26 MSS Code Factory CFDbTest 2.1.12616 Initial release built and packaged

Producing a clean build of CFDbTest 2.1 proved to be a challenge, as expected. This model exercises just about every feature MSS Code Factory has to offer, so it exposed a lot of "gotchas" in the migrated rule base for the core Java objects.

2014.11.26 MSS Code Factory CFInternet 2.1.12613 Initial release built and packaged

Once a few minor issues with the rules and custom verbs were addressed, CFSecurity 2.1 manufactured with no missing tags and built clean.

2014.11.26 MSS Code Factory CFSecurity 2.1.12611 Updated to support CFLib 2.1.12609

Remanufactured by MSS Code Factory 2.0.12610 and rebuilt and repackaged with CFLib 2.1.12609.

2014.11.26 MSS Code Factory CFLib 2.1.12609 Initial release

This is the initial release of the CFLib code migrated and modified from CFLib 1.11. Note that it is not source-compatible with 1.11.

2014.11.25 MSS Code Factory CFSecurity 2.1.12608 Clean build

CFSecurity 2.1 initial release of clean build of core object code.