[jira] Commented: (SM-883) MBean registration in Websphere returns different objectName
[ https://issues.apache.org/activemq/browse/SM-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39103 ] Grant McDonald commented on SM-883: --- Please delay it until 3.1.2 unless there is a screaming need for it. I am in the process of testing on WebSphere 6.1 and the patch wasn't seeming to work as advertised so more investigation is needed on my part before I am comfortable that it should be applied as is. MBean registration in Websphere returns different objectName Key: SM-883 URL: https://issues.apache.org/activemq/browse/SM-883 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.0.1, 3.1 Environment: Windows XP SP1, Ubuntu Linux, Java 1.5 Reporter: Grant McDonald Assigned To: Grant McDonald Fix For: 3.1.2, 3.2 Attachments: PatchTo3.0.1.zip, PatchToCurrentVersion.zip, SM-883-MBeanRegistration.patch Original Estimate: 2 hours Remaining Estimate: 2 hours Description courtesy of David Potter: When running serviceMix V3.0 on WebSphere 6.1.0.0 I get the following error after stopping and starting serviceMix from the WebSphere console. ERROR - ContextLoader - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbi' defined in ServletContext resource [/WEB-INF/servicemix.xml]: Invocation of init method failed; nested exception is javax.jbi.JBIException: javax.management.InstanceAlreadyExistsException: org.apache.servicemix:Name=ManagementContext,cell=SD1464Node01Cell,Type=SystemService,ContainerName=ServiceMix,node=SD1464Node01,process=server1 I have traced the error to the fact that when you register an mbean IBM adds additional information to the bean. So when serviceMix regesters the bean org.apache.servicemix:Name=ManagementContext,Type=SystemService,ContainerName=ServiceMix IBM, in the method com.ibm.ws.management.PlatformMBeanServer.registerMBean(PlatformMBeanServer.java:469) , adds the attributes cell=SD1464Node01Cell, node=SD1464Node01,process=server1 These means that when we try to unregister the bean on application shutdown we cannot find it (as we look the been up by name). Solution Ideas: 1) In AsyncBaseLifeCycle.doInit() use queryNames() instead of isRegistered(). Care would need to be taken in unregistering the bean is case the bean is not ours. 2) After a bean is registered, update its name (or the complete bean) with the name of the bean returned by the register operation. (this is preferred) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-883) MBean registration in Websphere returns different objectName
[ https://issues.apache.org/activemq/browse/SM-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38964 ] Grant McDonald commented on SM-883: --- David, When supplying patches can you please supply them in unified diff format from the root of the trunk (preferably using svn diff and aggregated to one patch file) since this makes them much easier to apply in addition to being able to easily see the changes. Thanks, Grant MBean registration in Websphere returns different objectName Key: SM-883 URL: https://issues.apache.org/activemq/browse/SM-883 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Affects Versions: 3.0.1, 3.1 Environment: Windows XP SP1, Ubuntu Linux, Java 1.5 Reporter: Grant McDonald Assigned To: Grant McDonald Fix For: 3.2, incubation Attachments: PatchTo3.0.1.zip, PatchToCurrentVersion.zip Original Estimate: 2 hours Remaining Estimate: 2 hours Description courtesy of David Potter: When running serviceMix V3.0 on WebSphere 6.1.0.0 I get the following error after stopping and starting serviceMix from the WebSphere console. ERROR - ContextLoader - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jbi' defined in ServletContext resource [/WEB-INF/servicemix.xml]: Invocation of init method failed; nested exception is javax.jbi.JBIException: javax.management.InstanceAlreadyExistsException: org.apache.servicemix:Name=ManagementContext,cell=SD1464Node01Cell,Type=SystemService,ContainerName=ServiceMix,node=SD1464Node01,process=server1 I have traced the error to the fact that when you register an mbean IBM adds additional information to the bean. So when serviceMix regesters the bean org.apache.servicemix:Name=ManagementContext,Type=SystemService,ContainerName=ServiceMix IBM, in the method com.ibm.ws.management.PlatformMBeanServer.registerMBean(PlatformMBeanServer.java:469) , adds the attributes cell=SD1464Node01Cell, node=SD1464Node01,process=server1 These means that when we try to unregister the bean on application shutdown we cannot find it (as we look the been up by name). Solution Ideas: 1) In AsyncBaseLifeCycle.doInit() use queryNames() instead of isRegistered(). Care would need to be taken in unregistering the bean is case the bean is not ours. 2) After a bean is registered, update its name (or the complete bean) with the name of the bean returned by the register operation. (this is preferred) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=comments#action_37418 ] Grant McDonald commented on SM-536: --- Author: grantm Date: Sun Nov 12 10:37 2006 GMT+10 New Revision: 473934 URL: http://svn.apache.org/viewvc?view=revrev=473934 Log: SM-536: moved endpoint validation method into AbstractDeployer and changed it to be a void method as the underlying endpoint validation throws a DeploymentException Modified: F:\Grant\Apache\ServiceMix\common\servicemix-common\src\main\java\org\apache\servicemix\common\AbstractDeployer.java Modified: F:\Grant\Apache\ServiceMix\common\servicemix-common\src\main\java\org\apache\servicemix\common\wsdl1\AbstractWsdl1Deployer.java Modified: F:\Grant\Apache\ServiceMix\common\servicemix-common\src\main\java\org\apache\servicemix\common\xbean\AbstractXBeanDeployer.java Modified: F:\Grant\Apache\ServiceMix\common\servicemix-common\src\main\java\org\apache\servicemix\common\xbean\BaseXBeanDeployer.java Modified: F:\Grant\Apache\ServiceMix\deployables\serviceengines\servicemix-bpe\src\main\java\org\apache\servicemix\bpe\BPEDeployer.java Modified: F:\Grant\Apache\ServiceMix\deployables\serviceengines\servicemix-wsn2005\src\main\java\org\apache\servicemix\wsn\component\WSNDeployer.java The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: incubation, 3.1 Attachments: SM-536.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Grant McDonald resolved SM-536. --- Fix Version/s: 3.1 incubation Resolution: Fixed Validation framework pushed into AbstractDeployer. HttpEndpoint fixed as per previous commit. The defaultMep is a mandatory attribute on consumer endpoints and should be checked --- Key: SM-536 URL: https://issues.apache.org/activemq/browse/SM-536 Project: ServiceMix Issue Type: Bug Components: servicemix-http, servicemix-jms Reporter: Guillaume Nodet Assigned To: Grant McDonald Fix For: 3.1, incubation Attachments: SM-536.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-744) Request/Response for jms through MessageID/CorrelationID
[ https://issues.apache.org/activemq/browse/SM-744?page=comments#action_37422 ] Grant McDonald commented on SM-744: --- That clarifies things quite a bit. I can see that in certain circumstances that this would be useful. The only thing to keep in mind is that such configuration is static for the lifetime of the endpoint - but I guess your client isn't going to be expecting it to be any different. I would like to hear what Guillaume has to say about such configuration options and whether it's appropriate or not. Can you please attach a patch of your changes? Request/Response for jms through MessageID/CorrelationID Key: SM-744 URL: https://issues.apache.org/activemq/browse/SM-744 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Environment: All platforms Reporter: Martin Landua Priority: Minor The servicemix-jms component assumes that the request/reponse pattern is implemented by the client by using some artificial correlation id as the connection between the messages (as described in http://activemq.org/site/how-should-i-implement-request-response-with-jms.html). However, there are cases where the client assumes that the server sets the correlation id of the response to the message id (!) of the request. Currently, the servicemix-jms component does not support this, but it would be convenient if it were configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SM-732) Fault-messages cause JbiChannel to throw NullPointerException
[ https://issues.apache.org/activemq/browse/SM-732?page=all ] Work on SM-732 started by Grant McDonald. Fault-messages cause JbiChannel to throw NullPointerException - Key: SM-732 URL: https://issues.apache.org/activemq/browse/SM-732 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Environment: not relevant Reporter: Horst Studer Assigned To: Grant McDonald From a service (jsr181 pojo), I am calling another service (also implemented as a jsr181 pojo), using a jsr181 proxy. This works fine if the called service returns an out message. If, however, the called service throws an exception (i.e. returns a fault), there is a NullPointerException in ...jsr181.xfire.JbiChannel. There are two problems: After the sendSync, there is a check to see if the exchange status is ERROR, and if not, getOutMessage().getContent() is called. The code assumes that after a fault, the exchange status is ERROR, but in fact, it is ACTIVE and the fault-Message is set, while the out-Message is null. So this causes the NullPointerException. The other problem is that the code for handling the fault-Message is missing (marked as // TODO, but as stated above, with the wrong assumption that the exchange status is ERROR). It would be nice, if the fault message would be processed an cause xfire to throw a corresponding exception on the proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-732) Fault-messages cause JbiChannel to throw NullPointerException
[ https://issues.apache.org/activemq/browse/SM-732?page=all ] Grant McDonald resolved SM-732. --- Fix Version/s: 3.1 incubation Resolution: Fixed Author: grantm Date: Sun Nov 12 03:47:00 2006 GMT+10 New Revision: 473875 URL: http://svn.apache.org/viewvc?view=revrev=473875 Log: Issue: SM-732 Description: refactored to test for fault condition and return fault content as string argument to XFireFault Modified: F:\Grant\Apache\ServiceMix\deployables\serviceengines\servicemix-jsr181\src\main\java\org\apache\servicemix\jsr181\xfire\JbiChannel.java Fault-messages cause JbiChannel to throw NullPointerException - Key: SM-732 URL: https://issues.apache.org/activemq/browse/SM-732 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Environment: not relevant Reporter: Horst Studer Assigned To: Grant McDonald Fix For: 3.1, incubation From a service (jsr181 pojo), I am calling another service (also implemented as a jsr181 pojo), using a jsr181 proxy. This works fine if the called service returns an out message. If, however, the called service throws an exception (i.e. returns a fault), there is a NullPointerException in ...jsr181.xfire.JbiChannel. There are two problems: After the sendSync, there is a check to see if the exchange status is ERROR, and if not, getOutMessage().getContent() is called. The code assumes that after a fault, the exchange status is ERROR, but in fact, it is ACTIVE and the fault-Message is set, while the out-Message is null. So this causes the NullPointerException. The other problem is that the code for handling the fault-Message is missing (marked as // TODO, but as stated above, with the wrong assumption that the exchange status is ERROR). It would be nice, if the fault message would be processed an cause xfire to throw a corresponding exception on the proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-744) Request/Response for jms through MessageID/CorrelationID
[ https://issues.apache.org/activemq/browse/SM-744?page=comments#action_37417 ] Grant McDonald commented on SM-744: --- Martin, Could you please expand upon the circumstances/scenarios where this occurs? The only places I found the JMS correlation id being set to the exchange id was in MultiplexingProviderProcessor(161) and StandardProviderProcessor(101) which you would expect from messages coming from the NMR onto JMS and having an InOut MEP. Under what scenario is there an expectation in the client that the JMS correlation id will be a message exchange id? Request/Response for jms through MessageID/CorrelationID Key: SM-744 URL: https://issues.apache.org/activemq/browse/SM-744 Project: ServiceMix Issue Type: Improvement Components: servicemix-jms Environment: All platforms Reporter: Martin Landua Priority: Minor The servicemix-jms component assumes that the request/reponse pattern is implemented by the client by using some artificial correlation id as the connection between the messages (as described in http://activemq.org/site/how-should-i-implement-request-response-with-jms.html). However, there are cases where the client assumes that the server sets the correlation id of the response to the message id (!) of the request. Currently, the servicemix-jms component does not support this, but it would be convenient if it were configurable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-721) maven plugin creates incorrect jbi.xml if multiple name spaces are used
[ https://issues.apache.org/activemq/browse/SM-721?page=all ] Grant McDonald updated SM-721: -- Attachment: SM-721.patch Patch file to fix issue maven plugin creates incorrect jbi.xml if multiple name spaces are used --- Key: SM-721 URL: https://issues.apache.org/activemq/browse/SM-721 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: James Bradt Assigned To: Grant McDonald Priority: Minor Attachments: SM-721.patch the xbean.xml file below is processed via the jbi maven plugin -- ?xml version=1.0? beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0; xmlns:demo=urn:servicemix:soap-binding xmlns:test=urn:servicemix:status-test xmlns:km=urn:iconnect:km classpath location./location /classpath jsr181:endpoint pojoClass=soap.SimpleServiceImpl annotations=jsr181 service=demo:simple-JSR-service endpoint=simple-JSR-service-endpoint / jsr181:endpoint service=km:SM-JSR181-service annotations=jsr181 endpoint=SM-JSR181-service-endpoint jsr181:pojo bean class=com.company.product.SMServiceHttpImpl /bean /jsr181:pojo /jsr181:endpoint /beans -- and the resulting jbi.xml is -- ?xml version=1.0 encoding=UTF-8? jbi xmlns=http://java.sun.com/xml/ns/jbi; version=1.0 services xmlns:ns1=urn:servicemix:soap-binding xmlns:ns1=urn:iconnect:km provides interface-name=ns1:simple-JSR-servicePortType service-name=ns1:simple-JSR-service endpoint-name=simple-JSR-service-endpoint/ provides interface-name=ns1:SM-JSR181-servicePortType service-name=ns1:SM-JSR181-service endpoint-name=SM-JSR181-service-endpoint/ /services /jbi -- The problem is that the namespace 'ns1' is defined twice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SM-721) maven plugin creates incorrect jbi.xml if multiple name spaces are used
[ https://issues.apache.org/activemq/browse/SM-721?page=all ] Work on SM-721 started by Grant McDonald. maven plugin creates incorrect jbi.xml if multiple name spaces are used --- Key: SM-721 URL: https://issues.apache.org/activemq/browse/SM-721 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: James Bradt Assigned To: Grant McDonald Priority: Minor Attachments: SM-721.patch the xbean.xml file below is processed via the jbi maven plugin -- ?xml version=1.0? beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0; xmlns:demo=urn:servicemix:soap-binding xmlns:test=urn:servicemix:status-test xmlns:km=urn:iconnect:km classpath location./location /classpath jsr181:endpoint pojoClass=soap.SimpleServiceImpl annotations=jsr181 service=demo:simple-JSR-service endpoint=simple-JSR-service-endpoint / jsr181:endpoint service=km:SM-JSR181-service annotations=jsr181 endpoint=SM-JSR181-service-endpoint jsr181:pojo bean class=com.company.product.SMServiceHttpImpl /bean /jsr181:pojo /jsr181:endpoint /beans -- and the resulting jbi.xml is -- ?xml version=1.0 encoding=UTF-8? jbi xmlns=http://java.sun.com/xml/ns/jbi; version=1.0 services xmlns:ns1=urn:servicemix:soap-binding xmlns:ns1=urn:iconnect:km provides interface-name=ns1:simple-JSR-servicePortType service-name=ns1:simple-JSR-service endpoint-name=simple-JSR-service-endpoint/ provides interface-name=ns1:SM-JSR181-servicePortType service-name=ns1:SM-JSR181-service endpoint-name=SM-JSR181-service-endpoint/ /services /jbi -- The problem is that the namespace 'ns1' is defined twice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-721) maven plugin creates incorrect jbi.xml if multiple name spaces are used
[ https://issues.apache.org/activemq/browse/SM-721?page=all ] Grant McDonald resolved SM-721. --- Fix Version/s: incubation Resolution: Fixed svn ci tooling\jbi-maven-plugin\src\main\java\org\apache\servicemix\maven\plugin\jbi\AbstractDescr iptorWriter.java -m issue: SM-721, description: added return of updated counter to namespace map construction Sending tooling\jbi-maven-plugin\src\main\java\org\apache\servicemix\maven\plugin\jbi\AbstractDescriptorWriter.java Transmitting file data . Committed revision 472489. The problem was simply the use of a primitive counter variable which was passed to a function which updated it but did not pass it back (local variable stack and all that). maven plugin creates incorrect jbi.xml if multiple name spaces are used --- Key: SM-721 URL: https://issues.apache.org/activemq/browse/SM-721 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: James Bradt Assigned To: Grant McDonald Priority: Minor Fix For: incubation Attachments: SM-721.patch the xbean.xml file below is processed via the jbi maven plugin -- ?xml version=1.0? beans xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0; xmlns:demo=urn:servicemix:soap-binding xmlns:test=urn:servicemix:status-test xmlns:km=urn:iconnect:km classpath location./location /classpath jsr181:endpoint pojoClass=soap.SimpleServiceImpl annotations=jsr181 service=demo:simple-JSR-service endpoint=simple-JSR-service-endpoint / jsr181:endpoint service=km:SM-JSR181-service annotations=jsr181 endpoint=SM-JSR181-service-endpoint jsr181:pojo bean class=com.company.product.SMServiceHttpImpl /bean /jsr181:pojo /jsr181:endpoint /beans -- and the resulting jbi.xml is -- ?xml version=1.0 encoding=UTF-8? jbi xmlns=http://java.sun.com/xml/ns/jbi; version=1.0 services xmlns:ns1=urn:servicemix:soap-binding xmlns:ns1=urn:iconnect:km provides interface-name=ns1:simple-JSR-servicePortType service-name=ns1:simple-JSR-service endpoint-name=simple-JSR-service-endpoint/ provides interface-name=ns1:SM-JSR181-servicePortType service-name=ns1:SM-JSR181-service endpoint-name=SM-JSR181-service-endpoint/ /services /jbi -- The problem is that the namespace 'ns1' is defined twice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=comments#action_37102 ] Grant McDonald commented on SM-582: --- Committed changes. Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\CountingErrorHandlerFactory.java Sending servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAggregatingErrorHandler.java Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAggregatingErrorHandlerFactory.java Adding servicemix-components\src\main\java\org\apache\servicemix\components\validation\MessageAwareErrorHandlerFactory.java Sending servicemix-components\src\main\java\org\apache\servicemix\components\validation\ValidateComponent.java Sending servicemix-components\src\test\resources\org\apache\servicemix\components\validation\example.xml Transmitting file data .. Committed revision 453155. Current ErrorHandler implementation used by ValidateComponent is not thread safe Key: SM-582 URL: https://issues.apache.org/activemq/browse/SM-582 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: incubation Environment: Ubuntu Linux 6.06 LTS, WinXP SP2 Reporter: Grant McDonald Assigned To: Grant McDonald Attachments: SM-582.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Due to the error handler being dependency injected it is a singleton which unfortunately stores state across invocations. The solution is to use the factory pattern, whereby an ErrorHandlerFactory implementation is created as the singleton which has properties containing the arguments to pass to the ErrorHandler when it is instantiated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=all ] Grant McDonald updated SM-582: -- Attachment: SM-582.patch Fixed mixed tabs/spaces in patch Current ErrorHandler implementation used by ValidateComponent is not thread safe Key: SM-582 URL: https://issues.apache.org/activemq/browse/SM-582 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: incubation Environment: Ubuntu Linux 6.06 LTS, WinXP SP2 Reporter: Grant McDonald Assigned To: Grant McDonald Attachments: SM-582.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Due to the error handler being dependency injected it is a singleton which unfortunately stores state across invocations. The solution is to use the factory pattern, whereby an ErrorHandlerFactory implementation is created as the singleton which has properties containing the arguments to pass to the ErrorHandler when it is instantiated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=all ] Grant McDonald updated SM-526: -- Description: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. was: When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DescribedValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has been done, although no test cases have been prepared. Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL - Key: SM-526 URL: https://issues.apache.org/activemq/browse/SM-526 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: JbiInvokeAction.java.patch Original Estimate: 15 minutes Remaining Estimate: 15 minutes When returning output and fault messages an XMLInteractionObject is currently being used to wrap the Document object created from the NormalizedMessage. The use of XMLInteractionObject is deprecated within ODE and due to some not entirely understood code paths this results in Fault messages being wrapped in a CannedFormattableValue which renders the object immutable in BPEL and its data unretrieveable to the JBI world when sent back to ServiceMix. The answer is to use instead DocumentFormattableValue from ODE/BPE to wrap both the output and fault messages of a JBI invoke action. A patch for this has been attached. Testing has confirmed the correctness of the solution works for namespace and non-namespace messages that contain mixed namespace declarations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-511) Problem with schemas' import when there are multiple xsds in many dirs
[ https://issues.apache.org/activemq/browse/SM-511?page=comments#action_36686 ] Grant McDonald commented on SM-511: --- This issue has been fixed for 3.0 (after M3) of ServiceMix. It was due to two things: 1) WSDLFlattener did not utilise the baseURI when parsing schema/wsdl imports. (SM-479) 2) Apache ODE BPE version had not implemented relative import functionality. (ODE-5) The patch for the first issue is in the codebase after the M3 release. The ODE patch has also been accepted in the ODE codebase but ServiceMix is not currently using this version. Problem with schemas' import when there are multiple xsds in many dirs -- Key: SM-511 URL: https://issues.apache.org/activemq/browse/SM-511 Project: ServiceMix Issue Type: Bug Components: servicemix-bpe Affects Versions: 3.0-M2 Environment: Windows XP SP2, java version 1.5.0_05 Reporter: Lukasz Attachments: bpe-demo-sa.zip The problem appears when the wsdl file, that accompanies the bpel file, imports data types' definitions from multiple referenced xsd files that are located in subdirectories relative to 'root' directory of service unit. It is impossible to deploy such a service unit to ServiceMix. In the attachment there is the example of such service unit. Test case is simple, just try to deploy this service and the error messages should be clearly seen in the logs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-480) Transitive dependencies of dependent projects not included in installer lib directory
[ https://issues.apache.org/activemq/browse/SM-480?page=comments#action_36494 ] Grant McDonald commented on SM-480: --- The same issue needs to be addressed in GenerateComponentDescriptorMojo.java as well since this uses the same method for determining dependencies. (line 197 is the culprit here). Transitive dependencies of dependent projects not included in installer lib directory - Key: SM-480 URL: https://issues.apache.org/activemq/browse/SM-480 Project: ServiceMix Type: Bug Components: tooling Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Original Estimate: 2 days Remaining: 2 days Whilst using servicemix I got a NoClassDefFound error from the servicemix-http service engine. It appears that the code in question was throwing a DecoderException which is defined in commons-codec which is a transitive dependency of commons-httpclient. This dependency was not included in the installer lib directory and is obviously quite critical to the running of httpclient. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
