This similar to issue 54867 but in that case it was not implemented yet and in this case it's a regression.
Basics:
- add/remove/rename cmp field, cmr field
- add/remove/rename cmp bean
- TBD: change field type such that it is no longer valid as field/cmr
For now, since we have no ui and no default mapping, we can skip handling add events. For basics, handle remove or
rename bean or field

Still to be done:
- rename cmp field
- remove/rename cmr field
- TBD: change field type such that it is no longer valid as field/cmr
The problem with these was that when we get the events/xpaths for cmp field name and for the cmr fields, there was no
way to get back to the path for the bean, which would be needed to find the corresponding entry in the
sun-cmp-mappings.xml.
From a discussion with Peter:
"As for CmpField->Entity, there is no way to track back to the parent. There are a couple of options.
We can do some sort of lookup. I threw together some code that builds a mapping and holds a weak reference (GC ->
rebuild on demand) but it would have to be maintained in case fields are deleted/added while the cache exists, which is
overhead I'd prefer to avoid.
Another possibility would be to add/remove listeners to entity beans themselves are they are created/destroyed and
specifically handle this case --> no mapping to maintain. This is what the old (5.5) code did, but for all ddbeans and
all xpaths, which I want to avoid. Doing it specifically for Entity/CmpField though isn't a big deal."