Mark's Code Fractal   

MSS Code Factory 2.13 alpha10 is now available at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha10. You can find installation instructions at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/ and the README.md displayed there. There have also been releases of the 2.13 knowledge base and model set as of 2026-08-19 03:45 CST, tagged as snapshot-202608190345 which are included in the installer and are required alongside the executable jars to run the tool. Alpha10 continues to flesh out use of the CodeVis attributes to produce pub and prot interfaces and implementations, but the code produced by Alpha10 does not clean compile yet. This alpha is being released primarily to capture the executable changes that are required to use the latest versions of the knowledge base as I proceed forward.

I haven't forgotten about the Role implementations; this current task has proven to be more fun to work on, and entertainment value is big on my priority list as I'm working on this while "retired" from life. Not that I've given up on ever "striking it rich" through my own efforts; I just realistically assess my odds of such rewards as less than the chances of winning Lotto 6/49 in Canada.

I've been banging away at the keyboard the past few weeks, and a whole plethora of code is getting properly synchronized and refactored at this time, though there are a number of method stubs to flesh out for special cases as a result. I have the old general case rules in the same file under different names, so it's a matter of copy-pasting their implementations and tweaking them for the specialization in question (special cases like atomic primary keys, which are always an object value instance rather than an embeddable composite object, and have to be handled differently for just about every branch of code (my so-called "Column" rules) than the composite key versions (the "Inst" rules.))

There are also rules in the old set that are necessary for fleshing out the details, such as the ones that distinguish between Singleton and Duplicate getter implementations and signatures. Once I'm done, the only vestige of the original knowledge base left will be the basic rules that handle schema and type name resolutions, the mapping from modelled data types to java data types and implementations, and a large portion of the Obj layer - for now. That gets refactored and rewritten after I'm done layering the buffers into private (original internal data structures and interfaces), Prot(ected), and Pub(lic) variants.

Then I tackle refactoring the HashMap usage in the Obj layer into ConcurrentHashMap code with careful restructuring and reworking of the allow concurrent lockless modification of the data objects, with sychronization only during key operations, such as replacing an object during a mutation. During a mutation, for example, the original object gets synchronized and the replacement gets synchronized, and only then is the swap is made and propagated through the data structure hierarchy, and only after the swap is completely propagated are the synchronization locks released and the replacement instance returned as the current value of the Obj instance in play for a given key (the so-called "Realized" instance.)

Normal operations like adding an object to an index key hashmap data set only use the set(expected,tobeapplied) variants of HashMap calls instead of get/put, same as with AtomicReference values that litter my code base nowadays. I learned a lot about asynchronous programming on my last job; this thing is going to scale like a beast!

Once I'm done with the ConcurrentHashMap changes for the Obj layer, then ProtObj and PubObj layers get spun off from Obj via copy-paste-edits. At that point I've got complete backend data sets for public, private, and protected data that is available for inheritance by schema reference (public), available to service implementations and the application's user interface (protected), or internal to the back-end server implementation (private.)

As of 2026-08-19 03:45 CST, there were 5,293,667 lines of clean-compiling code in the ever-growing 3.1 code base. That is 244,278 more lines than on 2026-07-09, for an average of 5,958 new lines of code per day.

2026-08-26 03:00 CST

With a great deal of continuous effort for the past 4 hours or so, I've been able to not only eliminate the stack overflows, but to get most of the rules rationalized and simplified such that there is minimal expansion required to express a code fragment. Although this might seem minor in nature, optimizing the code production logic and rule flows means the JPA refactoring to comply with the layered data it will need to talk to will be smaller in scope. Primarily, that effort involves merging the new private buffer layer rules with the JPA rules as Jpa variants instead of Buff variants, and with a new Candidate variant of the JPA support. Then the JPA rules have to use the Buff variant rules for non-candidate logic, but Candidate variants for supported tables within the schema that comply with hard-coded restrictions in the engine core.

2026-08-25 22:00 CST

The stack overflow is resolved again, but who knows for how long considering I'm getting the implIJavaOptAtomType resolution errors again. I'll figure that bit out some other time.

2026-08-25 06:00 CST

Fix one problem, and low and behold I bring back stack overflows. This is getting very annoying.

2026-08-25 04:10 CST

I've once again eliminated the recursion and resulting stack overflow errors, but who knows how long that will be the case, because now I have some issues resolving IJavaReqAtomType and IJavaOptAtomType. Not sure what the root cause of that is yet.

2026-08-23 20:45 CST

I give up for now. I've reworked and reworked and reworked expansion rules but still get stack overflows. I know I'm close to a final solution, but somewhere it is eluding me.

2026-08-23 16:30 CST

Enough for now; time for visiting.

2026-08-23 12:25 CST

Time for a break; I've been at it all morning.

2026-08-23 11:45 CST

Things are coming along, but I still have stack overflows (I had gotten rid of them, but they are back again. Such is life.)

2026-08-23 05:05 CST

Enough for now. It moved again, but it is still not gone for good. Pest. Damned bug. Cursed bug. Annoying bug. Irritating bug. I will take GREAT pleasure in SQUISHING this particular bug eventually!

2026-08-23 01:45 CST

A lot of progress has been made, but there is still a stack overflow occurring during code production. It happens later in the process than it used to, but it still kills the job, and will have to be resolved. But not tonight. I need to wind down, relax, and eventually get some sleep. A lot of code is temporarily missing as a result.

2026-08-22 07:00 CST

Excellent progress on the protected table buffers; now all I see is the plethora of duplicate method definition errors caused by the fact that the "tweaked" "Normal" branches of code step on the same namespace as the "Prot" branches of the code.

2026-08-21 23:30 CST

There are 5,724,210 lines of code to 3.1 tonight with the addition of the protected tables; 430,543 new lines in only two days. No productivity here at all!

2026-08-21 23:00 CST

The protected tables get created now, but they don't clean-compile yet. One step at a time.

2026-08-21 19:15 CST

The rules don't cause infite recursion any more, but there are still some gotchas on the protected table implementations.

2026-08-21 13:55 CST

The schemaprotbuff/buff/SchemaProtBuffTable.java.xml file has been updated sufficiently to get rid of all the duplicate rule names and to implement the missing JustProt variants required, but I'm getting a stack overflow - I suspect I've either got some bad rule nesting causing an infinite loop or an error in the implementation of the engine custom verbs for IsPublic, IsProtected, and IsPrivate.

2026-08-20 02:00 CST

I'm working on the protected buffer record implementations right now; there are a lot of rule conflicts after my bulk edits to be cleaned up and corrected, but not only will I get there, I'll get there tonight if I have my way! In the meantime, King Gizzard and The Lizard Wizard are deelie-bopping some synthetic tonal energy in my workspace and keeping me quite perky despite the late hour.

2026-08-19 03:45 CST

MSS Code Factory alpha10 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha10.

2026-08-19 02:10 CST

Things are really starting to come together now; the key issue remaining is the interface specifiers for the Pub and Prot layers reference Private and/or Protected data that they can't see from their layer. I know how to fix this, but not tonight - it's past 2 in the morning and I'd rather relax a while before going to bed. I'll have to issue a new alpha when I've got the base layer clean-compiling all the code changes I plan on making, but that is a fair bit down the road yet, probably not until near the end of the month, possibly the beginning of September if not by end of August.

2026-08-18 16:35 CST

Things have made a great deal of progress with the knowledge base. There are new errors that have cropped up, but code of some kind is produced for pretty much every case I want, but without duplicate references anywhere. Nice stuff. There are 5,293,667 lines of code produced for 3.1 right now, 244,278 more than on 2026-07-09, for an average of 6,106 new lines of cod per day.

2026-08-18 07:10 CST

Most of the expansions have been fleshed out now, but a few discrepencies remain that are likely caused by misnamed expansion references for rules that really do exist under similar but not quite exactly the same names. As I've spent the past nine hours poking and prodding at such errors and issues to get this far, I've decided to take a break, enjoy some of this glorious morning, and get some sleep in a little while. I may be a night owl, but eventually I do sleep - just not when so-called 'normal' people do.

2026-08-17 03:25 CST

I think I had best get some sleep now that I've fixed a few more issues with the code produced by the knowledge base. Things continue to grow and improve, but there are still a lot of gaps, particularly with the production of the relationship getters and setters.

2026-08-17 00:00 CST

There are currently 5,270,013 lines of code to 3.1; an increase of 221,000 lines of code since 2026-07-09, or an average 5,666 lines per day for the past 39 days. That number will only go up when I resolve the issues with the getters and setters in the buffers, and again when I propagate the buffer objects to the protected and public versions of them.

2026-08-16 23:25 CST

Of course I just had to make the first pass at fixing the conflict between CFLibUuid6 and the newly refactored CFLibDbUuid6 variant in dbutil, and modify the JPA rules accordingly.

2026-08-16 21:00 CST

This is the end of the night for me; the missing references to the keyhash subpackage have been resolved, and now I'm seeing conflicts between CFLibUuid6 in dbutil and keyhash; the version in dbutil will be refactored to DbUuid6 so they can be distinguished properly, and the type references in the knowledge base updated accordingly after I'm done with the refactoring. But not right now. I'm done for the day.

2026-08-16 19:50 CST

With the changeover to using the interface form of implJavaAtomType, implJavaOptAtomType, and implJavaReqAtomType as implIJavaAtomType, implIJavaOptAtomType, and implIJavaReqAtomType respectively, the code now defaults to specifying interfaces all over the place, but not without some gotchas, glitches, and errors along the way caused by some of my bulk .ex script editing. I'll clean it up some other time; for tonight I'm going to relax and unwind until going to bed.

2026-08-15 19:00 CST

The use of the new interface, buffer, and JPA data types begins.

2026-08-16 11:50 CST

The hash types now reference the interfaces for all copy-constructors instead of instances, which will make it a lot easier to clone data back and forth between buffers and JPA entities and keys. References to constructors to be used have been cleaned up as well, and I think I could almost make the byte array in the buffer implementations final, because buffer keys never get updated by the JPA back-end, which means they'd be pure final classes, allowing for further code optimizations by the Java compiler for the buffer layers.

2026-08-16 06:10 CST

The DbKeyHash types have been extracted into KeyHash interfaces in CFLib, with appropriate KeyHash implementations. The DbKeyHash implementations now import and reference the KeyHash interfaces so that both the KeyHash and DbKeyHash implementations share a common interface specification. Now I can modify the column type mappings in the rules to specify the interfaces for hash types in the interface-defining rules, but use the implementations as appropriate to the layer being produced. This will require two branches of rules - one for the interfaces, the existing ones need to be modified to reference the KeyHash types, and a Jpa variant that uses the DbKeyHash types. The end result of this is that you won't have to reference Jakarta for the base objects any more, only when you're actually working with JPA.

2026-08-14 17:30 CST

Steps forward, steps backwards, but at least steps of progress are being made.

2026-08-14 10:30 CST

Despite much effort, I'm still seeing duplicate method definitions for some objects and missing implementations for other objects. There is definitely a logic error to be figured out somewhere, but I guess it is going to take a fair amount of time to do.

2026-08-14 04:20 CST

There are a bunch of duplicate methods defined in the base layer buffer records right now, which I'll have to chase down, but it is worth noting that means that all the methods are finally properly defined by those objects; no other errors are reported for those .java files.

2026-08-13 20:30 CST

I need to dereference the correct variant of Schema, either Pub or normal, when evaluating the target readDerivedBlah() invocations. The pub prefixing of those invocations is correct, but I need to wire in the appropriate hooks to dereference the Normal schema or the Pub schema before retrieving the named table interface from it. At this time there are 5,280,672 lines of code in the 3.1 code base, an increase of 231,283 lines in only 36 days, for an average of 6,424 new lines of clean-compiling code per day. Just watch me go: I'll definitely get there eventually!

2026-08-13 11:10 CST

The production of the relationship setters by argument has been restored, but now I'm seeing issues with derived getters and setters. It'll come together eventually.

2026-08-13 05:50 CST

Working on the relationship rules for the table buffer records; neglected to flesh out Normal vs. Pub specifications, with normals cascading into Prot and Pub where applicable. Still have a couple 'gotchas' to resolve, but I've been at it for 4-5 hours so it's time for a check-in.

2026-08-12 18:00 CST

The rules that produce the narrowed and buffer record relationship argument setters for singletons now clean compile and should work pretty much perfectly. Now to get the instance-specific implementations worked out. There are now 5,275,222 lines of code to the 3.1 code base - an increase of 225,833 lines in 35 days for an average of 6,452 lines per day of new, clean-compiling code. Whoop, there it is!

2026-08-12 14:45 CST

This variation on the table buffer record creation rules implements relationship narrowing for duplicate key getters, singleton key by-argument setters, overloads of narrowed relationship argument setters and getters, but still needs to expound upon the singleton setters for object reference cases. I realize those invoke the by-args setters for buffers under the hood, but they won't be coded the same under JPA and I have to keep that in mind when I implement the narrowing overloads for those cases later in the day. I do expect to finish the narrowing code today before I call it a night, and have it clean-compiling to whatever degree I can test it.

2026-08-10 07:40 CST

The issues with the scoping of the INIT_VALUE definitions has finally been resolved. Nothing else, but that was persnickity enough!

2026-08-10 03:45 CST

Tried something, but it didn't work. I think I'm on the right track, though - for Enum specifications in this special case, I need to get the init value of the Enum definition's emitSchemaCodeVis value, not the column's emitSchemaCodeVis value, and use the Enum's INIT_VALUE instead of the column's in cases that follow the pattern 'fromHex.*toString'.

2026-08-10 00:15 CST

Remove the 2.13 checks for inPrimaryIndexKey() for the column permission checks isPrivate, isProtected, etc.

2026-08-09 19:10 CST

With these corrections to produce missing methods for the primary keys of data buffers, a lot of the errors have finally disappeared. Getting rid of the duplicate method definitions was also helpful. I'm now down to some expected issues, though I realize there is definitely a problem with the implementations of IsPublic, IsPrivate, and IsProtected because of the Pub references for Private password history table references. I'm definitely done for the day now that I feel content to have solved those issues. Contentment is important when coding for fun!

2026-08-09 17:50 CST

Cleaned up some of the errors in the code produced, but the knowledge base still needs some fine tweaking to resolve the remaining errors. I'll get there properly this time, unlike my last attempt that got backed out this morning. That is probably it for today.

2026-08-09 15:30 CST

Restored knowledge base from before I accidentally edited too much, made some minor changes to emitCodeVis rules, and regenned 3.1 code. This is the end result of those efforts.

2026-08-08 05:30 CST

The production of the code that I used to have in place now works again; the errors currently being reported are related to the factories, not the table indexes, primary key objects, or table buffer definitions. I'll break that again soon with a proper reworking of the history tables and keys.

2026-08-07 12:10 CST

Things are coming along nicely, and some of the code looked like it was building briefly because entire files and directories were empty so I was seeing the production of empty packages fly by. Those issues have been resolved. This is an all or nothing tool; either you have valid inputs or you don't. There is no arguing with it's sanity checks. There are now 5,270,066 glorious lines of broken 3.1 code produced and written by hand respective of the package in question, an increase of 220677 lines since 2026-07-09 when this effort began. I'm probably quite a long way from completion, but it is more an issue of getting the base layer cleaned up again and then propagating the newly-corrected table record buffer object into the prot layer as a prot buffer. Then come the index keys (which are relatively easy because they always use direct attribute instances and direct column accessors with no relationship support inherent to them at all. Note that primary keys don't support relations either; that would cause issues for the JPA layer. It's better and easier to keep all key objects "clean" but with appropriate getter and setter instances for easy assignment from other objects in the package, such as the table history buffers, and equality and comparison checks against those objects as well as between themselves, with orthogonal comparison and equality checks in the record buffer and history objects to keep things following a pure Java contract in intent despite the lack of true multiple inheritance in the language itself. Under the hood, it's all polymorphic, baby!

2026-08-06 12:15 CST

Cleaned up the initializers for SecSession and SecUser references.

2026-08-06 06:00 CST

All the statements needed get produced, but many of the getters and setters reference S_INIT values that aren't available where I need them to be. I'll figure it out eventually; one key factor might be to switch to direct getters and setters instead of pkey wrappers, at least for the pkeys themselves.

2026-08-05 18:00 CST

At long last the Prot layer compiles, but now I get errors in the base layer because of the changes I made to fix the issues along the way. I'll have to retrofit my changes accordingly.

2026-08-05 13:45 CST

Still no joy, but a lot of knowledge base tweaking.

2026-08-05 12:55 CST

The getters are fixed, now I see the undeclared setter errors for the protected primary keys. Most likely they're not being expanded via setDirect, but by a version of the rules that checks for superior relationships and skips the setter if they exist. Simple enough to fix, but not right now - I want to save away this almost clean compiling version of the Prot layer first.

2026-08-05 12:00 CST

Working of the direct value getter implementations; they're returning an empty statement that causes compile errors. Somewhere I've got the wrong expansion name being used, because the method is being declared properly, it is just the return statement in error. What is really confusing is the setter is correct, so the DirectSetter implementations are coded properly, but the Getters are in error.

2026-08-03 19:50 CST

That's enough of this nonsense for today. I'm getting frustrated, which means it's time to call an end to it after 10+ hours at the keyboard. I'm done until tomorrow.

2026-08-03 11:15 CST

There are currently 5,273,643 lines of code in 3.1; an increase of 224,254 lines in only 25 days since 2026-07-09, or 8,970 lines per day added. I'm not productive at all with my tool.

2026-08-03 11:10 CST

There are still errors in the files for some enum type references in the getters and setters, yet the definition of the data attribute in the same files is valid. Go figure. The bulk and worst of the errors that had been resulting in empty files (particularly in CFBam) have been resolved.

2026-08-03 10:35 CST

A tremendous amount of work has been done to reference the proper versions of Min, Max, Init, and MaxLen values to validate getters and setters. There are still some errors in the resulting code, but it looks pretty good at this point save for those few exceptions which cause some files to be left empty and others to have bad source code syntax.

2026-08-02 01:30 CST

The Pub version of the table/record/buffer interface specification has been refreshed to comply with the latest signatures.

2026-08-01 23:30 CST

The issue with the 'reference Table IsProtected' and 'reference Table IsPublic' errors has been corrected.

2026-08-01 19:45 CST

There is an annoying 'reference Table IsProtected' that is invalid somewhere in the rules...

2026-08-01 14:10 CST

At long last the buffer objects for the base layer clean compile. Now to move on to the history object counterparts, then I can procede with the enhancement of the equals() and compareTo() implementations for the record buffers, the primary keys, the index keys, and the history objects to make sure they are completely orthogonal, with the sole exception that an atomic primary key intrinsic wrapper has to be implicily compared to the atomic primary key column of a buffer, but there can be no orhtogonal comparison in the reverse direction because you can't extend atomic wrappers to specialize them in any way. They're final objects. There are now 5,260,196 lines of code in the 3.1 code base, an increase of roughly 220,000 lines since the 9th of last month when I began this data hiding effort.

2026-08-01 11:30 CST

The majority of the errors with building the buffer objects for the records have been resolved. A few issues remain, which simply require having the relationshipper setter invoke the recently added column setters instead of trying to manipulate the column directly. This will prevent the kind of issues I've been having with the build be deferring the resolution of the data to the setter for the column instead of having to add yet another branch of complex resolution rules for this special case. It is a common enough case that it has to be resolved correctly, though, and the next round of changes will do so. It has just been a long and busy morning and time for a commit and a break.

2026-07-31 21:00 CST

This commit is largely about clarifying implementation details for the relationship setters, which now all adapt their behaviour properly according to whether they are working with a null or instance specification as the input argument to be applied. Optionality is now considered and verified, with a null argument exception being thrown if the setter is invoked with a null for a required reference.

2026-07-31 19:30 CST

Several more of the methods for the record buffers have been fleshed out, and several objects now have an implementation of some kind for every method that was specified by their interface, providing phase 1 of getting the contracts implemented. Most of the implementations are valid as well, but there are some instances where there are undefined column attributes in the objects that should have been declared. I need to make sure those are actually the _column_ attributes missing, or whether these are code cases that should be deferring their implementations to the PKey interface specifications (e.g. setCol(Type var) should be invoking 'getPKey.setCol(var)', not doing a direct '$lower implColumnAttrOptionality$$Name$ = var;' setting.)

2026-07-31 11:55 CST

This little set of rule tweaks corrects the PKey atomic id getter/setter interactions to prevent the infinite loop that would have happened with getPKey() invoking getCol() invoking getPKey()...

2026-07-31 10:20 CST

The method signatures that are expected to be implemented are now brought into the SchemaBuffTable.java files produced, but many of them do not have bodies merged from the older code base yet. Specialized versions of the old method bodies have to be crafted for them that are suitable for that specific sub-case of rule expansion.

2026-07-30 21:15 CST

There are still some details to iron out, but there are now issues caused by the decoordination between the ISchemaTable.java.xml interface specification and the buff/SchemaBuffTable.java.xml implementation, which still relies on a variant of the knowledge/rule hierarchy from a few days ago. The one in the interface has been significantly enhanced and specialized, and will now be brought forward to the implementation and it's decl's retagged as impl's, and the bodies from the existing rules brought to bear for the former interface specifications. It'll take a few days, I'll wager, and I'm not in the mood to do so right now. It's past 9:00 PM and has been a long day at the keyboard - over 12 hours.

2026-07-30 18:55 CST

This version gets the build of the cfsec.cfsec.buff layer so close to resolving all of the issues I've been battling (which are no where near all the build errors being reported, other problems will be dealt with later) that I can taste the sweet nectar of victory in the back of my throat. Honeydew and coffee... :)

2026-07-30 16:35 CST

I'm reasonably content with the state of things as I set them aside for a while. I've been at the keyboard for hours.

2026-07-30 16:15 CST

Making slow progress at recovering from my mistake. Think I'm done restoring Wrap rules, now for Inst rules.

2026-07-30 16:00 CST

Some of the missing Wrap rules restored, now to restore their usage vs. Instance accessors for the PKey implementations. I forgot about that; it'll have to be replicated into the record/buffer implementation as well.

2026-07-30 15:45 CST

Work in progress on the interface specifications for table records/buffers/JPA objects. I need to use gitk and online repo comparisons to restore some rule fragments that I shouldn't have deleted.

2026-07-30 07:35 CST

A great deal of progress has been made on getting the declarations and implementations of the relationships for the cfsec.cfsec interfaces and buff implementations coordinated, and there are now far fewer errors being reported during the build process of the resulting code. I'm getting close to finished for the buffer/record implementations and interface cleanups. I think this is a good time for a break.

2026-07-29 23:25 CST

Work in progress; won't even attempt to produce code right now.

2026-07-28 21:45 CST

Most of the issues with the buffer records have been resolved, but there are some missing declarations in the interface specified for them (specifically, the superior primary key relation accessors aren't properly defined in the interfaces.)

2026-07-27 19:05 CST

Finally got the point of another clean run, and there are fewer errors than before, so this 'Direct' set of rules seems to be solving the problem I faced. I've dramatically changed the approach used for column access and modification. By the way, there are now 5249962 lines of code to this work in progress, roughly 200,000 more than on the 9th of this month.

2026-07-27 14:55 CST

Work in progress that actually runs the CFBam code production without getting stuck in an infinite loop.

2026-07-27 03:05 CST

Calling it a night with a plethora of duplicate method specifications and missing interface specifications in cfsec.cfsec, plus a host of errors from the Obj/EditObj layering.

2026-07-26 15:25 CST

So very close to a clean build of cfsec.cfsec right now, with less than a dozen errors from the Table and PKey objects still being reported; most of the missing relationships are now defined except for a smattering of container relationship methods for a few classes.

2026-07-25 08:10 CST

The issue of spurious column setter declarations in tables has been resolved; the table interfaces now only specify column setters if the column isn't in a Superior relationship for the table for all table column specifications.

2026-07-25 00:35 CST

Replaced declRecInheritSuper with declInheritSuper in Table.extendSchemaRecTableRecSuperRec rule in ISchemaTable.java.xml

2026-07-24 18:30 CST

The rule base is coming along nicely, though there are several non-factory-service errors I'm currently dealing with for cfsec.cfsec.

    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffTenant.java:[51,8] server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffTenant is not abstract and does not override abstract method setRequiredClusterId(server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256) in server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecTenant
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffTableInfo.java:[51,8] server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffTableInfo is not abstract and does not override abstract method setOptionalSuperName(java.lang.String) in server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecTableInfo
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSysCluster.java:[51,8] server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSysCluster is not abstract and does not override abstract method setRequiredClusterId(server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256) in server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecSysCluster
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecUserPWReset.java:[1060,17] no suitable method found for setRequiredContainerUser(server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser)
    {ERROR}     method server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSecUserPWReset.setRequiredContainerUser(server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecSecUser) is not applicable
    {ERROR}       (argument mismatch; server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser cannot be converted to server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecSecUser)
    {ERROR}     method server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSecUserPWReset.setRequiredContainerUser(server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256) is not applicable
    {ERROR}       (argument mismatch; server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser cannot be converted to server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256)
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecUserEMConf.java:[1269,17] no suitable method found for setRequiredContainerUser(server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser)
    {ERROR}     method server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSecUserEMConf.setRequiredContainerUser(server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecSecUser) is not applicable
    {ERROR}       (argument mismatch; server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser cannot be converted to server.markhome.mcf.v3_1.cfsec.cfsec.ICFSecSecUser)
    {ERROR}     method server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSecUserEMConf.setRequiredContainerUser(server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256) is not applicable
    {ERROR}       (argument mismatch; server.markhome.mcf.v3_1.cfsec.cfsecprot.ICFSecProtSecUser cannot be converted to server.markhome.mcf.v3_1.cflib.dbutil.CFLibDbKeyHash256)
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecUser.java:[2071,41] cannot find symbol
    {ERROR}   symbol:   class ICFSecPubSecUserByEMAddrIdxKey
    {ERROR}   location: class server.markhome.mcf.v3_1.cfsec.cfsec.buff.CFSecBuffSecUser
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[146,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[160,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[165,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[176,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[181,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[195,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[200,9] method does not override or implement a method from a supertype
    {ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfsec.cfsec/src/main/java/server/markhome/mcf/v3_1/cfsec/cfsec/buff/CFSecBuffSecTentRoleMemb.java:[211,9] method does not override or implement a method from a supertype

2026-07-24 15:40 CST

The primary key relation settings have been tweaked for the buffers, and now I need to propagate those implementation changes to the interface specifications for the object so that the proper signatures are defined for the implementation. It may be necessary to propagate the changes to the interfaces defined for Pub and Prot as well.

2026-07-24 12:55 CST

Revert to code produced by reversion of HEAD for org.msscf.msscf.v2_13.cfkbase to commit 6983d68 (one commit previous)

2026-07-24 05:35 CST

Work in progress; I've got the rules running, but with different build errors. Progress at least.

2026-07-21 15:20 CST

More progress; cleaned up those erroneous PKeyH fragments that should have been HPKey

2026-07-20 22:00 CST

Time to call it a night, not that I made a lot of progress. Still, there are some code changes in place that should help things out.

2026-07-20 01:45 CST

Remove spurious comparisons to non-existent ProtPKey for compareTo operations; there were actually two comparisons to that class that would have been produced, resulting in compile errors in later layers, had cfsec.cfsec not already failed to build.

2026-07-20 01:15 CST

Cleaned up the imports for the buffer history objects.

2026-07-18 02:50 CST

I've made excellent progress tonight, though I'm far from done with my information hiding efforts. It'll come in due time. But enough for tonight.

2026-07-18 01:35 CST

Making good progress; have variants on Prot/Pub relation setters now. Should be a HUGE code change in MCF 3.1...

2026-07-17 18:50 CST

Making good progress on the buff objects right now, slowly fleshing out the comparators for PKeys and HPKeys so far, and introducing a whole slew of new errors as progress gets made and old errors get resolved with the changes. I am content with the day, and think I might call an end to it seeing as it is a Friday night.

2026-07-16 18:50 CST

I am pretty happy with the state of the base PKeys now; I've fleshed out compareTo(Object) and equals(Object) to support the new layers, and removed the explicit specification of Comparable{PKey} from the object, replacing it with Comparable{Object} (and if I didn't remember to do that I'll have to do it soon. Here's hoping that doesn't break same arcane JPA requirement.)

2026-07-15 18:40 CST

Tweaked the Any code for the SpecificallyPrivate and SpecificallyProtected calculations.

2026-07-15 18:05 CST

Clean run of manufacturing 3.1, with no effective changes, but EffCodeVisSchemaPrefix is now EffCodeVisPrefix, and TableCodeVisPrefix, IndexCodeVisPrefix, and RelationCodeVisPrefix have been added, as well as SchemaName variants on the Prefix. Now to get back to work on enhancing the Buff code...

2026-07-15 17:30 CST

Added EffCodeVisSchemaPrefix with affiliated rules to any Java knowledge base. Need to add EffTableCodeVisSchemaPrefix, EffIndexCodeVisSchemaPrefix, and EffRelationCodeVisSchemaPrefix definitions and accessors as well, for use in determining the layer of code that defines an object and it's components. For example, in a Table, you want everything to do with the table using EffTableCodeVisSchemaPrefix, not EffCodeVisSchemaPrefix, so that it uses the _tables_ definition not the local object's definition to determine the schema prefix. The prefixes look like {DefSchemaName}Pub, {DefSchemaName}Prot, and {DefSchemaName} for private. They then get assembled by CodeVisSchemaName as I{EffCodeVisSchemaPrefix}Schema.

2026-07-15 10:20 CST

With the copy-paste-modify of the Protected methods to the Private in AnyObj, MSS Code Factory 2.13 should be feature complete - for now. The outputs didn't change when I ran the modified code, so at least I didn't break anything with my mass changes to the critical isBlah() code in AnyObj over the past couple of days.

2026-07-15 05:25 CST

Reworked the I{SchemaName}{TableName}.java files to specify private, protected, and public access as applicable if the to table has no def schema, and only the public interface if the table has a def schema. In either case, the 'default' implementations in the interfaces for the table objects has been removed; it turned out that when multiple interfaces are inherited, the defaults don't always get applied properly so no matching signature is found.

2026-07014 21:10 CST

isIntermediatelyPublic() and isIntermediatelyProtected() have been added, which are a blend of the isTriviallyXxx() and isXxx() methods that inspects the components of an object, but not as deeply as the final isPublic()/isProtected() do. Note that all of this is just to improve the accuracy and cleanliness of the output code when questionable modelling information is provided that implies greater hiding of information than is specified on the surface.

2026-07-14 19:15 CST

MSS Code Factory 2.13 AnyObj.isPublic() and AnyObj.isProtected() now have isTriviallyPublic() and isTriviallyProtected() counterparts. The Trivially variants only check for trivially verified conditons laterally or up the object tree. The isPublic() and isProtected() variants check if the object is trivially qualified, and then based on object type, deep-inspects the components of the object for isPublic() and isProtected(). This split in the logic ensures that you never get an infinite loop in the resulting code base.

2026-07-14 08:55 CST

Things are starting to come together nicely now; a number of errors have been resolved, but many more remain because the code is incompletely modified. I've cleaned up some last minute errors that cropped up in the code base from my changes as well, which were caused by a bad expansion rule name.

2026-07-14 03:30 CST

Time to call it a night now that I've got clean manufacturing runs, even if I'm getting build errors left right and center.

2026-07-13 23:50 CST

Most of the enhancements to support the public and protected interfaces in the buffer table objects has been coded, but it exposes some issues with the table object interface specifications, which don't have setters for those interfaces, but need to support them. The code in the implementation exists; I'm just missing the signatures in the interfaces for them.

2026-07-13 11:45 CST

Just a work in progress check in because I have other things to do today before I can get back to coding.

2026-07013 01:40 CST

I am content; 2.13 now produces a proper set of Enum type references in cfsec.cfsec - the stray reference to the private schema interface has been cleaned up.

2026-07-12 23:50 CST

MSS Code Factory 2.13 has been updated, but the updates didn't fix the fundamental problems I'm having with navigating to the correct schema interface for an enum type specification. One of the issues is the code and the knowledge base were making different assumptions about visibility of type specifications.

2026-07-12 22:55 CST

A great deal of progress has been made on cfsec.cfsec today, and cfsec.cfsecprot now clean compiles.

2026-07-12 07:45 CST

At this point, the Enum specifications should now be properly isolated to and accessed via the three layers of schema interfaces, depending on the CodeVis of the EnumType specification. There may be an issue in the actual code for the isPublic() et al methods in the custom MssCFBam code for 2.13, but if so, there will be all the enums in pub, even though they are expected elsewhere.

2026-07-11 23:50 CST

The issues with the default method implementations for setting the private interface relationships via pub and prot record/buffer instances instead of private instances has been completed; that set of build errors is gone. Now only the expected complaints about unimplemented methods in the factories remain, though I know complaints from other aspects of the code are likely to follow. Calling it a night.

2026-07-11 19:40 CST

MSS Code Factory 2.13 tweaked the various isPublic/Protected/Private and Specifically variants on Protected and Private; much happier with the code produced now, though I still have issues and bugs in it.

2026-07-11 18:50 CST

MSS Code Factory 2.13 updated with IsSpecificallyProtected and IsSpecificallyPrivate verbs, logic for IsPublic, IsProtected, and IsPrivate reworked.

2026-07-11 15:15 CST

Working on fleshing out the private table interfaces; I need to propagate one of the default method implementations in the private table object interface to a similar default implementation for the protected table object interface.

2026-07-11 13:00 CST

The private interfaces for table records have been updated to allow for protected and public record interfaces being used to set relationships; the protected interfaces now accept public interfaces in the same way. Note that implementations are expected to be entirely independent rather than derived, so code must always detect and process interfaces, not implementations, except with an implementation itself as the 'plumbing' of it's own implementation.

2026-07-11 03:30 CST

The internal/private factory interface for tables has been updated to extend any protected interface defined for the table, which in turn extends any publicc interface defined for the table, each adding new layers of asPublic()/asPrivate() implementations alongside the existing newBlah() methods. The bad checking from a couple days ago was overwritten by the recent alpha snapshots to recover.

2026-07-09 18:15 CST

Broken badly, stack overflows. Frustrated, I take a break...

2026-07-09 14:35 CST

The next phase of updating the existing private object interfaces to be based on modified versions of the schemaprot interfaces has begun. Then comes the hairy issue of modifying the implementations for those interfaces to follow the new specifications (they're close, but not quite.)

2026-07-09 04:00 CST

MSS Code Factory alpha08 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha08.

2026-07-09 03:45 CST

At last a clean compiling output for 3.1, which means it is time to issue a new alpha to replace the one that emits broken code that will not compile. This code still is far from complete for the new code visibility enhancements, but at least it builds.

2026-07-09 00:55 CST

cfintprotobj finally clean compiles, now there are a new 30 issues in cfbamprotobj to be resolved caused by class hierarchies. It will all get figured out in the end; I must continue to have patience and perseverence.

2026-07-08 16:40 CST

So very close now - down to three errors in cfintprotobj:
{ERROR] /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfint.cfintprot/src/main/java/server/markhome/mcf/v3_1/cfint/cfintprotobj/ICFIntProtSchemaObj.java:{44,17] cannot find symbol
{ERROR} symbol: class ICFSecProtSchemaObj
{ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfint.cfintprot/src/main/java/server/markhome/mcf/v3_1/cfint/cfintprotobj/ICFIntProtSchemaObj.java:{46,16} cannot find symbol
{ERROR} symbol: class ICFSecProtSchema
{ERROR} location: interface server.markhome.mcf.v3_1.cfint.cfintprotobj.ICFIntProtSchemaObj
{ERROR} /opt/mcf/v3_1/java/server.markhome.mcf.v3_1.cfint.cfintprot/src/main/java/server/markhome/mcf/v3_1/cfint/cfintprotobj/ICFIntProtSchemaObj.java:{47,46} cannot find symbol
{ERROR} symbol: class ICFSecProtSchema
{ERROR} location: interface server.markhome.mcf.v3_1.cfint.cfintprotobj.ICFIntProtSchemaObj

2026-07-07 23:45 CST

End of day - good progress on the reworking of the I{DefSchemaName}Prot{TableName}[Table] interfaces, but I'm not done yet - I've got hordes of duplicate method declarations right now.

2026-07-06 20:45 CST

Break time

2026-07-05 10:20 CST

Preparing for weekly backups; all files must be checked in.

2026-07-05 04:05 CST

The CFSec family of packages clean compile now, though they are still full of errors and mistakes, but cfintpub immediately chokes afterwards.

2026-07-02 23:45 CST

This is a very good way to end the programming day - I've got clean builds up to cfsecjpatest, which breaks the build. That's just fine by me, because it has been a couple of days since cfsecpub, cfsecprot, and cfsec all clean compiled. They certainly aren't complete or correct yet, but they clean compile, and that's a good start.

2026-07-02 11:00 CST

The code still won't clean compile for another week or two, but at least I got the knowledge base into a clean-generating state where there are no errors or messaging about missing GenRule specifications. A far better state of affairs than was in place for the past 24-36 hours.

2026-07-01 04:35 CST

The {cfsec/cfint/cfbam}prot{obj} packages have been populated with the protected interface definitions, but this code is no where near clean-compiling as introducing the prot layers has induced build errors in the cfsecpub layer package. C'est la vie; I'll get it figured out eventually and be back to a clean build, at which point I'll issue an alpha08.

2026-06-30 10:00 CST

MSS Code Factory 2.13 alpha07 is now available at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha07.

2026-06-30 01:25 CST

Started in on the Prot[ected] layer...

2026-06-29 22:00 CST

Need to do the I[DefPubSchemaName]SchemaObj next. Dozens upon dozens of undefined class complaints from the build...

2026-06-29 20:05 CST

Time to call it a day; I've been banging at the computer quire steadily and made a lot of progress.

2026-06-29 05:25 CST

We had a power outage recently and I have a clean build so this is just a sanity-check commit.

2026-06-28 07:35 CST

The first uses of the schemapub, schemaprot, and original private schema layering has been coded for the authorization objects. This produces a clean build.

2026-06-27 15:20 CST

MSS Code Factory 2.13 Added the IsPublic, IsProtected, and IsPrivate verbs for any definitions, defaulting to public for unknown objects.

2026-06-26 19:50 CST

Finished coding the MSSBamCFAnyObj.isPublic() static method, next I need to add a binding for IsPublic. Cleaned up a bunch of warnings about the old-fashioned way I handle type detection and casting to use cleaner syntax that doesn't show warnings in Netbeans.

2026-06-25 23:40 CST

Added initial draft of isPublic to AnyObj methods. Still needs to ensure that primary key attributes are always public.

2026-06-21 12:00 CST

MSS Code Factory alpha06 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha06.

2026-06-21 09:05 CST

Added ValueDef.CodeVis to CFBam 2.13.

2026-06-21 04:00 CST

Clean compile on the history record changes.

2026-06-21 03:20 CST

Working on the factories and ensuring there are always history records, though they are not always persisted. History records will be needed for replay-tracking in the session editors used by clients (eventually.)

2026-06-20 22:45 CST

The missing subclass evaluation for the ensureRec() methods of the factories now check for the entire set of class codes deriving from the current table class.

2026-06-20 08:30 CST

Refactoring of the DefaultFactory classes into proper FactoryService implementations is complete and ready to test.

2026-06-20 06:30 CST

Working on refactoring the factory objects into Buff and JPA factory services. Introduced BuffSchemaHooks to equivocate JpaSchemaHooks.

2026-06-17 14:00 CST

MSS Code Factory alpha05 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha05.

2026-06-17 13:40 CST

Moved the *buff packaging into the base interface packages. Buff instances are always going to be required, because I've decided to make all of the APIs talk Buff instances. The JPA layer will provide Buff interface methods as it does now, but also alternately-named JPA interface methods that its code can use directly with JPA instances during the processing of a transaction/service method. When returning in the JpaTable classes that do the security checks, those returned JPA instances will get converted to Buff instances for the upper application layer. The server method bodies will assume Buff access methods in its code, as everything except the JPA layer will be using buffers.

2026-06-17 02:00 CST

Added 2.13 iterator DefSchemaRootTables, TABLE_DATA array is now forms a tree of table dependencies, and does not get artificially sorted.

2026-06-16 22:20 CST

Renamed CFSecTableInfo object to CFSecTableData, created a CFSec.TableInfo table definition in the model and will be using that to persist the table data, verify it on subsequent boots, and ensure that 'dynamic' runtime ids are consistent between boots.

2026-06-08 18:00 CST

MSS Code Factory alpha04 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha04.

2026-06-08 12:20 CST

Add TableInfo table object to the security schema for 3.1. This will be used to store the registered table information so that the runtime class codes are mapped consistently between runs.

2026-06-08 05:10 CST

Update postgresql to 42.7.11.

2026-06-08 CST

MSS Code Factory alpha03 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha03 with installation instructions at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/.

2026-06-08 02:15 CST

Fresh snapshots of the 2.13 knowledge base and models for producing the code base were taken with the tag snapshot-202606080215.

2026-06-08 01:25 CST

Make use of CodeVis in the CFSec 3.1 model, and have the knowledge base produce comments about visibility of major objects in their comments.

2026-06-07 11:20 CST

Tweak the CFBam 3.1 specification so the 3.1 code base could be refreshed and rebuilt for the CodeVis attribute changes brought forward to the 3.1 CFBam Table, Index, Method, and Relationship objects with appropriate indexing by container key + CodeVis and by CodeVis alone

2026-06-07 08:40 CST

Added CodeVis attributes to 2.13 CFBam Table, Index, Method, and Relationship specifications, with appropriate indexing of same.

2026-06-07 05:50 CST

Updated website

2026-06-06

MSS Code Factory 2.13 alpha02 released at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/releases/tag/alpha02 with installation instructions at https://github.com/msobkow/org.msscf.msscf.v2_13-installer/.

2026-06-02 19:45 CST

cfbamjpatest now runs clean as well. Next I need to deal with my role code and queries.

2026-06-02 14:30 CST

Finally a clean run of cfsecjpatest, but cfbamjpatest fails.

2026-06-01 12:55 CST

Replace MembershipString of a Role definition in CFBam with Enables and Includes text strings, maxlen 2000000, required. Enables is not allowed to be empty. Update specification of CFSec 3.1 and the sample role specifications in that model correspondingly. Knowledge base for 2.13/3.0 updated accordingly, and the 3.1 code is producing the appropriate new code. Currently the cfsecjpatest runs to the point of trying to obtain a count on Clus security membership and failing. The syntax of the query is valid, but not evaluating properly. The System probes work okay, so I know you can auto-bind a count to a Long the way it does with the query compilation and access, but there must be an issue with the Clus query. I'm going to try to embed the resolution of the Cluster objects into the query itself now that the queries clean-check, so that there is no query-nesting going on - I suspect that is what is confusing JPA.

2026-05-31 09:40 CST

Some cleanup on the JPA code.

2026-05-31 07:35 CST

Add sanity checks for the mandatory superior relationships of an object before creation or update.

2026-05-31 06:15 CST

Finally a clean compile of 3.1 again. A lot of testing and debugging of the actual runtime has been happening, but the data creation only gets as far as CFSecUserPassword right now before it fails gloriously.

2026-05-30 14:20 CST

The issues with cfsecram have been resolved, and with that clean compiling, the rest of 3.1 clean compiled. The code is finally back into a testable, runnable state.

2026-05-30 12:20 CST

The cfsecjpa package finally clean compiles, now on to the cfsecram package errors. Those will be less hassle to fix, because the heavy lifting for the changes has been done in cfsecbuff earlier in the process.

2026-05-28 01:20 CST

Correct the relationships to be properly orthogonal between the containing Tenant/Cluster of the SecTentGrp/SecClusGrp and SecTentRole/SecClusRole entities.

2026-05-26 05:20 CST

The Buff layer now clean compiles without relationships embedded in the PKey objects. Next up is the JPA layer, which instigated this whole change, with the first symptom being the specific case of Atomic Superior Primary Key Container relationships. That turns out to be a serious understatement of the extent of the issue, especially in light of how the Buff layer likes to view data. The Buff layer with pure JPA as a backend would have to allow for Superior Candidate Relationships both in the PKeys and in the Data of an object being resolved by creating another instance of the JPA buffers for the referenced objects along the reference chain, a tremendous waste of memory for the sake of "standards."
Instead, the plan is to hybridize the purity of the old JDBC logic as implemented through the Buff objects of the era (see 2.13 for code that follows that style) with a JPA relationship definition architecture, with the settings of the modelled columns read from the normal DbName column in the database, but with edits to the values done through $DbName$$Suffix$ attributes for the relationship columns, with the code for the relationship setter also setting the value of the logically read-only version of the column to keep the two in sync. So the getter runs as fast as possible, but setting the value requires a valid instance of the target object of the relationship to maximize type-safety and data integrity of the set operations. The penalty is that there will be double the number of columns in the database records for defining the foreign keys of the Superior Candidate relationships so-implemented. (Reminder: Candidate relationships exist entirely within the scope of an individual schema, with further criteria around certain model attributes that are currently populated but not producing a back-end implementation yet. Non-Candidate relationships are those which are restricted from physical database relationship specifications within the schema by those future features, and any relationships to inherited/referenced schemas.)

2026-05-26 00:30 CST

Removed the relationships from IPKey and PKey definitions, and modified the Obj layer to stop referencing those methods. Now on to the buff errors that result...

2026-05-21 02:25 CST

Composite primary keys have SuperiorCandidatePrimaryKey relationships the same as had been encountered with Atomic primary keys, causing the same issue of unset attributes on insertion. The solution is to move those relationships to the main BaseClass object and leave the PKey attributes as minimal as possible to save memory. The relationships will use the relationship Suffix as it does for Atomic PKeys, and leaves the PKey attribute setters for the attributes in the relationship unspecified. The first step is to modify the PKey objects, which will break the code rather badly, and then create the BaseClass relationships, which should reduce the error count substantially and let me focus on fleshing out details.

2026-05-19 03:40 CST

The special case for atomic primary keys with a superior candidate Container relationship have been coded, so the next problem in the runtime has popped up, but I won't even look into potential causes of it tonight.

2026-05-18 02:50 CST

Finally got the syntax worked out for those hairy 8 way security joins for clusters and tenants; HQL sure is picky!

2026-05-16 22:00 CST

Removed the SecClusGrpInc and SecTentGrpInc tables and references from the CFSec model and special case rules. Trying to allow for joins of those tables would have resulted in insanely complex JQL statements; even the 8-way joins that are done for the SysGrpInc table stress most database engines.

2026-05-16 02:55 CST

Debugged the security framework back to the point I'd previously been; my named queries and their invocation worked right from the get-go. Nice to see.

2026-05-15 23:15 CST

The setPKey() methods now invoke the appropriate SuperiorCandidatePrimaryKeyRelation setter if it is a Container relation. I still need to rename the relationship columns in those cases so they don't collide with the @Id or @EmbeddedId attributes.

2026-05-15 15:25 CST

Stubbed in the Clus and Tent probes of the security tables, which will look for the hierarchy definition in the SecSys tables, but membership in the Clus tables.

2026-05-15 11:40 CST

Wired the cascading set-to-value or clear-to-null as applicable for the Container superior primary key relationships. Next I need to modify setPKey(val) in such cases so that the setter for the relationship-by-keyval is invoked instead of directly setting the pkey attribute. Also, the PKey attributes of the relationship in question need to use different names than are defined for the database columns, so that twin columns appear in the database, but with coordinated values. If both share the same column name, it turns out JPA isn't smart enough to coalesce them into a single column definition.

2026-05-15 10:40 CST

Wired the cascading application of an atomic PKey superior candidate relation to the @Id attribute of the entity. Works beauty, but now the setPKey(v) method needs to cascase to setting the relationship by id instead of setting the id attribute directly.

2026-05-14 21:55 CST

Working on some Container/Component value pass-down enhancements for the JPA layer

2026-05-14 02:55 CST

It has been a very long day with a lot of syntax errors for complex union queries fixed, pass-through of Authorization objects stubbed, and new exceptions thrown by the bootstrap code that didn't used to happen before I started fleshing things out, which is actually good to see - it is reminding me to finish certain fragments of code.

2026-05-10 02:45 CST

Added page mcf-lessonslearned.html to the documentation (the one previous to this development log in the updated website navigation.)

2026-05-08 20:15 CST

JPA Test wires an instance of the security schema's JPA Security Cache to the system, which routes the invocations of the back end to the methods stubbed in the security schema service. Rather than worrying about interest registration or cache forgetting at this time, I'll be working on the back end queries for those methods instead.

2026-05-08 01:45 CST

Fleshed out the most important aspects of the abstract SecurityCache; still need to do the registration handling and forget processing, not to mention time based expirations. The probes in the JPA implementation are just NotImplementedYet exception throwers. PostgreSQL bumped to 42.7.11.

2026-05-05 05:55 CST

What an interest time of day to be checking in the SecurityCache base implementation and a JpaSecurityCache specialization. Both are just stubs that throw NotImplementedYet exceptions for everything, but I wanted to get started.

2026-05-04 03:30 CST

Added [SecSchemaName]RoleInfoDependencyComparator, used it to sort the arrays in the consolidated role info accessors of the schema interfaces. Made the natural comparison order of the RoleInfo objects dependency order then role name.

2026-05-03 23:10 CST

Added verb SchemaDef.SchemaOrderedRoles which filters the set to only include those with a null DefSchema reference. Used it to create populations of a ROLE_INFO object in the schema interfaces for 3.1.

2026-05-03 13:10 CST

Added verb SchemaDef.OrderedRoles to custom engine, iterates roles in dependency order (who enables/includes who.)

2026-05-03 05:50 CST

Brought forward the Role definitions from 2.0.13 to 3.1 for CFBam, refreshed the 3.1 projects accordingly.

2026-05-03 05:40 CST

Tweaked the specifications of SchemaRole in CFBam 2.0.13. The custom XmlParser for 2.0.13 has been updated accordingly, but I need a custom verb that sorts the roels in dependency order instead of the random order they're defined by.

2026-05-01 12:35 CST

With regards to the knowledge base enhancements, I've decided that I will not implement complex create, update, and delete methods for the SecRole objects after all. I will implement the validation of the SecRole.MembershipString value. This implies that roles have to be created from the bottom up to form a dependency tree of memberships.
What I will do is create an accumulator object that gets constructed before anything attempts to manipulate the security tables/objects, and passed in to specialized versions of the create, update, and delete methods of the necessary tables. All processing of the security changes is then done through these enhanced methods so that the affected objects are tracked as hashmaps by key or by name as appropriate. Whenever a key or name is found to already be in the hashmap, it is not processed or added again. Note that the effective list of SecRoleEnables entries at the end of processing is often substantially larger than the list of names in the MembershipString after the roles have been expanded. Note that during the update and create processes, the role expansions are evaluated and tracked so that circular (graph) definitions can be reported as ExpectedTreeNotGraph exceptions.
Remember one of my long term goals is to provide a Ram-based session editor in the client application code, so there could be a lot of security data changed in a security session before it gets persisted as a batch.

2026-04-30 22:40 CST

Some changes for 2.0.13 are required before I proceed further. I need to add a RoleDef object to the CFBam model that is a component of SchemaDef, and properly imported with wiring of it's DefSchem links such that the cumulative set of role names in a schema is complete and unique. A parsing enhancement will be made to the custom XML parser for 2.0.13 to define and load the new role definitions as "Role" entries of the SchemaDef. Once I'm done with the enhancement, the model changes will be propagated forward to 3.1's CFBam model.
With the ground work laid, the knowledge base for producing 3.1 will be enhanced so that each set of TableInfo objects is supplemented by a set of RoleInfo objects that get passed to the security initialization process in similar fashion. The roles will be processed after the groups during security initialization, creating SecSysGrp and SecRole entry pairs for all names, and relying on the create and update services for the SecRole objects to populate the maps of affected security groups and users. Very special case knowledge base rules will detect the SecRole table and provide two versions of the create and update methods, one which takes in the two maps of information to be collected, and one which uses normal signatures and invokes the specialized version with newly created maps, propagating the changes to the security control interface when complete.
The JPA version of the security cache will invoke those specialized versions of the create and update service methods for SecRole during processing, such that all the changes made for each role during application of the resulting role creates and updates is propagated to the security control as a single forget operation just before the final database commit. You can't do special-case checking for an unmodified MembershipString, because you need to ensure that the role has been properly propagated throughout the security model during the initialization of the system. This ensures that the security information is self-repaired on system startup, save for any user membership information that might get lost by an overzealous security administrator deleting data they shouldn't.

2026-04-30 21:45 CST

The 3.1 CFSec model now has the new table objects SecRole, SecRoleEnables, SecRoleMemb, SecClusRole, SecClusRoleMemb, SecTentRole, and SecTentRoleMemb. I'll be adding a new parse object to the CFBamCust SAX XML parser that lets you define arbitrary SecRole instances at the Schema level.
I need to add a MembershipString to the SecRole that receives a space-separated list of SecSysGrp names, and do a heck of a lot of custom processing hooks and enhancements to my JPA code:
Whenever a role is updated, any security group that references some variant on the role's group name will have it's GrpInc that references the role name removed, and the SecRoleEnables entries for the SecRole are cleared. Note that because roles can't cascade to other roles, there are never any SecRoleEnables entries that map to role names.
If the role is being created or updated, a new set of SecRoleEnables entries are built for the SecRole by evaluating the list of permission names in MembershipString, and searching SecSysGrp for those names and information about the names to build a list of SecSysGrp entries for processing (hashmap-by-name). If any of the referenced SecSysGrp entries is for a role, the list is rejected and no SecRoleEnables entries will be created, an exception being thrown instead.
If all the SecSysGrp entries resolved to instances that are either Sys, Clus, or Tent security groups, the list is considered acceptable and the create or update is allowed to proceed. The create or update is processed, and then the list of SecSysGrp entries is processed to create the SecRoleEnables entries for the role.
Now for each SecRoleEnables entry that has been created, the corresponding SecSysGrp entry is retrieved from our earlier hashmap-by-name of entries, and GrpInc members are created for the Sys, Clus, and Tent groups of the system accordingly. Note that rebuilding the tenant groups could take quite a long time if there is a large community of tenants on the cluster.
Once all the GrpInc members have been created for the role, we begin building the list of information to be cleared from the security implementation. I'll use a hashmap of strings to ensure uniqueness, and start with the list of security group names from the SecRoleEnables members that were created.
If any SecSysGrpInc entry references one of those names, the name of the related SecSysGrp is added to the list of security group names, and a cascading check for SecSysGrpInc entries that reference the newly added name is done.
I also want to add a SecUserRole table that is maintained by the security administrator to specify a list of roles that is to be enabled for the user. If any user so references a role, that user is to be forgotten by the security implementation as well.
Now that we've got the complete list of unique security group names affected directly or indirectly by the role's changes, and a list of the users affected, we can proceed to tell the ICFSecSchema.getSecurityControl() to forget that information. We leave the other lists empty, providing populated lists only for the UserIds, UserLogins, and security group names. Now we can finally let the create or update finish processing after our custom code.
Obviously I'll be littering the create and update JPA service code with schematweak and tabletweak hooks and some specifications for them in the CFSec model for the appropriate tables (there are other security tables whose create and update operations need to cascade in this fashion. Then I need to modify my delete code for the SecSysGrp to explicitly lock all the instances that are going to be deleted before processing the delete itself, and taking that list of instances and processing it to prepare a list of forget notifications to the SecurityControl, process the delete, and then have a post-delete customization hook that takes that list of forget notifications we built and issues them to the SecurityControl.)
For now I'm completely ignoring the Buff implementations. Some of what I'm doing will be refactored to base class implementations that get extended and customized by the Jpa and Buff layers, such as a generic cache, which will have Buff and Jpa variants that do specialized processing for doing the security information probes required on a cache miss. The base class will just define NotImplementedYet bodies for those methods.

2026-04-30 18:45 CST

Work on the security services and infrastructure continues. The wiring for the security cache is in place and in use, now to write not only the cache but the services behind it.

2026-04-29 07:40 CST

The base security schema interface now extends the security control interface, which means all schemas will now be security control interfaces. Only the security schema will actually flesh out the implementation, all other schemas just pass the buck to the security schema. The v3_1 build is broken, as nothing implements the new interface methods yet.

2026-04-28 21:45 CST

Refactored the invocation of the security methods so the Tenant security interfaces receive both a cluster id and the tenant id, and followed the service interface comments about not invoking superuser security checks after making a SecScope-defined check. Lots of code has been pruned as a result in the 3.1 output fractal code.

2026-04-23 08:20 CST

The security and table info bootstrapping has been reworked to provide a 'system' user that cannot be logged into, and a separate 'systemadmin' account that can be. The system user is hard coded by the rules to allow access to all tables and all groups, but the 'systemadmin' account relies on the 'systemadmin' system group being incorporated into the permission definitions of the table info structuring, so although the application code running as system can always access data, it is possible to prevent system administrators from doing so.

2026-04-22 07:45 CST

Working on a SecurityInterface provided by CFSec to the applications, which will replace my current approach with one that lends itself to caching and remote server caching as well.

2026-04-20 20:25 CST

Fleshed out the remaining security code for the JPA table objects. Next I need to implement crude back-end JPA security, and then enhance it with a security cache.

2026-04-20 19:00 CST

Wired in the complete support for indextweak specializations so you can customize security checks on (for example) table read by index. Initial JPA security sketching rules have been laid out, but most of the methods don't use the new expansions yet to enforce security.

2026-04-19 12:20 CST

Brought the IndexTweak forward from the 2.0.13 model to the 3.1 model and updated the fractal code.

2026-04-19 01:20 CST

Add the IndexTweak and IndexAddendum types and references to the mssbam-2.13.xsd specification as appropriate, validate the XSD. IndexAddendum uses a special 385 character reference to TableName.IndexName within the schema.

2026-04-18 23:40 CST

Added IndexTweak to the CFBam 2.13 model, remanufactured.

2026-04-18 17:15 CST

Cline/Gemma4 suggested switching StringBuffer to StringBuilder in CFLibDbUtil because the object is only manipulated by the stack context and does not need synchronization overhead; a performance tweak.

2026-04-17 15:10 CST

The creation of the v3_1 CFSec tables is now sane, and the security tables get primed, with hundreds of entries in the case of cfbamjpatest runs.

2026-04-16 22:40 CST

Tweaked the security scope of part of the CFSec model, rebuilt v3_1.

2026-04-13 00:50 CST

Added the verb DefSchemaTables to 2.0.13 which iterates the tables defined by that particular schema. The 3.1 I[CFSec/CFInt/CFBam]Schemas have had getTableInfo() and getCompositeTableInfo() added to them, with the latter used for the top-most schema to pass down a consolidated list of table information to the CFSec implementation of schema initialization.

2026-04-12 17:50 CST

The security and table bootstraps finally clean compile, but I'm not satisfied yet - I want the entire set of table security information to commit as a single transaction on startup.

2026-04-11 22:00 CST

In CFBam model, SchemaDefObj objects now can have a SchemaTweak set of named objects underneath, and a TableObj can have TableTweak named objects underneath. The custom SAX parser for the models has been updated accordingly. Note that the tweaks are not pulled into a SchemaDef when importing a SchemaRef. This allows each SchemaDef to redefine the SchemaTweak and TableTweak instances by having "name collisions" with the referenced schemas. Then when processing the schematweak and tabletweak macros, the definition hierarchy is probed accordingly. In the knowledge base, "schematweak <TweakName>" macro invocations while on a SchemaDef object will find the appropriate set of tweaks in the SchemaRefs for the SchemaDef, trying to build the specializations from the lowest-level model on up. "tabletweak <TweakName>" macro invocations while on a Table object will find the appropriate set of tweaks in the DefSchema hierarchy for the table, eventually stopping at the table with a null DefSchema. As the tweaks are found, they are added to the beginning of the processing list of tweaks. When processing an appropriately created ArrayList of tweaks, the encounter of a tweak which specifies ReplacesInherited="true" will cause the GEL compile buffer to reset to empty. Otherwise, each tweak's GEL text is just appended to the GEL compile buffer as the tweaks are iterated through. Eventually, if the GEL compile buffer is not empty, the GEL is compiled in a try-catch block reporting any compile errors accordingly and expanded to produce the return result. If the GEL compile buffer is empty, an empty string is the return result.

2026-04-11 16:30 CST

msscode 2.0.13 exercises the SchemaTweak and TableTweak entries added to the 3.1 CFSec model, navigating the object hierarchy successfully to produce the output. MCF 3.1 clean compiles.

2026-04-11 11:15 CST

The builtin expansion verbs schematweak and tabletweak have been excercised for the null/no-such-definition case by modifying the knowledge base to invoke such expansions.

2026-04-11 11:10 CST

The builtin expansion verbs schematweak and tabletweak have been added to the 2.0.13 GEL compiler, and expect the balance of the macro to be the tweak name to be expanded. Searching of DefSchema and SchemaRef inheritence is done through code, and the tweak objects should not be copied when importing a schema reference.

2026-04-11 01:50 CST

The MCF v3_1 CFBam.Tweak objects have the same changes as v2_13 propagated forward to them. There is now a unique index key including the Def columns.

2026-04-11 01:45 CST

The v2_13 CFBam.Tweak objects now have an index key that includes the Def columns for use in merging the definitions on load in the runtime code that is soon to be written.

2026-04-11 01:40 CST

The v2_12 models were updated to tweak the v2_13 CFBam.Tweak object to have an index key that includes the Def columns for use in merging the definitions on load.

2026-04-07 09:40 CST

Almost forgot to ensure there are Cluster-level security entries for the Tenant-level security entries so that you can have a cluster-only superuser for the cluster's tenants instead of having to use the system level administration account for maintenance.

2026-04-05 02:30 CST

The initial coding of the security bootstrap groups, members, and subgroup inclusions is complete, now that a public group has been added.

2026-04-05 01:20 CST

The JPA security priming code has been written, but not tested. I think I should test it before I clone a big chunk of it to the buff layer.

2026-04-04-22:20 CST

The security framework priming is proceeding apace; I believe the code for the Sys level objects is now complete, and ready for the Tenant and Cluster scoped variants

2026-04-04 12:30 CST

With great pleasure I report that not only does the entire set of v3_1 fractal code now clean compile again, but the bug in the cfsecramtest that I knew about has been fixed - there is now only one user record for the admin user in the data set during the test instead of the erroneous two that I used to see.

2026-04-04 02:45 CST

Clean compile of v3_1 up to cfsecram, which needs updating to deal with the new models and relationships

2026-04-02 10:10 CST

Wrapped the resolution of named sub-objects in try-catch of Throwables as the fact you cannot convert a random string to a specific type of data is not an error in this case, but a common occurrence meaning that that particular lookup cannot be resolved using the string provided

2026-04-01 20:40 CST

You can now use any kind of column you like as the final column of a LookupIndex for a Table, and the strings will be auto-converted to the appropriate intrinsic type for probing the lookup index. I think I might need to wrap and ignore conversion exceptions, though, because a bad conversion just means the string can't possibly resolve to that particular table reference

2026-03-30 07:15 CST

Have been working on adding some new objects to the SecUser group of objects, but doing so exposed issues with the knowledge base' implementation and handling of some edge cases. Many of those edge cases have been corrected, but it isn't a clean-compiling check-in yet.

2026-03-27 01:10 CST

Version 3.1 of Mark's Code Fractal has added CFBam.Tweak and subclasses CFBam.TableTweak and CFBam.SchemaTweak, brought forward from the 2.0.13 models. I don't expect to be bringing forward and modernizing the related custom code for some time yet. Quite some time.

2026-03-26 23:50 CST

Version 2.0.13 of MSS Code Factory has added CFBam.Tweak and subclasses CFBam.TableTweak and CFBam.SchemaTweak as components of the obvious objects. These collect the customization tag information from parsing the model. Next up is modifying the 2.0.13 CFBam custom parser to accept the new data, and wiring the MssCF custom parser and actions to process the new data. The verbs 'tweak', 'tweakschema', and 'tweaktable' will be added to the custom Gel compilation, similar to the way the hardcoded customizations are handled now, but dynamically. Then a two-phase approach is used, where the rules are loaded priming the tweak name sets so they can be validated during the model parsing phase. Then and only then can I begin using this new feature that was originally slated for 3.1. I just decided it would be easier to implement for 2.0.13 than it would be to create all the custom expansion verbs and columns for 2.0.13 that I'd need for this new ruleset. I never did like the way I was handling customization... too tightly bound to the knowledge base being processed. Once I've verified the code is falling together reasonably well, I'll migrate the new objects and their relationships to 3.1 to carry the feature change forward.

2026-03-26 17:10 CST

Ready to redo the security initialization code, but this time fully fleshed with the new model in place

2026-03-26 03:30 CST

The CFSec model changes are tentatively complete. The code used to prime the database now has to be refactored and reworked to support the new model, after which I can start working on the code that enforces the security constraints.

2026-03-26 00:20 CST

Cleaned up the RAM errors because I didn't want to go to bed on compile errors. So even though the CFSec changes aren't complete yet, the code all clean compiles at least.

2026-03-25 20:55 CST

Finally got most of the CFSec packages building with the partial remodelling of the security tables in place; there were issues with relationships not being fully orthogonal in the model, preventing them from being processed as Superior relationship code. Now there are issues with the RAM storage layer, but I'll deal with that some other day.

2026-03-25 10:05 CST

Snapshot of CFSec (a work in progress) with tweaks to the CFBam.SecScopeEnum to support None, System, Global, Cluster, Tenant, SystemGroup, ClusterGroup, and TenantGroup. There is no GlobalGroup, as it is a SystemGroup with no read access enforcement restriction.

2026-03-25 04:45 CST

I've realized the real problem I'm having with the code produced is that the Superior relationship classification has to accept any unique index as the ToIndex of the relationship, not just primary indexes. This requires a series of 2.13 engine code changes, and possible knowledge base changes for the buff and jpa modules.

2026-03-20 02:00 CST

Added security model documentation for 3.1, sketchy and basic though it may be

2026-03-15 18:40 CST

Make Mark Stephen Sobkow's exception a specific clause in the gpl-3.0* and lgpl-3.0* license files for the various packages and projects. Clean up licensing, integrate resource resolution for 2.12, 2.13, and 3.1 via mcf.markhome.server URLs, and generally clean up the 2.13 and 3.1 code base.

2026-03-15 13:30 CST

The licensing has been coordinated and synchronized between the 2.13 and 3.1 releases, both of which use Apache V2 licensing for the cfsec and cfint jars and packages, GPLv3 with classpath, static linking, and my own special exceptions for cfbam and cfcore. The various cflib packages use LGPLv3 with classpath, static linking, and my own special exceptions. I specifically allow you to leverage newer features of Java like the ability to distill a bundle of jars down to a single executable jar.

2026-03-09 15:25 CST

Finished migrating to the nexus3.mcf.markhome.server-hosted repository for publication of code builds, brought the commons-codec references in 2.13 up to date.

2026-03-08 23:05 CST

Cleaned up more of the details of the migration back to mcf.markhome.server/server.markhome.mcf from msobkow.github.io/io.github.msobkow. At this point I think I've got all the kinks and details worked out for the 3.1.42 builds I've been working on, using github.io for the documentation publication, .xsd file distribution, and remote git repository provisioning for offsite backup of my work (hey, when you spend 25-30+ years banging away obsessively on the same idea, reworking pieces and redoing things until you're actually proud of them and the cleanliness of the code, you don't want to be without at least one viable backup at all times! I even carry a USB stick of the latest backups when I leave the building for an extended time, just in case there's a fire or something and I lose my machine completely.) The local services provide a nexus3 project-hosted repository and a project-public group that includes the project-hosted and maven-central repos, with all the pom.xml's set up to publish to the project-hosted repository. Obviously you're expected to configure your .m2/settings.xml to specify that the project-public group repo should be used for resolving maven artifacts. Add additional repos (hosted or groups) to the project-public repository as needed. The documentation now looks identical regardless of whether it is resolved as https://msobkow.github.io/, http://mcf.markhome.server/, or via direct opening via right-mouse-click on the index.html in the document root and opening it with a browser. Roughly 4GB of source code was redirected today, so I think that's quite enough for a day's work.

2026-03-08

Shifting back to server.markhome.mcf from io.github.msobkow for the project due to issues with publishing the maven builds - it tries to publish them to io.github.

2026-03-03 21:55

Set up a Sonatype nexus3 service and enhanced the rule base to leverage the new "SchemaHostName" verb to set the target server to nexus3.$lower SchemaHostName$ with a distribution repository target of $lower SchemaHostName$-hosted for the publication of the packages. Then you set up a $lower SchemaHostName$-public group that includes the -hosted first, and then the MavenCentral cache as a fallback for non-local package resolution. That way the local repository can resolve the io.github.msobkow packages before any msobkow.github.io addresses can be probed; a simple host name alias for my system in /etc/hosts takes care of intercepting nexus3.msobkow.github.io in my case. I've also resurrected the use of build number arguments, so you'll want to coordinate the manual custom pom.xml specifications with the build number specified for producing the fractal code.

2026-02-28 14:15

Refactored schema table security, added restore[tablename] and mutate[tablename] for tables with history and mutable tables, respectively.

2026-02-28 09:05

Fleshed out the table bootstrap security for the top-level Cluster based security that decides if you ever have permission to do something. For tables that have Tenant security, I next need to populate the default security sysadmin permissions for the system tenant. Log is at 2026-02-28-09h05-BamTestsWithSecurityBootstrappingRunlog.txt

2026-02-27 05:00

Added bin-v3_1/InstallRepos31.bash and bin-v2_13/InstallRepos213.bash to create the default install locations if install locations haven't been set and configured, and to install all of the repositories for the release as appropriate

2026-02-27 01:00

Update of CFSec with initial bootstrap of CFInt and CFBam databases, runlog is here: 2026-02-27-01h00-UpdateCFSecInitCFIntCFBamRunlog.txt

2026-02-27 00:30

Finally had an initial bootstrap run of the bootstrap Cluster, "system" Tenant in the Cluster, admin SecUser, the SysCluster entry that makes the bootstrap data the system singleton, and the SecSession record that tracks the management of the whole operation with begin and end LocalDateTime values on insert and update-to-close the session. The initial runlog of the core CFSec bootstrap process is here: 2026-02-27-00h25-InitialBootstrapRunlog.txt

2026-02-26

Resolved the issue with dependency injections to my satisfaction, and in the process of debugging the security bootstrap code and JPA source. 3,977,931 lines of code in the 3.1 code base between hand-written and fractal code, with the vast majority being fractal.

2026-02-21 AM

Get rid of AspectJ and spring-aspects next; dynamic resolution via ApplicationContext is relatively trivial, and much easier to work with.

2026-02-21 Early AM

Keep AspectJ because it should work after all, but I don't actually need to use AspectJ directly, and shouldn't be referencing it directly in my POMs, apparently. Instead, I need to rely on Spring Boot annotations that exist by default but which get runtime AspectJ style initialization on construction via new() operations after the instance is fully created, but before any actual runtime code is used to invoke the object following the new() operation that created it. So by creating a POJO in a separate schemajpahooks package whose classes are intended to be POJOs merely annotated by @Configurable instead of being full @Components. We don't want Spring to create instances and wire a web of them, we want POJO code to specify configuration layers before JPA is initialized and have their @Autowired references resolved on dynamic construction, not on boot layout processing. Currently there is one massive hooks object for the Schema that references all the Spring objects that are expected to exists for a JPA framework implementation. This ensures that the entire set of objects is guaranteed to have their singletons instantiated when the schema first constructs the originally-null [Schema]JpaHooksSchema member during the first getSchemaHooks() invocation after it's instantiation. I think what I have to do next is shift the pom.xml references to the spring-aspects dependency to the final main that initializes everything, because the maven processing consolidates all the class loaders into a single .jar and loader as far as I'm aware; I could be wrong. If I am wrong about that, just specifying spring-aspects was supposed to get the autowiring working, but it doesn't. Obviously I'm missing something...

2026-02-20 AM

AspectJ isn't going to do what I want! I need to do a post-construction initialization of the @Autowired references in my JPA Schema wiring/hook POJOs because those objects get constructed _before_ Spring initialization takes place. The initialization of those @Autowired references has to happen _after_ Spring is initialized and has resolved all the "normal" Spring objects in the JPA layer. By default, AspectJ does it's initialization by wiring itself as a "wedge" constructor with the ajc compiler such that the wedge constructor gets invoked instead of the default constructor, invokes the default constructor internally, and then does the autowiring. That's not what I need at all. I need to figure out how to do _dynamic_ bean resolution by name and interface type. I know it can be done 'cause it's been done on prior projects; I just need to relearn how Spring does it (besides, if I don't even remember what I'm looking for, it's probably an API that's changed by now, so I'm better off relearning 4.0 information.) Obviously I then need to remove @Autowired from the POJOs and the spring-aspects annotations, refactor those formerly @Autowired members as AtomicReference<Interface/Class>, and wrap their use in getter methods that use dynamic spring resolution mechanisms to locate the bean by name and by type and wire it to the member using ar.get() and ar.set(expected,value) in the getter method to ensure only one setting of the resolution gets kept by this attribute. Easy-peasy. Probably have it done today, now that a plan is in place.

2026-02-19

CANCELLED It turns out that JPA requires binding the POJOs that use @Autowire directives using AspectJ under the hood. The key is to add the spring-aspects package to your pom to anything making such references. This allows AspectJ to handle the autowiring for beans that have been annotated with @Configurable (you should specify whether to configure by name or by class; in my case virtually all my bindings are by name, but I haven't added that specification yet - I just read about it a few minutes ago. Once you've done that, you specify a bean in your main executable projects that rely on such annotate POJOs to initialize and wire the AspectJ components. Finally, at runtime, your java command has to specify that spring-aspects.jar is to be loaded as well as the *-spring-boot.jar that was produced as the unified application jar; the easiest way to ensure that is done is to wrap all your *-spring-boot.jars with bash scripts that pass along the command line arguments to the java command, but ensure that the command line arguments for launching the application are consistent. Even applications which don't rely on JPA should do so; this is a low-priority todo and has been for some time, but this recent change has made it important to take care of as the final step of the AspectJ wiring.

2026-02-13:14

ON HOLD - Requires new approach based on 2026-02-20 AM notes - Bootstrap code for priming the CFSec database with the "system" cluster, "system" tenant, "sysadmin" user with initial password "ChangeOnInstall", the SysCluster record, and the SecSession for the bootstrapped security data has been added to the Buff and JPA implementations, with a "bootstrapSchema()" method added to the schema interfaces. Atomic references for the SysClusterId, SysTenantId, and SysAdminId have been added and are initialized by the security portion of the bootstrapSchema() implementations for CFSecBuffSchema and CFSecJpaSchema. This is very much a work in progress - now that I've got the atomic references and their accessors, I can code initial security constraints for the table accessor methods that give the admin user global access, and pass in a security object during the bootstrap process that is based on those values. I want to get the initial security framework wired back in at this point in time as well, so that I've dealt with the special cases needed for the bootstrap processing. The SysCluster record and the actual system Cluster have to be readable by anybody, but trying to read any other Cluster should be secured. The existence of valid user ids has to be verifiable, but the SecUser table itself shouldn't be globally readable. SecSession should be tightly restricted, such that only the SysAdmin user can access it other than in-security-process code. The exceptions that were being thrown by CFSecRamTest have been cleaned up, but there are still two CFSecSecUser entries where there should only be one.

2026-02-10

It turned out that no syntax errors cropped when rebuilding with JDK17, even though I thought the use of final statics in interfaces was a JDK25 feature. The downgrade from JDK25 syntax to JDK17 syntax is with the intent of using GWT for Spring for the user interfaces, so I may not be able to continue with the static finals when I'm relying on the GWT Java processor that translates pure JDK17 code to JavaScript in the client. I have some ideas on how to go about mapping my JavaFX code to GWT code... and getting dynamic layout flow along the way! It's just fortunate GWT at least supports JDK17; when I was first exposed to it's commercial relative, only JDK8 code was supported.

Older

A simple test program similar to cfxxxjpatest called cfxxxramtest makes sure the code all wires together successfully and that the empty tables can be find-all'ed.

Older still

The base for the DbKeyHash implementations now uses a 64-bit ClusterCode instead of a 32-bit Machine Id. This change is more than name, but in fundamental meaning, because in the Code Fractal world, a ClusterCode is a randomly generated value stored in the singleton SysCluster table. This value is randomly generated on system install, and in the future will be submitted to a central server for registration. But the only way I could automate such processing right now is through the use of my personal email account with one of my ISPs, and I don't think they'd appreciate the potential traffic flood (i.e. Part of setup is sending the registration information encrypted by some known public key so that my email account can decrypt it, verify the ClusterCode is unique and accept the registration, or detect the ClusterCode collision and find a free random one to use instead, and conditionally accept the registration with the proviso that the node change it's ClusterCode to the assigned id. That way 99% of the time the _client_ produces the ClusterCode values, and the server only has to _register_ them. The internal keys used for the "system" Cluster and "system" tenant are irrelevant, and will be unique to each cluster, as will the id of the "admin" account for the cluster. No easy "defaults" other than the initial "admin" password being a known string that gets changed on initial login.