[nat101]

1. The ide has to be aware of the contents within the annotations. For example, if I have a NamedQuery defined in entity A, it should provide context assistance in a session Facade or a Servlet (or any other class) to the named query.
1b. The validation system needs to flag any ejb3 related error that would cause the module to fail when deployed, eg a typo in a NamedQuery. The validation system needs to understand EE5 rules.

2. When reverse-engineering a schema to ejb3 entities have an option to generate toString, hashcode, and compareTo (if Comparable). Since the key of the entity is known, you already have the data needed to correctly generate these methods.
2b. On the flip side, allow for the generation of the entities with MINIMAL annotations. Most of my entities work OK with 1 simple annotation for the entity (@entity) and 1 for the key (@ID). (But I would still like toString, hashcode, compareTo (in some cases) for these too.)

3. There might be a quick solution for the UML—> ejb3 problem. If you introduce a simple feature that transforms existing pojos into entity beans, then besides the usefulness of this in general, it can also be used as an intermediate step from uml to ejb3. Since the uml does generate pojos, it need not be annotation-aware. This should be simple to implement, and the usefulness of ME rises exponentially. All of a sudden ME has a route from UML to ejb3!

4. Last but not least. A JP-QL ad-hoc editor, similar to the sql editor you now have.

Thanks.
nat

[Riyad Kalla]

nat,
as always great feedback. Passing along to dev team asap.

[Author]

Posts