I had a similar problem a few years ago that I also did not get around to solving - and my thinking at the time was writing a POJO that was itself fixed, but could dynamically chang its contents..
I was thinking about creating member properties as a collection of "look-up by reference" abstract POJOs (or interfaces) that would implement one of a small set of supported value type implementations. Thus the collection itself becomes the list of properties, which can grow or shrink as required. The SQL-OS now supports collections of type interface / abstract classes, which it didn't when I first had the idea. Scimpi would have been the only UI that could be made to handle it, though - to render the collection as a list of properties rather than a normal collection. Regards, Kevin On 24 May 2012 at 3:32, Christopher Caserio wrote: > I investigated this just recently, as I am working with an > ontology-based object repository with a REST interface, and wanted > to drive the domain model from the ontology. Dan hits on the main > stumbling blocks below. I thought about generating pojo classes with > javassist, but the post-initialization immutability precludes that. > I ended up generating java classes, and compiling them "offline". > This works, but does not track changes to the underlying metadata. > > A better approach would be to create a programming model that > bypasses pojos altogether, but that was more work than I had time > for on this project. Unfortunately, since the domain deals with > multiple repositories that are "discoverable" while the container is > running (the domain is actually centered on managing the > repositories and their contents), I would still have the > immutability problem (not to mention dealing with potential naming > and definition conflicts).
