September 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

by Michael Clay (JIRA)

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Michael Clay commented on RTGOV-566: ------------------------------------ have you also discussed the possiblity to allow custom messagecomposer and contextmapper on the receiving sca binding side - with this option available all relevant properties can be recreated from the message itself and it would align the sca binding with the other bindings (e.g. soap,jms) in the sense of supported features/options. > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-561) Support Fuse JMS

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved SRAMP-561. ------------------------------- Resolution: Done > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-566: ---------------------------------- If type processors are used to extract the header details using xpath, then this associated bug will be relevant. > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-573?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-573. ------------------------------ Resolution: Done > XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-573 > URL: https://issues.jboss.org/browse/RTGOV-573 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. > Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-573?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-573: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/201 > XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-573 > URL: https://issues.jboss.org/browse/RTGOV-573 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. > Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Gary Brown edited comment on RTGOV-566 at 9/16/14 12:58 PM: ------------------------------------------------------------ Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a configuration property on this transformer (e.g. 'includeHeaders') to enable message content only serialization to also be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' (with includeHeaders=true) is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. was (Author: objectiser): Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a variation (e.g. 'serializeWithHeaders') to enable message content only serialization to be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' or 'serializeWithHeaders' is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-566: ---------------------------------- Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a variation (e.g. 'serializeWithHeaders') to enable message content only serialization to be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' or 'serializeWithHeaders' is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved

by Gary Brown (JIRA)

Gary Brown created RTGOV-573: -------------------------------- Summary: XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved Key: RTGOV-573 URL: https://issues.jboss.org/browse/RTGOV-573 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-566) Remove Fuse from installer and replace with new Karaf commands

by Brett Meyer (JIRA)

Brett Meyer created SRAMP-566: --------------------------------- Summary: Remove Fuse from installer and replace with new Karaf commands Key: SRAMP-566 URL: https://issues.jboss.org/browse/SRAMP-566 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer Rather than continue to support Fuse from within the installer, instead create Karaf command(s) to handle it all. Each project will have at least it's own overlord:[project]:configure. We'll also need to kick off overlord-commons GenerateSamlKeystoreCommand somehow, either by creating a central overlord:commons:configure (not sure that's best) or running it from *all* other projects' configure commands (and ensure it's only run once). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-535: ------------------------------------- Deleted nodes are kept for auditing, yes. The audit information lives as child nodes on the artifact node. So changing the UUI *should* be ok. I would suggest perhaps something like <UUID>_deleted_<timestamp> or something like that. And have same-name-siblings enabled only for the "trash" part of the tree. Definitely do not want to enable same-name-siblings for the main tree, as we use that feature specifically to ensure that we don't create multiple nodes with the same UUID. That was probably obviously but perhaps worth repeating. :) > Reset UUID of artifact when it is deleted > ----------------------------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues September 2014