Giters

smallrye / jandex

Java Annotation Indexer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Manually creating index objects

sebersole opened this issue · comments

commented

Hey Jason, etal. I started playing around again with using Jandex in Hibernate.

The thing I am still unsure of is how to manually build ClassInfo, MethodInfo, etc objects. For background, this is related to applying orm.xml mapping overrides. I realize this is a unique use-case, but wondered if you know of anything else using Jandex in a similar fashion or thoughts on how to best accomplish this.

The main thing I run into is that I need to re-create all of the AnnotationTarget references, which seems to get messy

commented

@sebersole we should chat sometime about this use-case. Are you thinking this is an override mechanism, like ideally you would read from bytecode, and then seed the mocks, which you then modify with the orm.xml metadata?

commented

@n1hility To be honest, I really have no idea how to accomplish this best. We have a working prototype of this, but:

  1. its literally 7 years old at this point. don't know if you remember but its the prototype that prompted me to ask you about modeling all "targets", not just annotated ones.
  2. as far as I remember, that one only supported "complete" XML mappings, not applying XML overrides. mainly because we were not sure the best way to handle that.

I had kind of hoped I could do something like leverage a CompositeIndex composing (1) the "real" Index and then (2) an "overide" Index, preferring the override form. But like I said, I got into trouble with the need to duplicate stuff.

Just looking for some hints/guidance

commented

@sebersole the most common pattern I have seen is that there is a metadata model or DSL that represents the true "configuration", and then the annotations and the XML just feed into that following the specific override rules. The model you describe I think makes sense if the natural contract is 100% equivalent subset to the Java structure. Otherwise you will end up emulating config style structures as made up Java types, which can get a little strange. For example, it's more intuitive to say config.description() than to say clazz.field("something).annotation("Description").

I haven't looked at orm.xml in awhile. I should take a look.

commented

There are basically 2 modes of interpreting an orm.xml - complete and incomplete.

Complete mappings fully define the model, meaning even if there are annotations available we will ignore them. This is specified in the mapping itself.

Incomplete mappings are interpreted as overrides. Like say the annotations say to map your attribute "description" to a column named "description", the orm.xml might say to instead use the column "summary".

I think what you are asking (the "100% equivalent" part is confusing) is whether the orm.xml can alter the perceived structure of the domain model - aka, can it add a new attribute. So that depends. In the complete case, it will unequivocally add attributes; that's the whole purpose. For the incomplete case, no the overrides cannot add new attributes; though technically the Jandex model already knows about the field/method(s) that define that attribute.

As for the approach of a "meta model" or DSL, sure. We have something like that obviously. What you suggest would be using our org.hibernate.mapping model which is an iterative model we populate as we read XML and annotations. That's a very fugly solution for us based on that model. In fact, I had hoped to eventually use Jandex as sort of that incremental "source"- the idea being that we would unify annotations, orm.xml and hbm.xml information into Jandex and use that to populate that o.h.mapping model.

The mapping model serves a lot of different roles across many projects and we are very careful about changes there.