June 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List

by David virgil naranjo (JIRA)

David virgil naranjo created SRAMP-481: ------------------------------------------ Summary: Maven View in S-ramp UI Artifact List Key: SRAMP-481 URL: https://issues.jboss.org/browse/SRAMP-481 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Eric Wittmann Attachments: s-ramp-artifacts.jpeg The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. If maven view is selected then there would be displayed the artifacts as a maven tree. It would improve the usability, and will be more user friendly. Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List

by David virgil naranjo (JIRA)

[ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.... ] David virgil naranjo updated SRAMP-481: --------------------------------------- Attachment: s-ramp-artifacts.jpeg > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-484) Re-introduce REST services in Karaf when SSO sorted out

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-484?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-484. ------------------------------ Resolution: Done > Re-introduce REST services in Karaf when SSO sorted out > ------------------------------------------------------- > > Key: RTGOV-484 > URL: https://issues.jboss.org/browse/RTGOV-484 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently the war with the REST services has been removed from the karaf features until SSO is configured in RTGov. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-484) Re-introduce REST services in Karaf when SSO sorted out

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-484?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-484: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/128 > Re-introduce REST services in Karaf when SSO sorted out > ------------------------------------------------------- > > Key: RTGOV-484 > URL: https://issues.jboss.org/browse/RTGOV-484 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently the war with the REST services has been removed from the karaf features until SSO is configured in RTGov. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on RTGOV-329: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1056449|https://bugzilla.redhat.com/show_bug.cgi?id=1056449] from NEW to CLOSED > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Jiri Pechanec (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Jiri Pechanec closed RTGOV-329. ------------------------------- Resolution: Done > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-329: ---------------------------------- No problem - can this issue be closed? > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Jiri Pechanec (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- I am sorry, I did not check imports and immediately projected @Singleton as being javax.ejb.Singleton not javax.inject.Singleton. Then all my comments are of course invalid > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-383) Use Declarative Services instead of Blueprint

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-383?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-383: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Use Declarative Services instead of Blueprint > --------------------------------------------- > > Key: RTGOV-383 > URL: https://issues.jboss.org/browse/RTGOV-383 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > If time permits, explore moving to Declarative Services (DS) in place of using Blueprint, for dependency injection and property initialisation, as it may have benefit when using with Fabric (see https://mojo.redhat.com/docs/DOC-14757). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-329: ---------------------------------- But the ActivityServerLogger is not an EJB. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2014