August 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-539) Content update of artifact is not part of audit history

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-539?page=com.atlassian.jira.plugin.... ] Eric Wittmann edited comment on SRAMP-539 at 8/8/14 10:04 AM: -------------------------------------------------------------- While it wouldn't be *too* hard to audit an update, we should really consider removing the content update feature. The spec is a little ambiguous on the topic if I recall correctly. *EDIT*: In particular, updates are problematic with regard to derived content. What do we do with the derived artifacts if we change the content? Presumably we would delete them and re-derive. But if we do that, we might lose meta-data added to those derived artifacts manually by users. There may also be relationships that have been formed on those derived artifacts, in which case referential integrity will prevent them from being deleted, and the update will fail. All in all I am disappointed in myself for implementing the updateContent feature to begin with. was (Author: eric.wittmann): While it wouldn't be *too* hard to audit an update, we should really consider removing the content update feature. The spec is a little ambiguous on the topic if I recall correctly. EDIT: In particular, updates are problematic with regard to derived content. What do we do with the derived artifacts if we change the content? Presumably we would delete them and re-derive. But if we do that, we might lose meta-data added to those derived artifacts manually by users. There may also be relationships that have been formed on those derived artifacts, in which case referential integrity will prevent them from being deleted, and the update will fail. All in all I am disappointed in myself for implementing the updateContent feature to begin with. > Content update of artifact is not part of audit history > ------------------------------------------------------- > > Key: SRAMP-539 > URL: https://issues.jboss.org/browse/SRAMP-539 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > After updating the content of an artifact audit trail still shows only its creation: > {code} > Artifact Audit Trail (1 entries) > Idx Audit Entry > --- ----------- > 1 artifact:add by 'admin' on Aug 6, 2014 at 2:09:54 PM. > {code} > I suppose that content update is quite important to be part of the audit log, since meta-data update *is* part of the audit log: > {code} > Artifact Audit Trail (2 entries) > Idx Audit Entry > --- ----------- > 1 artifact:update by 'admin' on Aug 6, 2014 at 2:26:16 PM. > 2 artifact:add by 'admin' on Aug 6, 2014 at 2:26:10 PM. > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-539) Content update of artifact is not part of audit history

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-539?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-539: ------------------------------------- While it wouldn't be *too* hard to audit an update, we should really consider removing the content update feature. The spec is a little ambiguous on the topic if I recall correctly. > Content update of artifact is not part of audit history > ------------------------------------------------------- > > Key: SRAMP-539 > URL: https://issues.jboss.org/browse/SRAMP-539 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > After updating the content of an artifact audit trail still shows only its creation: > {code} > Artifact Audit Trail (1 entries) > Idx Audit Entry > --- ----------- > 1 artifact:add by 'admin' on Aug 6, 2014 at 2:09:54 PM. > {code} > I suppose that content update is quite important to be part of the audit log, since meta-data update *is* part of the audit log: > {code} > Artifact Audit Trail (2 entries) > Idx Audit Entry > --- ----------- > 1 artifact:update by 'admin' on Aug 6, 2014 at 2:26:16 PM. > 2 artifact:add by 'admin' on Aug 6, 2014 at 2:26:10 PM. > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-539) Content update of artifact is not part of audit history

by Stefan Bunciak (JIRA)

[ https://issues.jboss.org/browse/SRAMP-539?page=com.atlassian.jira.plugin.... ] Stefan Bunciak commented on SRAMP-539: -------------------------------------- Hi [~brmeyer], via SrampAtomApiClient: {code} BaseArtifactType deployedXml = client.uploadArtifact(ArtifactType.XmlDocument(), new FileInputStream(new File("src/test/resources/sampleDocument.xml")), "audit-sampleDocument.xml"); client.updateArtifactContent(deployedXml, new FileInputStream(new File("src/test/resources/sampleDocument2.xml"))); {code} > Content update of artifact is not part of audit history > ------------------------------------------------------- > > Key: SRAMP-539 > URL: https://issues.jboss.org/browse/SRAMP-539 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > After updating the content of an artifact audit trail still shows only its creation: > {code} > Artifact Audit Trail (1 entries) > Idx Audit Entry > --- ----------- > 1 artifact:add by 'admin' on Aug 6, 2014 at 2:09:54 PM. > {code} > I suppose that content update is quite important to be part of the audit log, since meta-data update *is* part of the audit log: > {code} > Artifact Audit Trail (2 entries) > Idx Audit Entry > --- ----------- > 1 artifact:update by 'admin' on Aug 6, 2014 at 2:26:16 PM. > 2 artifact:add by 'admin' on Aug 6, 2014 at 2:26:10 PM. > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-508: ----------------------------------- See my note on https://github.com/Governance/s-ramp/pull/464. There were some major issues and I had to back out of the merge. > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. > This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. > So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-539) Content update of artifact is not part of audit history

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-539?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-539: ----------------------------------- Hey [~sbunciak], how are you updating the artifact? After SRAMP-507, that should no longer be possible through the Maven Wagon, etc., unless the artifact is a SNAPSHOT > Content update of artifact is not part of audit history > ------------------------------------------------------- > > Key: SRAMP-539 > URL: https://issues.jboss.org/browse/SRAMP-539 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > After updating the content of an artifact audit trail still shows only its creation: > {code} > Artifact Audit Trail (1 entries) > Idx Audit Entry > --- ----------- > 1 artifact:add by 'admin' on Aug 6, 2014 at 2:09:54 PM. > {code} > I suppose that content update is quite important to be part of the audit log, since meta-data update *is* part of the audit log: > {code} > Artifact Audit Trail (2 entries) > Idx Audit Entry > --- ----------- > 1 artifact:update by 'admin' on Aug 6, 2014 at 2:26:16 PM. > 2 artifact:add by 'admin' on Aug 6, 2014 at 2:26:10 PM. > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (OVERLORD-135) Init and Destroy annotations for services created by ServiceRegistry

by Gary Brown (JIRA)

Gary Brown created OVERLORD-135: ----------------------------------- Summary: Init and Destroy annotations for services created by ServiceRegistry Key: OVERLORD-135 URL: https://issues.jboss.org/browse/OVERLORD-135 Project: Overlord Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.7.Final Provide annotations that can be used to tag methods for initialization and close of a service. The methods must return void and take no parameters. If an exception is thrown then it will be logged by the service registry. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-551) Dtgov fuse fabric errors

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/RTGOV-551?page=com.atlassian.jira.plugin.... ] David virgil naranjo closed RTGOV-551. -------------------------------------- Resolution: Rejected > Dtgov fuse fabric errors > ------------------------ > > Key: RTGOV-551 > URL: https://issues.jboss.org/browse/RTGOV-551 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Gary Brown > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-551) Dtgov fuse fabric errors

by David virgil naranjo (JIRA)

David virgil naranjo created RTGOV-551: ------------------------------------------ Summary: Dtgov fuse fabric errors Key: RTGOV-551 URL: https://issues.jboss.org/browse/RTGOV-551 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Gary Brown -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-548) Create maven archetypes for RTGov

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-548?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-548. ------------------------------ Fix Version/s: (was: 2.1.0.Final) Resolution: Done > Create maven archetypes for RTGov > --------------------------------- > > Key: RTGOV-548 > URL: https://issues.jboss.org/browse/RTGOV-548 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > > Create maven archetypes for the RTGov governance artifacts for JEE and OSGi. > The archetypes intended for JEE will create war files, the ones intended for OSGi will create jars. The samples can be used to identify the contents of these wars/jars. > The archetypes will be required to create a basic template for the Event Processor Networks (EPN), Activity Validators (AV), Information Processors (IP) and Active Collection Sources (ACS). Users will then add specific details manually, including details in the relevant json files, and any additional dependencies. > One specific note - when a war is deployed in EAP (and eventually WildFly), it will use the dependency (currently defined in the manifest) on overlord-rtgov.war to obtain its dependencies. When we support other JEE containers, then we may need to ask the user for the specific container and change the created maven project accordingly. > So this work can either create a single archetype which requests details about which artifact is being created, and whether OSGi or JEE, or could be separate archetypes. > I think my preference currently is a single archetype that asks questions to determine what should be created, as this can then easily evolve as changes are required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-548) Create maven archetypes for RTGov

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/RTGOV-548?page=com.atlassian.jira.plugin.... ] David virgil naranjo updated RTGOV-548: --------------------------------------- Git Pull Request: https://github.com/Governance/tools/pull/1 > Create maven archetypes for RTGov > --------------------------------- > > Key: RTGOV-548 > URL: https://issues.jboss.org/browse/RTGOV-548 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.1.0.Final > > > Create maven archetypes for the RTGov governance artifacts for JEE and OSGi. > The archetypes intended for JEE will create war files, the ones intended for OSGi will create jars. The samples can be used to identify the contents of these wars/jars. > The archetypes will be required to create a basic template for the Event Processor Networks (EPN), Activity Validators (AV), Information Processors (IP) and Active Collection Sources (ACS). Users will then add specific details manually, including details in the relevant json files, and any additional dependencies. > One specific note - when a war is deployed in EAP (and eventually WildFly), it will use the dependency (currently defined in the manifest) on overlord-rtgov.war to obtain its dependencies. When we support other JEE containers, then we may need to ask the user for the specific container and change the created maven project accordingly. > So this work can either create a single archetype which requests details about which artifact is being created, and whether OSGi or JEE, or could be separate archetypes. > I think my preference currently is a single archetype that asks questions to determine what should be created, as this can then easily evolve as changes are required. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues August 2014