@exceptionfactory Thank you for submitting this change. In overall looks good, but I'll get more into the details and review it later today.

@takraj - thanks for reviewing, I'll wait for your feedback.

As a side note, the current dependency usage makes me think we should deprecate this bundle. It is currently using the Asana client 1.0.0 (https://github.com/exceptionfactory/nifi/blob/main/nifi-extension-bundles/nifi-asana-bundle/pom.xml#L48) which is here https://github.com/Asana/java-asana. It is no longer maintained and the recommendation is: "We recommend using Java's HttpClient or similar HTTP libraries to make direct API requests instead."

This bundle currently brings a lot of very old dependencies (grpc 1.59, google http client 1.47, etc). So unless someone is willing to do the work, I think we should mark it as deprecated for removal in the future. I don't think the effort is huge but as always it's a matter of finding someone :)

@exceptionfactory

implementation replaces the generic Serializer and Deserializer implementation, built on Java Object serialization.

Did you test, what happens after upgrading to the new format? I can't see any migration logic. Will the state be simply lost, or will it cause the processor to crash until the user clears the state?

@pvillard31

As I see there is an OpenAPI spec for Asana, so a new client could be simply generated from it:
https://github.com/Asana/openapi

I can't tell however, how much work is it to adapt the differences if there are any. The original client was also generated from OpenAPI, but they have made a pre-built version available on maven too.

I would suggest to create a NIFI ticket to migrate this component to a new, generated client.

@exceptionfactory

implementation replaces the generic Serializer and Deserializer implementation, built on Java Object serialization.

Did you test, what happens after upgrading to the new format? I can't see any migration logic. Will the state be simply lost, or will it cause the processor to crash until the user clears the state?

Yes, changing the format does result in exceptions on upgrade when there is existing state. This will require manual clearing of stored state in the associated cache server.

@pvillard31

As I see there is an OpenAPI spec for Asana, so a new client could be simply generated from it: https://github.com/Asana/openapi

I can't tell however, how much work is it to adapt the differences if there are any. The original client was also generated from OpenAPI, but they have made a pre-built version available on maven too.

I would suggest to create a NIFI ticket to migrate this component to a new, generated client.

@takraj Is this something you are planning to work on soon? If not, then I agree with Pierre's suggestion that the current Processor should be marked as deprecated for removal.

Deprecating for removal could also provide the opportunity for a new future implementation if needed. Published NAR bundles of the current version could continue to be used, without maintaining the source code, if maintenance cycles are not available to work through the upgrade and redesign needed.

@takraj and @pvillard31, I submitted PR #10601 to deprecate the current GetAsanaObject Processor and supporting Controller Service for removal. That should provide a path forward, just leaving this current issue as a minimal change to eliminate Java Object serialization.

Thanks @pvillard31, I updated the Migration Guidance for 2.7.0 to mention the state change and deprecation for GetAsanaObject.

@pvillard31 +1 from my side as well.

Thanks for the reviews @takraj and @pvillard31!