August 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-540) Replace SwitchYard based s-ramp demos with webapp versions

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-540?page=com.atlassian.jira.plugin.... ] Work on SRAMP-540 started by Brett Meyer. > Replace SwitchYard based s-ramp demos with webapp versions > ---------------------------------------------------------- > > Key: SRAMP-540 > URL: https://issues.jboss.org/browse/SRAMP-540 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > Currently we have two demos in s-ramp that use switchyard. The demos do not *need* to be switchyard-specific, however. For example, the multiapp demo simply demonstrates that the s-ramp wagon can be used to pull maven dependencies directly from the maven repository. This could be done using a simple multi-module web application, which would be much more stable. We would not need to keep it in synch with the version of SwitchYard in FSW. -- 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 resolved SRAMP-508. ------------------------------- Fix Version/s: 0.5.0.Beta4 Resolution: Done > 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 > Fix For: 0.5.0.Beta4 > > > 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-542) If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-542: --------------------------------- Summary: If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it Key: SRAMP-542 URL: https://issues.jboss.org/browse/SRAMP-542 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: David virgil naranjo Priority: Minor Fix For: 0.6.0 Low priority -- we shouldn't consider this until 0.6. DeployCommand is currently assuming a SNAPSHOT artifact includes a timestamp. But, if I'm using the CLI to deploy a locally built artifact, it won't. Consider automatically generating a timestamp if it's missing so that I can upload new snapshots. -- 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)

[ https://issues.jboss.org/browse/OVERLORD-135?page=com.atlassian.jira.plug... ] Gary Brown updated OVERLORD-135: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/100 > 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: Overlord-Commons-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] (SRAMP-541) Consider removing artifact/content updates

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-541?page=com.atlassian.jira.plugin.... ] Brett Meyer updated SRAMP-541: ------------------------------ Fix Version/s: 0.6.0 > Consider removing artifact/content updates > ------------------------------------------ > > Key: SRAMP-541 > URL: https://issues.jboss.org/browse/SRAMP-541 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > From [~eric.wittmann] on SRAMP-539: > {quote} > 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. > {quote} > I also agree that updateContent and artifact updates should probably be removed entirely. It's caused quite a bit of confusion, is only partially implemented, and could cause quite a bit of harm in real-world use cases. -- 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 closed SRAMP-539. ----------------------------- Resolution: Won't Fix > 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 Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-539?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-539: ----------------------------------- Agreed -- see SRAMP-541. [~sbunciak], if you disagree with that for some reason, feel free to discuss it! > 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-541) Consider removing artifact/content updates

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-541: --------------------------------- Summary: Consider removing artifact/content updates Key: SRAMP-541 URL: https://issues.jboss.org/browse/SRAMP-541 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer >From [~eric.wittmann] on SRAMP-539: {quote} 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. {quote} I also agree that updateContent and artifact updates should probably be removed entirely. It's caused quite a bit of confusion, is only partially implemented, and could cause quite a bit of harm in real-world use cases. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-540) Replace SwitchYard based s-ramp demos with webapp versions

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-540: ----------------------------------- Summary: Replace SwitchYard based s-ramp demos with webapp versions Key: SRAMP-540 URL: https://issues.jboss.org/browse/SRAMP-540 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Components: Distro Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0.Beta4 Currently we have two demos in s-ramp that use switchyard. The demos do not *need* to be switchyard-specific, however. For example, the multiapp demo simply demonstrates that the s-ramp wagon can be used to pull maven dependencies directly from the maven repository. This could be done using a simple multi-module web application, which would be much more stable. We would not need to keep it in synch with the version of SwitchYard in FSW. -- 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 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. > 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues August 2014