Re: Review Request 73974: ATLAS-4614 :- Atlas - Deferred Actions : Add classification name in response
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73974/
---
(Updated June 16, 2022, 5 a.m.)
Review request for atlas, Jayendra Parab, Mandar Ambawane, and Pinal Shah.
Bugs: ATLAS-4614
https://issues.apache.org/jira/browse/ATLAS-4614
Repository: atlas
Description
---
In /api/atlas/admin/tasks call , when a tag is propagated , the
classificationVertexId is displayed. It becomes tough to debug when there are
many pending tasks . classification name can be added in the response in
addition to/instead of classificationVertexId.
Diffs (updated)
-
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/DeleteHandlerV1.java
6964211e9
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/EntityGraphMapper.java
9a7f29017
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/tasks/ClassificationTask.java
0bad84e49
Diff: https://reviews.apache.org/r/73974/diff/4/
Changes: https://reviews.apache.org/r/73974/diff/3-4/
Testing
---
Manual testing is done.
Pre-commit :
https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1096/consoleFull
Created 1000 hive_tables dependant on parent table.
Hive_tables name will be sequence_1 to sequence_999
Below step are tested for add, update and delete classification.
1) Adding classification :-
Create a classification with name test_1.
Added test_1 classification with checked on "propagate" of
sequence_1 hive_table, so this classification will be assign to all child table.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
2)Updating classification attribute value:-
Creating attribute for test_1 classification.
Updating classification attribute value on sequence_1
hive_table, then in background process it will update all the child table
attribute value.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
3)Deleteing classification:-
Create a classification with name test_2.
Added test_1 classification with checked on "propagte" and
"Remove propagation on entity delete" on sequence_1 hive_table, so this
classification will be assign to
all child table.
So background process is going on, will check the task status
API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
Re: Review Request 73974: ATLAS-4614 :- Atlas - Deferred Actions : Add classification name in response
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73974/
---
(Updated June 16, 2022, 4:59 a.m.)
Review request for atlas, Jayendra Parab, Mandar Ambawane, and Pinal Shah.
Bugs: ATLAS-4614
https://issues.apache.org/jira/browse/ATLAS-4614
Repository: atlas
Description
---
In /api/atlas/admin/tasks call , when a tag is propagated , the
classificationVertexId is displayed. It becomes tough to debug when there are
many pending tasks . classification name can be added in the response in
addition to/instead of classificationVertexId.
Diffs (updated)
-
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/DeleteHandlerV1.java
6964211e9
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/EntityGraphMapper.java
9a7f29017
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/tasks/ClassificationTask.java
0bad84e49
Diff: https://reviews.apache.org/r/73974/diff/3/
Changes: https://reviews.apache.org/r/73974/diff/2-3/
Testing
---
Manual testing is done.
Pre-commit :
https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1096/consoleFull
Created 1000 hive_tables dependant on parent table.
Hive_tables name will be sequence_1 to sequence_999
Below step are tested for add, update and delete classification.
1) Adding classification :-
Create a classification with name test_1.
Added test_1 classification with checked on "propagate" of
sequence_1 hive_table, so this classification will be assign to all child table.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
2)Updating classification attribute value:-
Creating attribute for test_1 classification.
Updating classification attribute value on sequence_1
hive_table, then in background process it will update all the child table
attribute value.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
3)Deleteing classification:-
Create a classification with name test_2.
Added test_1 classification with checked on "propagte" and
"Remove propagation on entity delete" on sequence_1 hive_table, so this
classification will be assign to
all child table.
So background process is going on, will check the task status
API.
curl k -u : -request GET
'https://:/api/atlas/admin/task
Re: Review Request 73974: ATLAS-4614 :- Atlas - Deferred Actions : Add classification name in response
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/73974/
---
(Updated June 16, 2022, 4:54 a.m.)
Review request for atlas, Jayendra Parab, Mandar Ambawane, and Pinal Shah.
Summary (updated)
-
ATLAS-4614 :- Atlas - Deferred Actions : Add classification name in response
Bugs: ATLAS-4614
https://issues.apache.org/jira/browse/ATLAS-4614
Repository: atlas
Description
---
In /api/atlas/admin/tasks call , when a tag is propagated , the
classificationVertexId is displayed. It becomes tough to debug when there are
many pending tasks . classification name can be added in the response in
addition to/instead of classificationVertexId.
Diffs
-
repository/src/main/java/org/apache/atlas/repository/store/graph/v1/DeleteHandlerV1.java
6964211e9
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/EntityGraphMapper.java
9a7f29017
repository/src/main/java/org/apache/atlas/repository/store/graph/v2/tasks/ClassificationTask.java
0bad84e49
Diff: https://reviews.apache.org/r/73974/diff/2/
Testing
---
Manual testing is done.
Pre-commit :
https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1096/consoleFull
Created 1000 hive_tables dependant on parent table.
Hive_tables name will be sequence_1 to sequence_999
Below step are tested for add, update and delete classification.
1) Adding classification :-
Create a classification with name test_1.
Added test_1 classification with checked on "propagate" of
sequence_1 hive_table, so this classification will be assign to all child table.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
2)Updating classification attribute value:-
Creating attribute for test_1 classification.
Updating classification attribute value on sequence_1
hive_table, then in background process it will update all the child table
attribute value.
So while background process is going on, will check the task
status API.
curl k -u : -request GET
'https://:/api/atlas/admin/tasks'
so in response will be
[
{
"type":
"CLASSIFICATION_PROPAGATION_ADD",
"guid":
"39f68061-2c5b-4e0c-9ba6-65b3d8117e99",
"createdBy": "admin",
"createdTime": 1651591949394,
"updatedTime": 1651591949394,
"parameters": {
"relationshipGuid": null,
"classificationName": "test_1",
"entityGuid":
"29a5ac89-a3fb-46ff-bbb1-646d3b0717dd",
"classificationVertexId":
"122896440"
},
"attemptCount": 0,
"status": "PENDING"
}
]
3)Deleteing classification:-
Create a classification with name test_2.
Added test_1 classification with checked on "propagte" and
"Remove propagation on entity delete" on sequence_1 hive_table, so this
classification will be assign to
all child table.
So background process is going on, will check the task status
API.
curl k
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make some business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to the behavior in 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make some business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. Due to 1) if one wants to make some business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definitions (and potentially perf issue as well) due to the behavior in > 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make some business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. Due to 1) if one wants to make some business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definitions (and potentially perf issue as well) due to 2). What's the > best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. Would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. Due to 1) if one wants to make business attributes apply to all entity > types today, the closest thing he could do would be setting applicable type > to "Referenceable", and that would cause the expansion of all entity type > definitions (and potentially perf issue as well) due to 2). What's the best > practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. Would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. Would it make more sense to align with classification's behavior (i.e., > empty/null means no restriction to all entity types)? > 2. Due to 1) if one wants to make business attributes apply to all entity > types today, the closest thing he could do would be setting applicable type > to "Referenceable", and that would cause the expansion of all entity type > definitions (and potentially perf issue as well) due to 2). What's the best > practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definitions (and potentially perf issue as well) due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. For 2), due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definitions (and potentially perf issue as well) due to 2). What's the > best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? Thanks > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. For 2), due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definition due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior as an improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? Thanks was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. For 2), due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definition due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? > Thanks -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions 1. For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? 2. For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > 1. For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > 2. For 2), due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definition due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > For 2), due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definition due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause the expansion of all entity type definition due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause all entity type definition expansion due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > For 2), Due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause the expansion of all entity > type definition due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Description: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty/null, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause all entity type definition expansion due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? was: Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause all entity type definition expansion due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty/null, none of entity types > will be applicable (while all entity types will be applicable in > classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > For 2), Due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause all entity type definition > expansion due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classification
[ https://issues.apache.org/jira/browse/ATLAS-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Liang updated ATLAS-4623: --- Summary: Different business metadata behavior of applicableEntityTypes compared to classification (was: Different business metadata behavior of applicableEntityTypes compared to classfication) > Different business metadata behavior of applicableEntityTypes compared to > classification > > > Key: ATLAS-4623 > URL: https://issues.apache.org/jira/browse/ATLAS-4623 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Affects Versions: 2.2.0 >Reporter: Allen Liang >Priority: Major > > Hi there, > When compared with the implementation of classification in terms of > applicable entity type, business metadata has a different implementation that > 1) When applicable entity type is set to empty, none of entity types will be > applicable (while all entity types will be applicable in classification) > 2) When applicable entity type is set to a specific entity type, that > specific entity type and each of its derived entity types will be added the > business attributes in their entity definition response (while classification > doesn't have this behavior) > > I have the following questions > For 1), would it make more sense to align with classification's behavior > (i.e., empty/null means no restriction to all entity types)? > For 2), Due to 1) if one wants to make business attributes apply to all > entity types today, the closest thing he could do would be setting applicable > type to "Referenceable", and that would cause all entity type definition > expansion due to 2). What's the best practice here? > > And in general, I am trying to understand what's the rationale behind this > different applicableEntityType implementation in business metadata compared > to classification? And do we consider changing to the similar implementation > to align with classification's behavior (which seems more reasonable) as an > improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (ATLAS-4623) Different business metadata behavior of applicableEntityTypes compared to classfication
Allen Liang created ATLAS-4623: -- Summary: Different business metadata behavior of applicableEntityTypes compared to classfication Key: ATLAS-4623 URL: https://issues.apache.org/jira/browse/ATLAS-4623 Project: Atlas Issue Type: Improvement Components: atlas-core Affects Versions: 2.2.0 Reporter: Allen Liang Hi there, When compared with the implementation of classification in terms of applicable entity type, business metadata has a different implementation that 1) When applicable entity type is set to empty, none of entity types will be applicable (while all entity types will be applicable in classification) 2) When applicable entity type is set to a specific entity type, that specific entity type and each of its derived entity types will be added the business attributes in their entity definition response (while classification doesn't have this behavior) I have the following questions For 1), would it make more sense to align with classification's behavior (i.e., empty/null means no restriction to all entity types)? For 2), Due to 1) if one wants to make business attributes apply to all entity types today, the closest thing he could do would be setting applicable type to "Referenceable", and that would cause all entity type definition expansion due to 2). What's the best practice here? And in general, I am trying to understand what's the rationale behind this different applicableEntityType implementation in business metadata compared to classification? And do we consider changing to the similar implementation to align with classification's behavior (which seems more reasonable) as an improvement in future release? -- This message was sent by Atlassian Jira (v8.20.7#820007)
Review Request 74027: ATLAS-4622: import fix to handle invalid zip entry
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74027/ --- Review request for atlas, Ashutosh Mestry, Jayendra Parab, Nikhil Bonte, Nixon Rodrigues, Pinal Shah, Radhika Kundam, Sarath Subramanian, Sharmadha Sainath, and Sidharth Mishra. Bugs: ATLAS-4622 https://issues.apache.org/jira/browse/ATLAS-4622 Repository: atlas Description --- updated to fail import operation when invalid zip entries were found Diffs - intg/src/main/java/org/apache/atlas/AtlasErrorCode.java 6ca933ff9 repository/src/main/java/org/apache/atlas/repository/impexp/ZipSourceWithBackingDirectory.java 79638009d Diff: https://reviews.apache.org/r/74027/diff/1/ Testing --- - verified that import fails on detecting entries with names having relative path to parent directory - pre-commit tests run https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1122/ Thanks, Madhan Neethiraj
[jira] [Created] (ATLAS-4622) import fix to handle invalid entries
Madhan Neethiraj created ATLAS-4622: --- Summary: import fix to handle invalid entries Key: ATLAS-4622 URL: https://issues.apache.org/jira/browse/ATLAS-4622 Project: Atlas Issue Type: Bug Components: atlas-core Reporter: Madhan Neethiraj Assignee: Madhan Neethiraj Atlas import functionality supports deployment option to unzip contents into a server directory. In such configuration, import should prevent invalid zip file entries, like those having relative path to parent directory,. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4575) Version Compatibility: Handle cross version messages in Atlas
[ https://issues.apache.org/jira/browse/ATLAS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554675#comment-17554675 ] ASF subversion and git services commented on ATLAS-4575: Commit 0b18b1483a7980721f9393413a9f18627f82864e in atlas's branch refs/heads/branch-2.0 from vinayak.marraiya [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=0b18b1483 ] ATLAS-4575 : SDX Version Compatibility - Handle cross version messages Signed-off-by: Pinal Shah (cherry picked from commit bad730c76de50ae9b4682b1c0a357d70edccbcc9) > Version Compatibility: Handle cross version messages in Atlas > - > > Key: ATLAS-4575 > URL: https://issues.apache.org/jira/browse/ATLAS-4575 > Project: Atlas > Issue Type: Task >Reporter: VINAYAK MARRAIYA >Assignee: VINAYAK MARRAIYA >Priority: Major > > Atlas server can receive notification messages from atlas hooks running on > different version (than Atlas server version). When messages are not > compatible, appropriate actions should be taken: > Log Error/Warning in Atlas logs about cross-compat version messages -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4575) Version Compatibility: Handle cross version messages in Atlas
[ https://issues.apache.org/jira/browse/ATLAS-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554674#comment-17554674 ] ASF subversion and git services commented on ATLAS-4575: Commit bad730c76de50ae9b4682b1c0a357d70edccbcc9 in atlas's branch refs/heads/master from vinayak.marraiya [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=bad730c76 ] ATLAS-4575 : SDX Version Compatibility - Handle cross version messages Signed-off-by: Pinal Shah > Version Compatibility: Handle cross version messages in Atlas > - > > Key: ATLAS-4575 > URL: https://issues.apache.org/jira/browse/ATLAS-4575 > Project: Atlas > Issue Type: Task >Reporter: VINAYAK MARRAIYA >Assignee: VINAYAK MARRAIYA >Priority: Major > > Atlas server can receive notification messages from atlas hooks running on > different version (than Atlas server version). When messages are not > compatible, appropriate actions should be taken: > Log Error/Warning in Atlas logs about cross-compat version messages -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4614) Deferred Actions : Add classification name in response
[ https://issues.apache.org/jira/browse/ATLAS-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554669#comment-17554669 ] ASF subversion and git services commented on ATLAS-4614: Commit aa358b727479aeab65fdaf18ff63da4a4927a11e in atlas's branch refs/heads/branch-2.0 from pareshD [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=aa358b727 ] ATLAS-4614 : Deferred Actions : Add classification name in response Signed-off-by: Pinal Shah (cherry picked from commit eaa6d1645e0f2215d9f210336d4be283f2bed05b) > Deferred Actions : Add classification name in response > > > Key: ATLAS-4614 > URL: https://issues.apache.org/jira/browse/ATLAS-4614 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Reporter: Paresh Devalia >Assignee: Paresh Devalia >Priority: Major > > In /api/atlas/admin/tasks call , when a tag is propagated , the > classificationVertexId is displayed. It becomes tough to debug when there are > many pending tasks . classification name can be added in the response in > addition to/instead of classificationVertexId. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4614) Deferred Actions : Add classification name in response
[ https://issues.apache.org/jira/browse/ATLAS-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554668#comment-17554668 ] ASF subversion and git services commented on ATLAS-4614: Commit eaa6d1645e0f2215d9f210336d4be283f2bed05b in atlas's branch refs/heads/master from pareshD [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=eaa6d1645 ] ATLAS-4614 : Deferred Actions : Add classification name in response Signed-off-by: Pinal Shah > Deferred Actions : Add classification name in response > > > Key: ATLAS-4614 > URL: https://issues.apache.org/jira/browse/ATLAS-4614 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Reporter: Paresh Devalia >Assignee: Paresh Devalia >Priority: Major > > In /api/atlas/admin/tasks call , when a tag is propagated , the > classificationVertexId is displayed. It becomes tough to debug when there are > many pending tasks . classification name can be added in the response in > addition to/instead of classificationVertexId. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4617) Atlas - Upgrade Spring Framework to 5.3.20
[ https://issues.apache.org/jira/browse/ATLAS-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554665#comment-17554665 ] ASF subversion and git services commented on ATLAS-4617: Commit 11d54f7e031dee0bb61da72c234277c8609ead23 in atlas's branch refs/heads/branch-2.0 from vinayak.marraiya [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=11d54f7e0 ] ATLAS-4617 : Upgrade Spring Framework to 5.3.20 Signed-off-by: Pinal Shah (cherry picked from commit bc49b631e9eb4f8e31feadb4b375b23a49aa9bdd) > Atlas - Upgrade Spring Framework to 5.3.20 > -- > > Key: ATLAS-4617 > URL: https://issues.apache.org/jira/browse/ATLAS-4617 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Reporter: VINAYAK MARRAIYA >Assignee: VINAYAK MARRAIYA >Priority: Major > > Currently Atlas is using Spring framework version 5.3.18 upgrading it to > 5.3.20 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (ATLAS-4617) Atlas - Upgrade Spring Framework to 5.3.20
[ https://issues.apache.org/jira/browse/ATLAS-4617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554664#comment-17554664 ] ASF subversion and git services commented on ATLAS-4617: Commit bc49b631e9eb4f8e31feadb4b375b23a49aa9bdd in atlas's branch refs/heads/master from vinayak.marraiya [ https://gitbox.apache.org/repos/asf?p=atlas.git;h=bc49b631e ] ATLAS-4617 : Upgrade Spring Framework to 5.3.20 Signed-off-by: Pinal Shah > Atlas - Upgrade Spring Framework to 5.3.20 > -- > > Key: ATLAS-4617 > URL: https://issues.apache.org/jira/browse/ATLAS-4617 > Project: Atlas > Issue Type: Improvement > Components: atlas-core >Reporter: VINAYAK MARRAIYA >Assignee: VINAYAK MARRAIYA >Priority: Major > > Currently Atlas is using Spring framework version 5.3.18 upgrading it to > 5.3.20 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4614) Deferred Actions : Add classification name in response
[ https://issues.apache.org/jira/browse/ATLAS-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paresh Devalia updated ATLAS-4614: -- Summary: Deferred Actions : Add classification name in response (was: Deferred Actions : Support to add classification name instead of classificationVertexId) > Deferred Actions : Add classification name in response > > > Key: ATLAS-4614 > URL: https://issues.apache.org/jira/browse/ATLAS-4614 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Reporter: Paresh Devalia >Assignee: Paresh Devalia >Priority: Major > > In /api/atlas/admin/tasks call , when a tag is propagated , the > classificationVertexId is displayed. It becomes tough to debug when there are > many pending tasks . classification name can be added in the response in > addition to/instead of classificationVertexId. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (ATLAS-4621) Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘XXXXX’
[ https://issues.apache.org/jira/browse/ATLAS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hansonhe updated ATLAS-4621: Description: *The logfile:logs/atlas.20220615-200134.out occured exceptions as following when run bin/atlas_start.py* 109981 [main] WARN org.springframework.web.context.support.XmlWebApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework .beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/] atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is org.springframework.b eans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl] as-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans. factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w] ebapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.fac tory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/] org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache .atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty 109984 [main] ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp|file:///opt/programs/apache-atlas-2.2.0/server/webapp] /atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is or g.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/at|file:///opt/programs/apache-atlas-2.2.0/server/webapp/at] las/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spr ingframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/] WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spring framework.beans.factory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas] -webapp-2.2.0.jar!/org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to inst antiate [org.apache.atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:749) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:189) at org.springframew
[jira] [Comment Edited] (ATLAS-4621) Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘XXXXX’
[ https://issues.apache.org/jira/browse/ATLAS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554557#comment-17554557 ] hansonhe edited comment on ATLAS-4621 at 6/15/22 12:41 PM: --- My atlas start environment with connect independent hbase-2.4.9,kafka,solr service，but without local embedded. After starting，I found hbase2 automake default:apache_atlas_janus successfully,but Kafka did not autocreate topic . When visit :21000 web return 503 was (Author: JIRAUSER290582): My atlas start environment with connect independent hbase-2.4.9,kafka,solr service，but without local embedded. After starting，I found hbase2 automake default:apache_atlas_janus successfully,but Kafka did not autocreate topic .when visit :21000 web reture 503 > Atlas start failed：UnsatisfiedDependencyException: Error creating bean with > name ‘X’ > > > Key: ATLAS-4621 > URL: https://issues.apache.org/jira/browse/ATLAS-4621 > Project: Atlas > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: hansonhe >Priority: Major > > The logfile:logs/atlas.20220615-200134.out occured exceptions as following: > 109981 [main] WARN > org.springframework.web.context.support.XmlWebApplicationContext - Exception > encountered during context initialization - cancelling refresh attempt: > org.springframework > .beans.factory.UnsatisfiedDependencyException: Error creating bean with name > 'atlasSecurityConfig' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/] > atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: > Unsatisfied dependency expressed through constructor parameter 9; nested > exception is org.springframework.b > eans.factory.UnsatisfiedDependencyException: Error creating bean with name > 'activeServerFilter' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl] > as-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.springframework.beans. > factory.UnsatisfiedDependencyException: Error creating bean with name > 'activeInstanceState' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w] > ebapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.springframework.beans.fac > tory.BeanCreationException: Error creating bean with name 'curatorFactory' > defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/] > org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean > failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [org.apache > .atlas.web.service.CuratorFactory]: Constructor threw exception; nested > exception is java.lang.IllegalArgumentException: connectionString cannot be > null or empty > 109984 [main] ERROR org.springframework.web.context.ContextLoader - Context > initialization failed > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'atlasSecurityConfig' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp|file:///opt/programs/apache-atlas-2.2.0/server/webapp] > /atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: > Unsatisfied dependency expressed through constructor parameter 9; nested > exception is or > g.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'activeServerFilter' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/at|file:///opt/programs/apache-atlas-2.2.0/server/webapp/at] > las/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.spr > ingframework.beans.factory.UnsatisfiedDependencyException: Erro
[jira] [Updated] (ATLAS-4621) Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘XXXXX’
[ https://issues.apache.org/jira/browse/ATLAS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hansonhe updated ATLAS-4621: Description: The logfile:logs/atlas.20220615-200134.out occured exceptions as following: 109981 [main] WARN org.springframework.web.context.support.XmlWebApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework .beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/] atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is org.springframework.b eans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl] as-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans. factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w] ebapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.fac tory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/] org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache .atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty 109984 [main] ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp|file:///opt/programs/apache-atlas-2.2.0/server/webapp] /atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is or g.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/at|file:///opt/programs/apache-atlas-2.2.0/server/webapp/at] las/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spr ingframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/] WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spring framework.beans.factory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas] -webapp-2.2.0.jar!/org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to inst antiate [org.apache.atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:749) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:189) at org.springframework.beans.factory.support.AbstractAutowireCap
[jira] [Commented] (ATLAS-4621) Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘XXXXX’
[ https://issues.apache.org/jira/browse/ATLAS-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554557#comment-17554557 ] hansonhe commented on ATLAS-4621: - My atlas start environment with connect independent hbase-2.4.9,kafka,solr service，but without local embedded. After starting，I found hbase2 automake default:apache_atlas_janus successfully,but Kafka did not autocreate topic .when visit :21000 web reture 503 > Atlas start failed：UnsatisfiedDependencyException: Error creating bean with > name ‘X’ > > > Key: ATLAS-4621 > URL: https://issues.apache.org/jira/browse/ATLAS-4621 > Project: Atlas > Issue Type: Bug >Affects Versions: 2.2.0 >Reporter: hansonhe >Priority: Major > > The logfile:logs/atlas.20220615-200134.out occured exceptions as following: > 109981 [main] WARN > org.springframework.web.context.support.XmlWebApplicationContext - Exception > encountered during context initialization - cancelling refresh attempt: > org.springframework > .beans.factory.UnsatisfiedDependencyException: Error creating bean with name > 'atlasSecurityConfig' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/] > atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: > Unsatisfied dependency expressed through constructor parameter 9; nested > exception is org.springframework.b > eans.factory.UnsatisfiedDependencyException: Error creating bean with name > 'activeServerFilter' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl] > as-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.springframework.beans. > factory.UnsatisfiedDependencyException: Error creating bean with name > 'activeInstanceState' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w] > ebapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.springframework.beans.fac > tory.BeanCreationException: Error creating bean with name 'curatorFactory' > defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/] > org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean > failed; nested exception is > org.springframework.beans.BeanInstantiationException: Failed to instantiate > [org.apache > .atlas.web.service.CuratorFactory]: Constructor threw exception; nested > exception is java.lang.IllegalArgumentException: connectionString cannot be > null or empty > 109984 [main] ERROR org.springframework.web.context.ContextLoader - Context > initialization failed > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'atlasSecurityConfig' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp|file:///opt/programs/apache-atlas-2.2.0/server/webapp] > /atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: > Unsatisfied dependency expressed through constructor parameter 9; nested > exception is or > g.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name 'activeServerFilter' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/at|file:///opt/programs/apache-atlas-2.2.0/server/webapp/at] > las/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: > Unsatisfied dependency expressed through constructor parameter 0; nested > exception is org.spr > ingframework.beans.factory.UnsatisfiedDependencyException: Error creating > bean with name 'activeInstanceState' defined in URL > [jar:[file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/|file:///opt/programs/apache-atlas-2.2.0/server/webapp/atlas/] > WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: > Unsatisfied dependency expressed thro
[jira] [Created] (ATLAS-4621) Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘XXXXX’
hansonhe created ATLAS-4621: --- Summary: Atlas start failed：UnsatisfiedDependencyException: Error creating bean with name ‘X’ Key: ATLAS-4621 URL: https://issues.apache.org/jira/browse/ATLAS-4621 Project: Atlas Issue Type: Bug Affects Versions: 2.2.0 Reporter: hansonhe 109981 [main] WARN org.springframework.web.context.support.XmlWebApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework .beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/ atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is org.springframework.b eans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atl as-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans. factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-w ebapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.fac tory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/ org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache .atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty 109984 [main] ERROR org.springframework.web.context.ContextLoader - Context initialization failed org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'atlasSecurityConfig' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp /atlas/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/security/AtlasSecurityConfig.class]: Unsatisfied dependency expressed through constructor parameter 9; nested exception is or g.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeServerFilter' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/at las/WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/filters/ActiveServerFilter.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spr ingframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'activeInstanceState' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/ WEB-INF/lib/atlas-webapp-2.2.0.jar!/org/apache/atlas/web/service/ActiveInstanceState.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.spring framework.beans.factory.BeanCreationException: Error creating bean with name 'curatorFactory' defined in URL [jar:file:/opt/programs/apache-atlas-2.2.0/server/webapp/atlas/WEB-INF/lib/atlas -webapp-2.2.0.jar!/org/apache/atlas/web/service/CuratorFactory.class]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to inst antiate [org.apache.atlas.web.service.CuratorFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: connectionString cannot be null or empty at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:749) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:189) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1196) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1098) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:511) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:481) at org.springframework.beans.factor
Re: Review Request 74021: ATLAS-4617 :- Atlas - Upgrade Spring Framework to 5.3.20
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74021/#review224510 --- Ship it! Ship It! - Jayendra Parab On June 15, 2022, 9:47 a.m., Vinayak Marraiya wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74021/ > --- > > (Updated June 15, 2022, 9:47 a.m.) > > > Review request for atlas, Jayendra Parab and Pinal Shah. > > > Bugs: ATLAS-4617 > https://issues.apache.org/jira/browse/ATLAS-4617 > > > Repository: atlas > > > Description > --- > > Currently Atlas is using Spring framework version 5.3.18 upgrading it to > 5.3.20 > > > Diffs > - > > pom.xml faf294e42 > > > Diff: https://reviews.apache.org/r/74021/diff/1/ > > > Testing > --- > > 1)mvn clean package -Pdist,embedded-hbase-solr -DskipTests -Drat.skip > Atlas server runnning > 2)Quick started was passed successfully > > > Pre-commit :- > https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1119/console > > > Thanks, > > Vinayak Marraiya > >
Re: Review Request 74021: ATLAS-4617 :- Atlas - Upgrade Spring Framework to 5.3.20
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74021/ --- (Updated June 15, 2022, 9:47 a.m.) Review request for atlas, Jayendra Parab and Pinal Shah. Bugs: ATLAS-4617 https://issues.apache.org/jira/browse/ATLAS-4617 Repository: atlas Description --- Currently Atlas is using Spring framework version 5.3.18 upgrading it to 5.3.20 Diffs - pom.xml faf294e42 Diff: https://reviews.apache.org/r/74021/diff/1/ Testing (updated) --- 1)mvn clean package -Pdist,embedded-hbase-solr -DskipTests -Drat.skip Atlas server runnning 2)Quick started was passed successfully Pre-commit :- https://ci-builds.apache.org/job/Atlas/job/PreCommit-ATLAS-Build-Test/1119/console Thanks, Vinayak Marraiya
[jira] [Updated] (ATLAS-4620) Remove EmbeddedKafkaServer from compile dependencies in Atlas notification module
[ https://issues.apache.org/jira/browse/ATLAS-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrik Márton updated ATLAS-4620: - Description: Goal is to break the strong coupling between Atlas components and Kafka. These dependencies include using server side libraries of Kafka (this couples the Scala version and other non-public interfaces of Kafka). Any code using server side libraries of Kafka should be refactored. The notification module uses an EmbeddedKafkaServer which brings in the core kafka dependency. Based on the usage in the source, it is only used during testing, but pulled in as a compile dependency. If there is a way to avoid using this embedded kafka server for other reasons (eg. development), this can be moved to the test folder and pulled in as a test scope dependency. https://github.com/apache/atlas/blob/master/notification/src/main/java/org/apache/atlas/kafka/EmbeddedKafkaServer.java was: Goal is to break the strong coupling between Atlas components and Kafka. These dependencies include using server side libraries of Kafka (this couples the Scala version and other non-public interfaces of Kafka). Any code using server side libraries of Kafka should be refactored. The notification module uses an EmbeddedKafkaServer which brings in the core kafka dependency. Based on the usage in the source, it is only used during testing, but pulled in as a compile dependency. If there is a way to avoid using this embedded kafka server for other reasons (eg. development), this can be moved to the test folder and pulled in as a test scope dependency. > Remove EmbeddedKafkaServer from compile dependencies in Atlas notification > module > - > > Key: ATLAS-4620 > URL: https://issues.apache.org/jira/browse/ATLAS-4620 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Reporter: Patrik Márton >Priority: Major > > Goal is to break the strong coupling between Atlas components and Kafka. > These dependencies include using server side libraries of Kafka (this couples > the Scala version and other non-public interfaces of Kafka). Any code using > server side libraries of Kafka should be refactored. > The notification module uses an EmbeddedKafkaServer which brings in the core > kafka dependency. Based on the usage in the source, it is only used during > testing, but pulled in as a compile dependency. > If there is a way to avoid using this embedded kafka server for other reasons > (eg. development), this can be moved to the test folder and pulled in as a > test scope dependency. > https://github.com/apache/atlas/blob/master/notification/src/main/java/org/apache/atlas/kafka/EmbeddedKafkaServer.java -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (ATLAS-4620) Remove EmbeddedKafkaServer from compile dependencies in Atlas notification module
Patrik Márton created ATLAS-4620: Summary: Remove EmbeddedKafkaServer from compile dependencies in Atlas notification module Key: ATLAS-4620 URL: https://issues.apache.org/jira/browse/ATLAS-4620 Project: Atlas Issue Type: Bug Components: atlas-core Reporter: Patrik Márton Goal is to break the strong coupling between Atlas components and Kafka. These dependencies include using server side libraries of Kafka (this couples the Scala version and other non-public interfaces of Kafka). Any code using server side libraries of Kafka should be refactored. The notification module uses an EmbeddedKafkaServer which brings in the core kafka dependency. Based on the usage in the source, it is only used during testing, but pulled in as a compile dependency. If there is a way to avoid using this embedded kafka server for other reasons (eg. development), this can be moved to the test folder and pulled in as a test scope dependency. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (ATLAS-4619) Refactor Atlas webapp module to remove Kafka core dependency
Patrik Márton created ATLAS-4619: Summary: Refactor Atlas webapp module to remove Kafka core dependency Key: ATLAS-4619 URL: https://issues.apache.org/jira/browse/ATLAS-4619 Project: Atlas Issue Type: Bug Components: atlas-webui Reporter: Patrik Márton Goal is to break the strong coupling between Atlas components and Kafka. These dependencies include using server side libraries of Kafka (this couples the Scala version and other non-public interfaces of Kafka). Any code using server side libraries of Kafka should be refactored. Since atlas webapp module uses the ShutdownableThread from core kafka, it should be refactored in a way to eliminate this dependency. https://github.com/apache/atlas/blob/master/webapp/src/main/java/org/apache/atlas/notification/NotificationHookConsumer.java#L526 -- This message was sent by Atlassian Jira (v8.20.7#820007)
