SetID

[Rod Widdowson]

I was thinking about this overnight.  I think that we are chasing a few
different directions, and I'm guilty of adding a few more. I'd like to
capture my thoughts - we might be able to nail this down before Friday, if
not we can do so then.

1) setId()

Scott said:

> Note that on the call we alluded to the fact that we probably should
> eliminate all the implicit calls to setId, because these keep biting us

I'm not sure what you mean by implicit.  I do think that we need to look at
the explicit calls and make sure that their inputs are guaranteed non-null.
The implicit calls should all be deal with by the bean post-processor (see
below).  Again, I'll take a UI to check that (manually).  I'll enter a case
to track this.

I'll also add that the reason why the setID bites us is because we demand
that getID() be @nonnull.  So we are trading off some "shift-left" hassle
with setID against NPEs in the field.

Of course the real question is the one Scott mentioned:  Why do we need
GetID().

> then we should stop requiring IDs. I think that's been
> basically an unhelpful concept for us.

Last time through we killed off the most gratuitous identifiable bean (was
it the Event or perhaps the Context?).  I think it might be useful to do
another pass through (and I'll take an AI to do that and enter a case).   I
fear that we have got rid of all the low hanging fruit and two alpha
releases in seems like a bit late & perturbing to be going after the higher
ones.  As a worked example, consider the Filter Objects (below).  For the
rest I'll report back.

2) The bean post processor.

This has always worried me, but I cannot explain why so I have to assume
it's either some Calvanistic worry about "making things to easy", or perhaps
an indication that the real issue is that we required setID on too many
things, see above.

The fact is that it is there now (and yes I agreed to having it there so my
nagging worries do not count) and it is definitely too late to consider
removing it.  I would suggest that we inspect those cases that it is
currently warning about (where bean ID and object ID are both specified).
I'll enter a case for that.

I don't see that making the code more complex serves anything and I'm not
sure that distinguishing custom-parsed beans from standard beans gains us
anything.  But again I missed the last meeting.

3) Requiring identifiers in the configuration of filter objects (IDP-451)

The filter objects have to be named because of their putative use in
references; because of this the Identifier is derived from the id in the
custom config element, plus some stuff about where it comes from (it's an
incomplete attempt to uniquify names based on their location), if there is
no id in the config element then that part is generated.

Filter object references are partly implemented, and I think that as part of
this discussion we need to decide whether to fully implement them or to fail
configurations with references in them (much like V2).    Certainly in the
latter case, and possibly in the former, the cruft around the name
uniquification could be dropped.

The other use of Id for is in logging.  Because the generated name is messy,
if we want to use the ID then it becomes sensible to require the ID to be
specified.  However this is heavyweight.

I suggest that we deal with this by making the logPath something which the
parsers configure.  Then if the config element has the ID we can use that
otherwise we can derive something sensible from the parameterization.

/Rod