Exceptions when using connector are insufficient about egeria-connector-ibm-information-server

[grahamwallis]

I think that would be consistent with the local repositories.

[planetf1]

If this doesn't apply to other connectors feel free to TRANSFER accordingly...

[cmgrote]

This might be IGC connector-specific: at the moment there seems to be a particular ordering I'm reliant on between the overridden initialize(), setMetadataCollectionId() and start() methods to be able to setup the OMRSMetadataCollection with a valid connection to the underlying IGC repository -- and the audit log is only available (to log records beyond the developer logs) as of the start() method...

If I'm only able to initialize the OMRSMetadataCollection after I've setup the IGC connection, but this must occur before the start() method is called, then I think we may have a more general problem in terms of sequencing (that is likely to affect other connectors as well)...

Need to work through the detailed sequencing -- will leave here for now, but assign to me.

[cmgrote]

Looks like the following sequence occurs at startup:

1. EventMapper -- initialize()
2. Connector -- initialize()
3. Connector -- setMetadataCollectionId()
4. EventMapper -- setMetadataCollectionId()
5. Connector -- getMetadataCollection()

If I move all of the logic of setting up the connection to IGC itself into the start() method of the connector, that is never called before getting to the getMetadataCollection() call above -- which means that call will then result in an OMRS-REPOSITORY-400-025 (null metadata collection)...

@mandy-chessell is this expected? Should I:

• move my logic to actually setup the metadata collection (which to be reliable requires me to first ensure I can connect to the IGC host itself) into the getMetadataCollection() method (keeping in mind that I have no audit log there to record what's happening with the IGC connectivity)?
• or is there another issue in that the start() method of the connector should be called before the getMetadataCollection() method?
• or should I not assume that my metadata collection itself has a working IGC client connection at the time of construction, but have every single method in the class first check for such a connection's existence (again, though, I don't think I have any audit log access from the metadata collection, so no way to record anything about IGC connectivity)?

[cmgrote]

Think I might have just answered it -- actual ordering (with audit log) is:

1. EventMapper -- initialize()
2. EventMapper -- setAuditLog()
3. Connector -- initialize()
4. Connector -- setAuditLog()
5. Connector -- setMetadataCollectionId()
6. EventMapper -- setMetadataCollectionId()
7. Connector -- getMetadataCollection()

So it seems that the audit log actually should be available just after the initialize() (ie. before the getMetadataCollection()). Therefore I think I can go for the first bullet above?

[cmgrote]

Ok, I've got the ordering working -- now the issue seems to be that the audit log only reports out the very top of the problem stack, so in the case where we say try to connect to a nonexistent host, the only message we get out (even though there is a deeper chain of exceptions that are far more descriptive that the connection was refused or the host is unknown) is that the failure is due to a null metadata collection...

[cmgrote]

Should be fixed by odpi/egeria#2384