Fixed a bug where under certain conditions string IDs would break
storeMulti(). The cause was, that the check for the possibility of proxy
ID translation of an ID field was done on the field’s owning
entity instead of the field’s target entity. It broke as soon as
an entity with numeric ID had an association to an entity with a string
ID. String IDs inside of embedded IDs (like VisitId) were no problem,
because embedded IDs are specisl-cased anyway. This closes issue #29.
Changes in 1.3.1
Built and tested with Eclipse Indigo SR2, GlassFish 3.1.2 and Java
Changes in 1.3.0
New URLs for SOAP and REST. The new URL schema bundles full services and
restricted services. Thus it is possible to allow/disallow one of those
categories based on the URL prefix. This breaks current applications and
therefore we have bumped the minor version.
The default HTTP header expected to contain a pre-authenticated username
is now “x-authenticate-userid”.
The default HTTP header expected to contain a user’s credentials
is now “x-authorize-roles”. See the tutorial
for details on credentials.
These two HTTP header names and the default anonymous user name can
still be changed via JNDI custon string resources, but this is more
elaborate now. The old JNDI resource for the username HTTP header was
as this is global and would define the header name for all applications,
we have recognized that a per-app definition may be useful. From 1.3.0
on the first resource checked is
where “<APPNAME>” is the project base
name, in the example application it’s
“cookbook”. If this name is not defined, the
tried, and if that isn’t defined either, the default value is used.
Added lots of JavaDoc to runtime. Still not complete though.
Added an AuthorizationInterface. You can add a reference to
an instance of a class implementing this interface to the
Azzyztant. It’s completely analogous to the username
converter and it can be used to check authorization per call, based on
the taget class/method and credentials.
Eliminated the MAGWIEN feature. Through all the time it has been
identical to the GENERIC feature anyway. So far we don’t need any
special or secret code and the configuration options suffice.
Added a subset of BETWEEN to QuerySpec. You
can specify BETWEEN clauses where the result is limited to
be between two literals. This covers the most common uses. The general
solution, where each limit can be either a literal or a field reference,
would have needed a major refactoring or polluted the code to no end.
Tested with GlassFish 3.1.1
Tested with Indigo SR1
Added credential-based authorization
Added unit tests for credential-based authorization
Changes in 1.2.4
In Azzyztant you can now define options. There is one option now,
AzzyztGeneratorOption.AddCxfRestClient, that you can use to
get a REST client project using
CXF as REST client library. Of all the
Java REST client APIs, CXF seems to be the most elegant. It uses an
interface with the same annotations as on server side. You call one
factory method using the interface as parameter, get a proxy, and this
proxy behaves just as the resource on server side would. Cool, clean,
minimum fuss. Of course the interfaces for generated REST services are
generated as well.
The documentation has now a JUnit test that covers everything
that’s in the cookbook
Up to now the REST runtime behavior was hard-coded to work around some
limitations of our Flex clients. In case of an error, the conformant
REST behavior would be to use HTTP status codes, for example
“500, Internal server error”. Our Flex clients
can’t (please don’t ask me why) access the status code and
can’t even find out if the error was on client or on server side.
Thus our servers return “200, OK” in case of an
error, with an XML error element indicating the kind of error. This is
OK as long as you read and parse XML responses yourself, but REST client
libraries like Apache CXF expect the proper result object on
“200, OK”. Now the default is, for the server to
behave correctly unless the client indicates otherwise via an HTTP
Changes in 1.2.3
The installed feature is now listed in the “about / installation
details / features” dialog.
An Azzyzt logo is displayed in the “about” dialog.
Azzyzt was built under Eclipse 3.7 “Indigo” against the
GlassFish 3.1 runtime. The plugin runs with all Eclipse versions since
Changes in 1.2.2
Support for JSON added. Query spec parameter for list operations is
intentionally still XML though.
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.
Changes in 1.2.1
Upgrading plugins now works. 1.2.0 failed to upgrade projects created
with 1.1.1 or earlier. You had to save your entities and other
self-written code, create a new azzyzted project, copy back the saved
code and generate anew.
Code generator, support and runtime libraries are now copied to an
automatically created project azzyzt_tools, and there into
a subdirectory called like the version of Azzyzt, e.g.
azzyzt_zools/1.2.1. Tools are run form there and no more
from the JARs embedded into the plugin. Eventually this will allow us to
run an old code generator from a new plugin.
EarContent/META-INF/azzyzt.xml is a new configuration file.
At the moment it only contains the version of Azzyzt that was used to
create the project or to generate code, but eventually it will be our
central place for meta information.
At the moment all upgrades are automatic and immediate. As soon as you
generate code in a project created by an older version of Azzyzt, the
project is upgraded.
Changes in 1.2.0
Added configuration options via Azzyztant.
Added runtime hook to Azzyztant for converting user names
as provided by the site adapter.
Made @Remote interfaces optional via AzzyztGeneratorOptions
and AzzyztGeneratorCutback.NoRemoteInterfaces. This means
JBoss AS 6.0 should be a fully supported runtime. No tests with JBoss
have been conducted though, thus I expect some glitches.
optional via AzzyztGeneratorOptions and
Added a Java program to bump Azzyzt’s version
Added basic validation to entities and embeddables. Generating now fails
unless every non-internal field has a default getter/setter. For
entities we would get a compile error in the converter anyway, but there
are hard-to-detect cases where embedded IDs fail to serialize a field.
This is now caught at generation time.
Changes in 1.1.1
Fixed a bug where the generated converters would try proxy id
substitution for string IDs. The generated code failed to compile where
the ID is checked if it’s less than zero.
Added entity Language to cookbook. It’s an example
for a simple string lookup table (language code → language long
Added Language to tutorial.
Removed two System.err.println()
Site adapters are still identical for magwien and generic. Now query
server for anonymous user name and user name header. Consider merging
Changes in 1.1.0
The “update()” operation was dropped. Basically it was a
“store()” without result and also implemented as such.
“store()” now returns not only the ID of the object (could
come from a sequence), but instead returns the DTO for the whole entity.
This avoids all problems with server-set timestamps or database column
defaults. You store something, you get back what’s in the database.
A new operation “storeMulti()” takes a list of DTOs of any
type, converts them to the respective entities and stores them. The
resulting entities are then converted back and the list of DTOs is
In case of interdependent objects, the numeric IDs of not-yet-existing
objects may be filled with unique negative numbers, so-called proxy IDs,
and references to other entities may use those proxy IDs. This works for
numeric IDs only, and it assumes that ID values can’t be negative,
but then, so does “EntityBase.couldBeIdValue()”.
Use “storeMulti()” to store multiple objects of any kind in
A new operation “deleteMulti()” takes a list of DTOs of any
type. Only the ID values must be set. The corresponding objects in the
database are deleted.
Use “deleteMulti()” to delete multiple objects of any kind
in one transaction.
A new operation “storeDeleteMulti()” takes two lists of DTOs
of any type. DTOs in the first list, the delete list, only need to have
their IDs set, DTOs in the second list, the store list, are treated
exactly as in “storeMulti()”. The operation returns the list
of stored entities, converted to external DTO form. Use
“storeDeleteMulti()” to make any kind of modification in one