December 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-625) Support Target#otherAttributes

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-625: --------------------------------- Summary: Support Target#otherAttributes Key: SRAMP-625 URL: https://issues.jboss.org/browse/SRAMP-625 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0 Target is currently mapped directly on the sramp:relationship node type, through the following: {code} - sramp:targetType (string) multiple - sramp:relationshipTarget (weakreference) multiple < 'sramp:baseArtifactType' {code} Instead, that needs pulled out into a separate sramp:target type. Then, also include the following, necessary for Target#otherAttributes: {code} - * (string) - * (string) multiple {code} Add support for storing Target#otherAttributes in the visitors. See Relationship#otherAttributes and SRAMP-622. This needs to wait till 1.0 as it's a breaking change in the CND. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-622) Relationship.getOtherAttributes() should be persisted and queryable

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-622?page=com.atlassian.jira.plugin.... ] Brett Meyer commented on SRAMP-622: ----------------------------------- I might need to hold off on the Target#otherAttributes and follow that up later. Relationship#otherAttributes is easy since it's simply an additional property on the sramp:relationship node type. But, since Target is not currently mapped in its own wrapper node type, working in open-ended attributes will be dirty. I've meant to introduce the wrapper type, but won't be able to until 1.0 (breaking change). > Relationship.getOtherAttributes() should be persisted and queryable > ------------------------------------------------------------------- > > Key: SRAMP-622 > URL: https://issues.jboss.org/browse/SRAMP-622 > Project: S-RAMP > Issue Type: Bug > Components: Persistence > Affects Versions: 0.7.0.Final > Reporter: Lukas Krejci > Assignee: Brett Meyer > Attachments: reproducer.zip > > > The API allows for the relationships to have arbitrary "other" attributes on them. > These attributes don't seem to be persisted. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-517) Support Wildfly

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-517?page=com.atlassian.jira.plugin.... ] Brett Meyer reassigned SRAMP-517: --------------------------------- Assignee: Brett Meyer (was: David virgil naranjo) > Support Wildfly > --------------- > > Key: SRAMP-517 > URL: https://issues.jboss.org/browse/SRAMP-517 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-622) Relationship.getOtherAttributes() should be persisted and queryable

by Lukas Krejci (JIRA)

[ https://issues.jboss.org/browse/SRAMP-622?page=com.atlassian.jira.plugin.... ] Lukas Krejci commented on SRAMP-622: ------------------------------------ Tangentially to this, Target also has "other attributes". Querying using the getRelationshipAttribute or getTargetAttribute makes even more sense in that light. > Relationship.getOtherAttributes() should be persisted and queryable > ------------------------------------------------------------------- > > Key: SRAMP-622 > URL: https://issues.jboss.org/browse/SRAMP-622 > Project: S-RAMP > Issue Type: Bug > Components: Persistence > Affects Versions: 0.7.0.Final > Reporter: Lukas Krejci > Assignee: Brett Meyer > Attachments: reproducer.zip > > > The API allows for the relationships to have arbitrary "other" attributes on them. > These attributes don't seem to be persisted. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-531) Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-531?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved SRAMP-531. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side > --------------------------------------------------------------------------- > > Key: SRAMP-531 > URL: https://issues.jboss.org/browse/SRAMP-531 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > Currently, artifacts are expanded w/ ZipToSrampArchiveRegistry/ZipToSrampArchive in multiple locations client-side. See: > - shell's UploadArtifactCommand and DeployCommand > - ui's ArtifactUploadServlet > - wagon's SrampWagon > - server's Maven facade (MavenRepositoryServiceImpl) > Consider moving the expansion somewhere central and server-side. > If the concern was that it's not spec-compliant, consider moving the expanders out of the atom module and create something isolated. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-580) Server-side autodetection of artifact types

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-580?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved SRAMP-580. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Server-side autodetection of artifact types > ------------------------------------------- > > Key: SRAMP-580 > URL: https://issues.jboss.org/browse/SRAMP-580 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. > Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. > The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. > This should completely replace all other types of client-side logic. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-624) Handle expanded artifacts in updateContent/deleteContent

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-624: --------------------------------- Summary: Handle expanded artifacts in updateContent/deleteContent Key: SRAMP-624 URL: https://issues.jboss.org/browse/SRAMP-624 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer updateContent/deleteContent currently clears out the artifacts derived from the given artifact. What if an archive is updated/deleted? Should all of its expanded artifacts also be removed? -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-627) Separate out governance from rtgov config for KeyCloak

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-627?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-627. ------------------------------ Resolution: Done > Separate out governance from rtgov config for KeyCloak > ------------------------------------------------------ > > Key: RTGOV-627 > URL: https://issues.jboss.org/browse/RTGOV-627 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > Currently there are two XSLT transformations, one used when there is no keycloak installed, and the other to create the config for the governance and rtgov specific details. > To enable rtgov to be installed where keycloak and the governance realm have already been installed, we should separate out the governance realm creation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-627) Separate out governance from rtgov config for KeyCloak

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-627?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-627: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/244 > Separate out governance from rtgov config for KeyCloak > ------------------------------------------------------ > > Key: RTGOV-627 > URL: https://issues.jboss.org/browse/RTGOV-627 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > Currently there are two XSLT transformations, one used when there is no keycloak installed, and the other to create the config for the governance and rtgov specific details. > To enable rtgov to be installed where keycloak and the governance realm have already been installed, we should separate out the governance realm creation. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-623) Expand Java classes if referenced by WSDL, beans.xml, etc.

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-623: --------------------------------- Summary: Expand Java classes if referenced by WSDL, beans.xml, etc. Key: SRAMP-623 URL: https://issues.jboss.org/browse/SRAMP-623 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Currently, Java classes are expanded only if referenced by switchyard.xml. It would also be useful to expand if referenced in other ways: WSDL, beans.xml, etc. Also consider adding a config property that would expand *all* classes, regardless of references (but default to false). -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues December 2014