-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customizable analysis #164
Customizable analysis #164
Conversation
name = name == null ? defaultValues.getName() : name; | ||
String description = config.getDescription(); | ||
description = description == null ? defaultValues.getDescription() : description; | ||
return builder.setId(config.getId()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a bit odd that we create a TmfConfiguration with id, name, description that can come from the json string and then the TmfConfiguration also contains the json string, so these values are duplicated inside the TmfConfiguration object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this statement for name and description. The ID is generated to remove burden of end-user to create a unique ID. We use this class to serialize a TmfConfiguration that has generated ID. When deserializing the configuration, we read the ID back, no need for regeneration.
* @return list of the available providers for this trace / experiment | ||
* @since 9.5 | ||
*/ | ||
public synchronized @NonNull List<IDataProviderDescriptor> getAvailableProviders(ITmfTrace trace, String configId, String... ids) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For supporting per base DataProvider conifgurations We would need a getAvailableProviders(ITmfTrace trace, String... ids)
to return all DataProviders which contain the (factoryId == baseDataProvider ID).
That, or DataProvider Descriptor object would need to be a tree of descriptor strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could be useful. It would return all derived data providers for all configurations for the base data provider.
* | ||
* @since 9.5 | ||
*/ | ||
default String getJsonParameters() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not be needed because only the map will be supported:
See eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)
* If the creation of the configuration fails | ||
* @since 9.5 | ||
*/ | ||
default ITmfConfiguration create(String parameters) throws TmfConfigurationException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not be needed because only the map will be supported:
See eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)
throw new TmfConfigurationException("Can't convert json string to Map to update configuration", e); //$NON-NLS-1$ | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not be needed because only the map will be supported:
See eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)
* if an error occurs | ||
*/ | ||
// List<IDataProviderDescriptor> createDataProviderDescriptors(String typeId, ITmfTrace trace, Map<String, Object> parameters) throws TmfConfigurationException; | ||
List<IDataProviderDescriptor> createDataProviderDescriptors(String typeId, ITmfTrace trace, String jsonParameters) throws TmfConfigurationException; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API should use Map<String, Object> as discussed here: eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)
* if an error occurs | ||
*/ | ||
void removeDataProviderDescriptor(ITmfTrace trace, IDataProviderDescriptor descriptor) throws TmfConfigurationException; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this interface needs also a method to remove the config which will then remove the data providers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class might not be needed and json serialization and deserialization to disk can be in the TmfConfiguration class after removing the jsonParameter string support, as discussed here:
eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)
name = name == null ? defaultValues.getName() : name; | ||
String description = config.getDescription(); | ||
description = description == null ? defaultValues.getDescription() : description; | ||
return builder.setId(config.getId()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this statement for name and description. The ID is generated to remove burden of end-user to create a unique ID. We use this class to serialize a TmfConfiguration that has generated ID. When deserializing the configuration, we read the ID back, no need for regeneration.
* @since 9.5 | ||
*/ | ||
default @Nullable String getParentId() { | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted to only have the parentId in the descriptor to create an hierarchy and not having also a getChildren() method. This is easier to implement at the moment, but we can opt to implement it at a later time if we realize it's to iterating through the list of descriptors to find the parent - children hierarchy.
If we opt to have the getChildren() I suggest to implement later and not in the initial version of the fullstack support of data provider configurations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds right. Currently, DataProviderManager maintains a list of all Data Providers, and we don't have nesting of derived data providers. So, base data providers don't really need to be aware of their children.
As you said, after full-stack implementation, if we see any performance or simplicity benefit by adding getChildren(), we can implement it.
* data provider, or null if not applicable | ||
* @since 9.5 | ||
*/ | ||
default @Nullable ITmfConfiguration getCreationConfiguration() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the name of the method. Any suggestions for a better name? @PatrickTasse @abhinava-ericsson
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just getConfiguration()
is fine till we don't allow modification of an existing configuration. Later, if we do allow that, we can differentiate between getConfiguration()
and getInitialConfiguration()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getConfiguration()
sounds like there can be only one. We might (I don't have use case yet) some other configuration, that does something else than creating a data provider. That's why I used creationConfiguration
, but I don't like it. Maybe for now we call it getConfiguration()
as you suggested and that's the configuration that was used for creation. If we in the future support another configuration we can find a name for the new type configuration.
@@ -273,6 +273,37 @@ public interface ITmfTrace extends ITmfEventProvider { | |||
*/ | |||
@NonNull Iterable<@NonNull IAnalysisModule> getAnalysisModules(); | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@PatrickTasse @abhinava-ericsson
This API needs explanation. In Trace Compass analysis modules are managed by the TmfAnalysisFramework through IAnalysisModuleSource extension. The ITmfTrace has a method getAnalysisModules() and that collection has only analysis modules that are configured through the analysis framework when opening a trace TmfTraceOpenSignal() processed which triggers the method executeAnalysis(). This then call TmfAnalysisManager.getAnalysisModules() which will then instantiate the modules and store in the trace object
Many data provider factories often use TmfTraceUtils.getAnalysisModulesOfClass(trace, IFlameChartProvider.class);
which call ITmfTrace.getAnalysisModules()
. So, if an analysis module is not know by the analysis framework, then analysis module is not instantiated and not return by the trace.
These 2 methods will by-pass the analysis framework and custom analysis modules can be added and removed. This is needed for the custom analysis implementation.
Please note that the analysis framework, reads some global configuration to instantiate so-called IAnalysisModuleHelpers which globally available and assigned to applicable traces. These helpers are used to instantiate the actual analysis module and then configure it with parameters provided by the extension point or xml definition.
One thing to remember, if we would like to use the analysis framework for custom analysis, which is doable and I prototyped, there needs to global storage of configuration files (e.g. json), a manager class that can add and remove such configurations as well as assign it to a trace. However, the design of customizable analysis through data providers (factories) doesn't the provision for having such manager class and the required server endpoint.
* @return true if it was successful or false if invalid config (TODO should we through exception?) | ||
* @since 9.5 | ||
*/ | ||
default boolean setConfiguration(ITmfConfiguration configuration) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This use needed to be able to add the configuration IDataProviderDescriptors for derived data providers. This is not used by the analysis framework, and hence doesn't have equivalent methods in IAnalysisModuleHelper.
* @return true if it was successful or false if invalid config (TODO should we through exception?) | ||
* @since 9.5 | ||
*/ | ||
default @Nullable ITmfConfiguration getConfiguration() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This use needed to be able to add the configuration IDataProviderDescriptors for derived data providers. This is not used by the analysis framework.
* @return the configuration root path | ||
* @since 9.5 | ||
*/ | ||
default @Nullable String getConfigurationRoot() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed. It's an artifact from a protoype that uses the anlaysis framework.
d013347
to
140ffae
Compare
140ffae
to
751b02c
Compare
Update (Oct 28, 0204):
All the PRs below are merged.
This PR combines different commits to allow for customization of analysis using a json definition. These customable analyses are exposed through data providers used in conjunction with the Trace Compass trace server.
Note that some of the commits are also available as separate pull requests.
List of commits/PRs:
tmf: add jsonParameters to ITmfConfiguration and ITmfConfigurationSource #144Signed-off-by: Bernd Hufmann [email protected]