[BUG] ClassCastException at getSchemaTypeForElement (Asset-Manager) #7692
Comments
dbruns91
added
bug
|
@mandy-chessell Can you have a look at this? |
|
I will add it to my list and look at it when I get some time. |
|
@dbruns91 and I had a talk this morning about this. The error shows to debug we suggested:
|
|
I expect that the audit log will show where the problem is and this level of effort to recreate will not be required. |
|
@davidradl here is the draft pr for the connector: odpi/egeria-connector-integration-lineage-event-driven-sample#66 I will use the next days to setup a local egeria instance. |
|
I have switch the owner to @davidradl since you have taken it over from me. |
Signed-off-by: Mandy Chessell <[email protected]>
|
I have added a PR to 4.2-SNAPSHOT. It fixes multiple issues in Asset Manager's schema function which is also surfaced through the Lineage Integrator OMIS. It also involved restructuring the schema element beans so they closer match the structure used in Data Manager OMAS. Therefore, your lineage connector is likely to need some code changes to work with the latest level of Egeria. However, it may then work :) |
|
@mandy-chessell Thank you for the PR. That sounds great. I will test it asap so we can close this issue. |
|
@mandy-chessell I updated the connector to 4.2-SNAPSHOT, sent an typical metadata event to the topic and got the following error message: The connector code looks like this Do you see a problem? The creation logic above do not throw an error in 3.15. |
|
I tested (nearly) the same code in 4.1 - that works fine. It ended with without an error. |
|
I think that the GUIDs are around the wrong way - the schemaTypeChoiceGUID should be endOne and the eventType GUID is endTwo. However that does not explain where there is a null GUID being passed through. Another thought is that there is a new method called createAnchoredSchemaType() which is designed to anchor the schema type entities to the asset. (So anchorGUID=assetGUID). This means that if the asset is deleted, the schema elements are deleted too. Creating schemaAttributes always anchors them to the same anchor as the element that the new schema attribute is connected to. With schema types they can be created/used independently of the asset or anchored - this is why there are two methods for creatign schema types. |
|
According to your tips I changed it like this: It throws the same exception. I am still wondering that nearly the same code works fine in Egeria 4.1 . Does Egeria 4.2 have such big changes? |
|
I can't see much change - the code still seems to be using createSchemaType() rather than createAnchoredSchemaType() and the relationshipGUIDs are the wrong way around. Is this the new code? The main changes between 4.1 and 4.2 are in the retrieval of schema types. I did also fix a couple of bugs (such as the schem type GUID being reversed) and I added createAnchoredSchemaType. It would be a great help to see the audit log entries for the failing call from the metadata access server. This will show me the stack trace of where it is failing. Also you can also check in your code that neither schemaTypeGUID nore schemaTypeChoiceGUID is null. They should not be - but it may help to identify the problem |
|
I had not changed createAnchoredSchemaType(..) everywhere, maybe this was wrong. In the code above the change is in the for-loop. Now I changed it everywhere and flipped schemaTypeGUID and schemaTypeChoiceGUID (sorry I had missed that): The egeria base/metadate-server error logs like this: |
|
So it seems, with your changes, that the error has shifted. The exception shows that the error is now in the call This is the method signature: The schemaTypeGUID is the second parameter and the asset GUID (KafkaTopic's GUID in this case) is the third parameter. So if the call is changed from to it may work. This change in parameter ordering may be one of the bugs I fixed - I know I fixed one of the relationship methods because the server-side had incorrectly flipped the relationship end guids. That could explain why it worked before even though it was incorrectly coded. |
|
It worked! Thank you, Mandy :-) It makes sense to change it that way, it is just hard to understand when you are not so into Egeria ;-) Last question to this topic: What is the best way to get a list of "EventType" which is associated to "-EventTypes"? In our MockLineageIntegratorContext I created an extra method for this: Maybe I am understand something wrong and/or this is not the right way to do it ... or there is a method missing. |
|
When you retrieve the schemaType for the asset, you are returned the schemaTypeElement for the SchemaTypeChoice entity. Inside that element is the list of option schema types. These are the event types. |
|
Great! Thank you for the explanation! My local tests looks good. I will close this. |
Existing/related issue?
No response
Current Behavior
When we try to get the schema type through the REST or Java API (LineageIntegratorContext) the egeria server returns an error message with a ClassCastException.
POST
with body
Response
Before we created the SchemaTypeChoice (type: EventTypeList) with the SchemaType (type: EventType) the following way:
Expected Behavior
The REST call above should works like the following call through the data manager:
GET
This call returns returns us an EventTypeList with all EventTypes associated to the asset, the kafka topic. We expected to get the same or a similiar response on this endpoint
At best It should be possible to get this response through the Java API (LineageIntegratorConnector).
Steps To Reproduce
Environment
Any Further Information?
No response
The text was updated successfully, but these errors were encountered: