Azzyzt JEE Tools 1.2.4 are available

Some more customization: 

• Now you can not only cut back on features that would normally be generated, you can also add features that would normally not be generated. Currently the only option to add is an Apache CXF REST client project. Interfaces for the CXF proxy-based API are generated. The tutorial now contains an example for in-server unit tests implemented via CXF REST. 
• Customization of the REST error response via HTTP request headers.

See section 6 Customization of the generated code for all the details.

Azzyzt JEE Tools 1.2.3 are available

Everybody makes an Indigo release these days, why shouldn't I :-?

The only visible changes are in the vanity department: The installed feature is now displayed in the list of installed features (this was a harmless bug) and in Eclipse's "Help / About" dialog there's now an Azzyzt icon.

Azzyzt JEE Tools are now built on Indigo and against a GlassFish 3.1 runtime. Up to now I have used Helios SR1 and GlassFish 3.01 for building.

I have tested the cookbook tutorial in the following configurations:

• Glassfish Tools Bundle for Eclipse (Galileo SR1 + GlassFish 3.0)
• Helios SR1 + GlassFish 3.01
• Helios SR2 + GlassFish 3.1
• Indigo + GlassFish 3.1

I guess I should try to automate these tests :)

Azzyzt JEE Tools 1.2.2 are available

Well, actually they've been available since Friday afternoon, but you just don't announce new software on Fridays. So, what's new?

• Support for JSON added. Query spec parameter for list operations is intentionally still XML though. The operations in the generated ModifyMulti bean could theoretically be accessed via JSON, but in practice this fails due to lacking deserialization support for polymorphic lists. In XML this is solved via @XmlSeeAlso annotations on parent classes, Jackson, the JSON base technology in GlassFish, has evolved something analogous in 1.5 and as GlassFish 3.1 ships with 1.5.5, it would be possible to support it. The necessary annotations are in the package org.codehaus.jackson.annotate, and I expect them to surface somewhere under javax.ws.rs in JEE 7. If you really need it now, you can always change the code or the generator :)
• Two new cutbacks can be defined in Azzyztant: NoRestServicesXml and NoRestServicesJson. If both are used, no REST code is generated at all, not even the servlet.
• A good one and a bad one: we now clean all generated folders before generating code. This has become a necessity with cutbacks. The drawback is, that we now have Apache Commons IO as an additional bundled library.

Documentation updated

Originally I had got the semantics of the "Visit" class in the tutorial stupidly wrong. The language used by the guide is no extra attribute, it clearly has to be a part of the embedded ID.

How do I know? Well, in the original you couldn't insert two visits from the same ZIP area to the same city, but with different languages used by the guide. You always got an update of the same record, because the ID, combining only city and ZIP, was the same.

Now we have an association between three entities, City, Zip and Language, all three contributing their respective IDs to the embedded ID, and the "numberOfVisitors" has become a "totalNumberOfVisitors". Whenever new data about a visit comes in, we look if an instance of Visit already exists. If so, we increment its total number of visitors, otherwise we create a new object. Maybe I should even call the class not Visit but VisitStats or something like that.

I have not made a new release, but I have already updated the documentation, the tutorial as well as doc.zip, the archive that also contains sample sources. You would have got it with the next release, but I figure it is bad style keeping nonsense on the web as soon as you recognize it's nonsense :)

Azzyzt JEE Tools 1.2.1 are available

This is really a bugfix release. Release 1.2.0 had a problem with azzyzted projects created by earlier versions. It tried to upgrade gracefully and failed miserably :)

1.2.1 has been tested with the cookbook application as generated by 1.1.1 and 1.2.0. In both cases the upgrade works.

Two user-visible changes are, that Azzyzt now generates a new project called "azzyzt_tools" and that there is a new file "EarContent/META-INF/azzyzt.xml" in the EAR project. You can ignore them by now, later on they may become useful. "azzyzt_tools" is not packaged into the EAR artifact, it is only used by the Azzyzt JEE Tools plugins during code generation.

Upgrading to 1.2.0

Upgrading Azzyzt JEE Tools themselves is just a matter of upgrading an Eclipse feature from the update site, but if you already have created an azzyzted project with an earlier version, you will encounter a problem after the upgrade.

Azzyzt installs two runtime components into the lib directory of the EAR project, but it runs the code generator from the plugin itself. Unfortunately the code generated by the plugin depends on a particular version of the runtime components, and after the upgrade, code generator and runtime don't match.

If you generate code with 1.2.0 from an azzyzted project created with an earlier version, you will get "Azzyztant" created in the wrong package, and the code will not compile because of two missing interfaces.

This will be fixed in release 1.2.1 due in a few days, but until then, here are two possible temporary solutions:

1. If the only code supplied by you are the entities and your persistence.xml, you can just save them, delete the four projects, create the azzyzted project anew, copy the saved entities and persistence.xml into the new projects, refresh the projects, clean all projects, and then you can safely generate code.
2. The other solution is to create a second azzyzted project (call it "dummy" or whatever you like), and then copy the contents of "dummyEAR/lib" over to the lib directory in your EAR project. Refresh your own EAR project, delete the dummy projects, create a sub-package "meta" parallel to "entity" in your EJB project's "ejbModule" source folder, and then you're done.

Sorry for the inconvenience, next time there will be an automatic solution.

Azzyzt JEE Tools 1.2.0 are available

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 "3.2.2.1 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.