EDG-255 Reclaim Tag Ownership from Adapters, v2 - phase 2, REST (Edge)#1456
Open
Conversation
- Replace FileTag with GenericTag in FilePollingProtocolAdapter, FileDataPoint, and FileProtocolAdapterInformation - Switch tagConfigurationClass() to tagDefinitionClass() returning FileTagDefinition.class - Delete FileTag.java - Update FileProtocolAdapterConfigTest accordingly
…o avoid wildcard capture
Replace per-adapter EipTag with the canonical GenericTag. Update EipProtocolAdapterInformation to use tagDefinitionClass(), update EipPollingProtocolAdapter to cast to EipTagDefinition where needed, and update both test files. Delete EipTag.java.
Replace per-adapter Plc4xTag with the canonical GenericTag across AbstractPlc4xAdapter, Plc4xConnection, S7ProtocolAdapter, and ADSProtocolAdapter. Update both information classes to use tagDefinitionClass(). Cast to Plc4xTagDefinition wherever tag address or data type is needed. Update all test files. Delete Plc4xTag.java.
Replace per-adapter MtConnectAdapterTag with the canonical GenericTag. Update MtConnectProtocolAdapterInformation to use tagDefinitionClass(), update MtConnectProtocolAdapter to cast to MtConnectAdapterTagDefinition where needed, and update the test. Delete MtConnectAdapterTag.java.
Replace per-adapter DatabasesAdapterTag with the canonical GenericTag. Update DatabasesProtocolAdapterInformation to use tagDefinitionClass(), update DatabasesPollingProtocolAdapter to cast to DatabasesAdapterTagDefinition where needed. Delete DatabasesAdapterTag.java.
Switch tagConfigurationClass() to tagDefinitionClass() returning SimulationTagDefinition.class, update adapter and test to use GenericTag, and delete the now-redundant SimulationTag wrapper class.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
A
Tagis an Edge concept. It represents a named, described data point as Edge understands it — with a name, a description, and a lifecycle. ATagDefinitionis the adapter's concern: it is the adapter-specific addressing information needed to locate that data point on a device (e.g. a Modbus register address, an OPC-UA node ID).Edge should have complete control over what a tag is and how it behaves. Protocol adapters should only own what is necessary to address a tag on the device — i.e. the
TagDefinition. Adapters receiveTagobjects and pass them back to Edge, but they must not define or own theTagimplementation.Approach
The migration is done in phases. Phases 1 and 2 are fully compatible — no existing adapter needs to change. Phase 3 is incompatible and cleans up the SDK once all adapters have migrated. Phase 4 seals the interface to enforce the invariant permanently.
Phase 1 — SDK and Edge changes (compatible, no adapter changes required)
Phase 2 — Migrate adapters one at a time (compatible, per-adapter)
Migration steps for one adapter (example: OPC-UA)