[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:
------------------------------------
hi Gary,
ok i understand thanks for clarification - btw are you aware of the fact that SOAP Header Values are only available as Exchange#context properties during
the pipeline execution since the (incoming)SOAPMessageComposer only extract the first child of the SOAPBody as exctual message Context ie Exchange#message. The reason why i mention this is because i think you dont have access to the complete SOAPMessage (ie. SOAPHeader + SOAPBody) in you transformer.
.this is my understanding of things maybe one of the SY guys could confirm/review this.
> [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, 4 months
[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:
----------------------------------
Hi Michael
Would have to disagree - the property mechanism within the information processor is intended to extract business relevant information that can be used in policies, not to serialize header values, which are really part of the message. Originally I was looking at using this mechanism, as a potential way to implement your requirement on FSW 6.0 without having to apply a patch. but this didn't work out.
So I think the 'serialize' information transformer is the ideal place to handle serialization of not just the mesage payload, but header values aswell.
If header values are stored in properties, then the ip.json configuration is more complex as it must list each header value of interest, as well as potentially define its unserialized representation (e.g. dom). It would also not be clear which properties are header values, and which are actually extracted values intended to support policies.
I've actually implemented the mechanism described above - it simply requires the 'includeHeaders=true' set on the serialize information transformer, and it will resubmit all string and DOM header properties - the DOM properties are returned in the correct format.
Branch: https://github.com/objectiser/rtgov/tree/RTGOV-566
I'll hold off merging until we have had further discussions.
> [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, 4 months
[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:
------------------------------------
- short summary how sy handles SOAP header properties
\\
sy sets the incoming soap header properties in {{ContextMapper#mapFrom}} as message property with a soap header label {{context.setProperty(name, value).addLabels(SOAP_HEADER_LABELS);}}
and retrieves and appends it on the outgoing soap message within {{ContextMapper#mapTo}}
{code:title=ContextMapper.java|borderStyle=solid}
for (Property property : context.getProperties()) {
Object value = property.getValue();
if (value instanceof Node) {
} else if (value instanceof Configuration) {
} else {
String v = value.toString();
if (SOAPHeadersType.XML.equals(_soapHeadersType)) {
try {
Element xmlElement = new ElementPuller().pull(new StringReader(v));
Node xmlNode = soapHeader.getOwnerDocument().importNode(xmlElement, true);
soapHeader.appendChild(xmlNode);
} catch (Throwable t) {
soapHeader.addChildElement(qname).setValue(v);
}
} else {
soapHeader.addChildElement(qname).setValue(v);
}
}
}
{code}
what's also relevant here is the way {{context.getProperties()}} is implemented i.e. ALL exchange and message properties are considered.
{code:title=ContextMapper.java|borderStyle=solid}
@Override
public Set<Property> getProperties() {
Set<Property> properties = new HashSet<Property>();
properties.addAll(getProperties(Scope.EXCHANGE));
properties.addAll(getProperties(Scope.MESSAGE));
return properties;
}
{code}
\\
As already mentioned we are using {{SOAPHeadersType#DOM}} on the incoming and outgoing ContextMapper side and therefore would also expect to receive DOM context property instances from Exchange objects originating from SwitchYardRemotingServlet -> but this is no hard constraint since an application can always override/configure those ContextMappers and add the required behaviour.
\\
\\
- recap of how rtgov passes those context properties to switchyards remoting servlet:
\\
On the rtgov side we are using {{ActivityType#properties}} which could be used to restore the RemoteMessage#context and those properties are string valued since we have to persist them. Therefore we have no way to directly pass/serialize DOM(w3c.Node) property value instance which would be anyway a bad idea since the serialization encoding format is already xml.
\\
\\
- comment on Garys suggestion
\\
What i don't like on this solution is that it breaks the existing separation of concerns between PropertyEvaluators(extract context properties) and InformationTransformers (message content serialization) in a bad way which mixes the two responsibilities i.e. header/property retrieving is spread over two (main)concepts of the informationprocessor which i think makes it harder to understand/maintain.
\\
What about adding an addition resultType (org.w3c.dom.xpath.XPathResult) configuration option to the existing xpath evaluator in the same way as as it is possible with camel Xpath expression's http://camel.apache.org/xpath.html ..of course we still need to serialize the result type into string value.
> [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, 4 months
[JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-488?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated SRAMP-488:
------------------------------
Git Pull Request: https://github.com/Governance/s-ramp/pull/489
> Use the maven-bundle-plugin in WAR projects
> -------------------------------------------
>
> Key: SRAMP-488
> URL: https://issues.jboss.org/browse/SRAMP-488
> Project: S-RAMP
> Issue Type: Task
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Fix For: 0.6.0
>
>
> Right now in our WAR projects we are using the war plugin to configure the manifest for osgi. Instead we should use the bundle plugin.
> Links:
> https://ops4j1.jira.com/wiki/display/paxweb/OSGi-fy+your+WAR
> https://ops4j1.jira.com/wiki/display/ops4j/Getting+the+benefits+of+maven-...
> Here is an example of using it in overlord-commons-idp:
> {code}
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <parent>
> <groupId>org.overlord</groupId>
> <artifactId>overlord-commons</artifactId>
> <version>2.0.3-SNAPSHOT</version>
> </parent>
> <artifactId>overlord-commons-idp</artifactId>
> <packaging>war</packaging>
> <name>Overlord Commons: IDP</name>
> <description>An identity provider using PicketLink SAML.</description>
> <dependencies>
> <!-- Third Party Dependencies -->
> <dependency>
> <groupId>org.picketlink</groupId>
> <artifactId>picketlink-federation</artifactId>
> </dependency>
> <dependency>
> <groupId>org.picketbox</groupId>
> <artifactId>picketbox</artifactId>
> </dependency>
> <dependency>
> <groupId>org.picketlink</groupId>
> <artifactId>picketlink-federation</artifactId>
> </dependency>
> <dependency>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>
> </dependency>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>overlord-commons-auth</artifactId>
> </dependency>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>overlord-commons-auth-jboss7</artifactId>
> </dependency>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>overlord-commons-auth-jetty8</artifactId>
> </dependency>
> <dependency>
> <groupId>${project.groupId}</groupId>
> <artifactId>overlord-commons-auth-tomcat7</artifactId>
> </dependency>
> <!-- Provided Dependencies -->
> <dependency>
> <groupId>org.jboss.spec.javax.servlet</groupId>
> <artifactId>jboss-servlet-api_3.0_spec</artifactId>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>build-helper-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>regex-property</id>
> <goals>
> <goal>regex-property</goal>
> </goals>
> <configuration>
> <name>project.version.osgi</name>
> <value>${project.version}</value>
> <regex>-SNAPSHOT</regex>
> <replacement>.Snapshot</replacement>
> <failIfNoMatch>false</failIfNoMatch>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <!-- <plugin> -->
> <!-- <artifactId>maven-war-plugin</artifactId> -->
> <!-- <configuration> -->
> <!-- <failOnMissingWebXml>false</failOnMissingWebXml> -->
> <!-- <warName>${project.artifactId}</warName> -->
> <!-- <attachClasses>true</attachClasses> -->
> <!-- <classesClassifier>classes</classesClassifier> -->
> <!-- <archive> -->
> <!-- <manifestEntries> -->
> <!-- <Bundle-ManifestVersion>2</Bundle-ManifestVersion> -->
> <!-- <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName> -->
> <!-- <Bundle-Version>${project.version.osgi}</Bundle-Version> -->
> <!-- <Web-ContextPath>/overlord-idp</Web-ContextPath> -->
> <!-- <Webapp-Context>/overlord-idp</Webapp-Context> -->
> <!-- <Import-Package>org.apache.log4j,javax.servlet, javax.servlet.http,javax.security.auth.login,javax.xml.stream,javax.xml.stream.events,javax.xml.namespace,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,javax.xml.parsers,javax.xml.datatype,javax.xml.crypto,javax.xml.crypto.dsig,javax.xml.bind,org.apache.karaf.jaas.boot.principal,org.eclipse.jetty.plus.jaas,org.xml.sax,org.w3c.dom,org.w3c.dom.ls,org.overlord.commons.auth.util,org.picketlink.identity.federation.core.interfaces -->
> <!-- </Import-Package> -->
> <!-- <Bundle-ClassPath>.,WEB-INF/classes,WEB-INF/lib/commons-logging-${version.commons-logging}.jar,WEB-INF/lib/jboss-logging-${version.org.jboss.logging}.jar,WEB-INF/lib/jbossxacml-2.0.8.Final.jar,WEB-INF/lib/picketbox-${picketbox.version}.jar,WEB-INF/lib/picketlink-common-${picketlink.version}.jar,WEB-INF/lib/picketlink-config-${picketlink.version}.jar,WEB-INF/lib/picketlink-federation-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-api-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-impl-${picketlink.version}.jar,WEB-INF/lib/xmlsec-1.5.1.jar -->
> <!-- </Bundle-ClassPath> -->
> <!-- </manifestEntries> -->
> <!-- </archive> -->
> <!-- </configuration> -->
> <!-- </plugin> -->
> <plugin>
> <artifactId>maven-war-plugin</artifactId>
> <configuration>
> <archive>
> <!-- add the generated manifest to the war -->
> <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
> </archive>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <executions>
> <execution>
> <id>bundle-manifest</id>
> <phase>process-classes</phase>
> <goals>
> <goal>manifest</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <failOnMissingWebXml>false</failOnMissingWebXml> -->
> <warName>${project.artifactId}</warName>
> <attachClasses>true</attachClasses>
> <classesClassifier>classes</classesClassifier>
> <instructions>
> <Bundle-ManifestVersion>2</Bundle-ManifestVersion>
> <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
> <Bundle-Version>${project.version.osgi}</Bundle-Version>
> <Web-ContextPath>/overlord-idp</Web-ContextPath>
> <Webapp-Context>/overlord-idp</Webapp-Context>
> <Import-Package>org.apache.log4j,javax.servlet, javax.servlet.http,javax.security.auth.login,javax.xml.stream,javax.xml.stream.events,javax.xml.namespace,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,javax.xml.parsers,javax.xml.datatype,javax.xml.crypto,javax.xml.crypto.dsig,javax.xml.bind,org.apache.karaf.jaas.boot.principal,org.eclipse.jetty.plus.jaas,org.xml.sax,org.w3c.dom,org.w3c.dom.ls,org.overlord.commons.auth.util,org.picketlink.identity.federation.core.interfaces
> </Import-Package>
> <Bundle-ClassPath>.,WEB-INF/classes,WEB-INF/lib/commons-logging-${version.commons-logging}.jar,WEB-INF/lib/jboss-logging-${version.org.jboss.logging}.jar,WEB-INF/lib/jbossxacml-2.0.8.Final.jar,WEB-INF/lib/picketbox-${picketbox.version}.jar,WEB-INF/lib/picketlink-common-${picketlink.version}.jar,WEB-INF/lib/picketlink-config-${picketlink.version}.jar,WEB-INF/lib/picketlink-federation-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-api-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-impl-${picketlink.version}.jar,WEB-INF/lib/xmlsec-1.5.1.jar
> </Bundle-ClassPath>
> </instructions>
> </configuration>
> </plugin>
> </plugins>
> </build>
> </project>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (SRAMP-566) Remove Fuse from installer and replace with new Karaf commands
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-566?page=com.atlassian.jira.plugin.... ]
Work on SRAMP-566 started by Brett Meyer.
-----------------------------------------
> 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, 4 months
[JBoss JIRA] (SRAMP-567) Exception Integration Tests
by David virgil naranjo (JIRA)
David virgil naranjo created SRAMP-567:
------------------------------------------
Summary: Exception Integration Tests
Key: SRAMP-567
URL: https://issues.jboss.org/browse/SRAMP-567
Project: S-RAMP
Issue Type: Bug
Reporter: David virgil naranjo
Assignee: David virgil naranjo
Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.193 sec <<< FAILURE!
testWagonPull(org.overlord.sramp.test.wagon.SrampWagonTest) Time elapsed: 1.402 sec <<< ERROR!
java.lang.NullPointerException: null
at java.lang.String.concat(String.java:1970)
at org.codehaus.plexus.logging.console.ConsoleLogger.log(ConsoleLogger.java:91)
at org.codehaus.plexus.logging.console.ConsoleLogger.error(ConsoleLogger.java:68)
at org.overlord.sramp.wagon.SrampWagon.error(SrampWagon.java:992)
at org.overlord.sramp.wagon.SrampWagon.doGetArtifact(SrampWagon.java:491)
at org.overlord.sramp.wagon.SrampWagon.fillInputData(SrampWagon.java:224)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.overlord.sramp.test.wagon.SrampWagonTest.testWagonPull(SrampWagonTest.java:351)
Running org.overlord.sramp.test.server.atom.services.OntologyResourceTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.866 sec
Running org.overlord.sramp.test.server.atom.services.ServiceDocumentResourceTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec
Running org.overlord.sramp.test.server.atom.services.QueryResourceTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.207 sec
Running org.overlord.sramp.test.server.atom.services.AuditResourceTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.733 sec
Running org.overlord.sramp.test.server.atom.services.BatchResourceTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.549 sec
Running org.overlord.sramp.test.server.atom.services.ArtifactResourceTest
Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.969 sec <<< FAILURE!
testFullPurchaseOrderXSD(org.overlord.sramp.test.server.atom.services.ArtifactResourceTest) Time elapsed: 1.873 sec <<< ERROR!
java.lang.NullPointerException: null
at org.overlord.sramp.common.SrampModelUtils.getCustomProperty(SrampModelUtils.java:97)
at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.verifyEntryUpdated(ArtifactResourceTest.java:736)
at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.testFullPurchaseOrderXSD(ArtifactResourceTest.java:611)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty
by Rob Cernich (JIRA)
[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ]
Rob Cernich commented on RTGOV-566:
-----------------------------------
I agree with Keith. If we need to make adjustments, I think we should be looking at modifying the remote API. As Keith mentioned, the SCA binding is for native communication and, as such, the message, headers, and exchange should be completely configured by the client. If this is not possible today, then I think it's fair to ask for modifications to the remote API (as Keith suggests).
> [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, 4 months
[JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty
by Keith Babo (JIRA)
[ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.... ]
Keith Babo commented on RTGOV-566:
----------------------------------
Support for SCA bindings was introduced to allow a "native" communication path into a SwitchYard application in support of the following use cases:
1) Inter-application communication between SwitchYard services.
2) Remote client access to a SwitchYard service.
These cases are different from a traditional binding in that clients are dealing directly with the SY content and context. For other bindings (e.g. JMS, SOAP), the protocol-specific message needs to be mapped to the SY content and context, which is where a message composer and context mapper come in. If it is not possible to pass something via RemoteInvoker/RemoteMessage today, then we should definitely address that in the remote API and/or the SCA binding itself. My preference would be to avoid adding message composer support since clients should already be dealing with a native interface to SwitchYard.
> [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, 4 months
[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:
----------------------------------
Hi Michael
I'll let Keith comment on that.
In terms of the general mechanism I have described, does this meet your needs?
> [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, 4 months