We are definitely making progress.
Release 1.2.0 brings some basic validation of entity classes and embeddable classes. Embeddables are used as embedded IDs in those cases where we have to model a many-to-many association with extra attributes on the join table, and where the join table has no explicit ID from a sequence. In such cases we lump all foreign keys together into a class annotated with @Embeddable, and the entity class for the join table gets an instance of such an embeddable class as @EmbeddedId. See section "18.104.22.168 A complicated association" of the Azzyzt tutorial for details.
Embedded IDs are a special case of IDs, thus they have to be passed from client to service in cases like a lookup by ID. They get serialized by JAX-B like any other DTO, and today we had an interesting case:
A developer had defined a mis-matching pair of getter/setter on a property of an embedded ID. The getter was getidPerson() and the setter was setIdPerson(). The problem is, that if we don't explicitly specify serialization rules with annotations, JAX-B just serializes all properties of an object, and it decides that something is a property, if there is a pair of matching getter/setter. Of course the difference between a lower case i and an upper case I is not that big and is easy to miss. The effect was, that only one of the two foreign IDs comprising the embedded ID got serialized.
Although I am quite confident by now, that the basic code in Azzyzt is working and stable, I am still in a phase where I tend to search for the error on my side. When I finally found the problem, I decided to solve it once and for all times. From now on all entity classes and all embeddables get verified. If any of the expected getters/setters for non-internal fields is missing, code generation fails with a precise log message telling you where the problem is.
Other than that, Azzyzt 1.2.0 introduces some configurability. There is a new class Azzyztant. It gets generated into the user source folder of the EJB directory at project creation time, and if it does not exist at code generation time, it gets generated as well. You can modify this class in two ways:
Set properties that get evaluated at runtime, or annotate the class to influence code generation. There is a new chapter "6 Customization of the generated code" in the Azzyzt tutorial that explains the details.
Currently Azzyzt offers one runtime hook (changing of portal-supplied user names) and two code generation options. They allow you to omit "@Remote" on service interfaces (thus I suppose we now support the JEE 6 web profile and therefore JBoss AS 6.0) and/or to omit "@WebService" on service beans. If you use both options, the application is exclusively available via REST.