[jira] Created: (SM-883) MBean registration in Websphere returns different objectName
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.1, 3.0.1 Environment: Windows XP SP1, Ubuntu Linux, Java 1.5 Reporter: Grant McDonald Assigned To: Grant McDonald Fix For: 3.2, incubation 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-728) Validation component / CopyTransformer / SourceTransformer put a non serializable property in the message
[
https://issues.apache.org/activemq/browse/SM-728?page=comments#action_37436 ]
Grant McDonald commented on SM-728:
---
I think this is due to the erroneous use of the sourceTransformer directly in
the transform method in ValidateComponent:
try {
SourceTransformer sourceTransformer = new SourceTransformer();
// this may be a problem
// Only DOMSource and SAXSource are allowed for validating
// See
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/Validator.html#validate(javax.xml.transform.Source,%20javax.xml.transform.Result)
// As we expect a DOMResult as output, we must ensure that the
input is a
// DOMSource
DOMSource src = sourceTransformer.toDOMSource(out.getContent());
doValidation(validator,src,result);
if (errorHandler.hasErrors()) {
Fault fault = exchange.createFault();
// set the schema and source document as properties on the fault
fault.setProperty("org.apache.servicemix.schema", schema);
// remove these prop sets
fault.setProperty("org.apache.servicemix.xml", src);
// remove these prop sets
What occurs here is that the property is set on the Fault message which would
explain why changing the CopyTransformer did not work. If no-one has any
objections I would like to remove both of these properties as I wouldn't think
they ultimately prove very useful.
> Validation component / CopyTransformer / SourceTransformer put a non
> serializable property in the message
> -
>
> Key: SM-728
> URL: https://issues.apache.org/activemq/browse/SM-728
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-core
>Affects Versions: 3.0
> Environment: Windows XP Professional
>Reporter: Eyji
>
> See discussion with Guilaume Nodet on Nabble for ServiceMix User:
> http://www.nabble.com/forum/ViewPost.jtp?post=7093895&framed=y
--
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-736) JcaConsumerProcessor.start() fails after subsequent stop()
[
https://issues.apache.org/activemq/browse/SM-736?page=comments#action_37435 ]
Grant McDonald commented on SM-736:
---
The question is which is the preferred resource adapter the one on the endpoint
or the one on the activation spec?
resourceAdapter = endpoint.getResourceAdapter();
if (resourceAdapter == null) {
resourceAdapter = activationSpec.getResourceAdapter();
if (resourceAdapter == null) {
throw new IllegalArgumentException("resourceAdapter not set");
}
} else if (activationSpec.getResourceAdapter() == null) {
activationSpec.setResourceAdapter(resourceAdapter);
}
resourceAdapter.start(bootstrapContext);
resourceAdapter.endpointActivation(endpointFactory, activationSpec);
In the code you have modified above there is a condition which has side effects:
- the endpoint resource adapter is not null; and
- the activation spec resource adapter is not null
in this case the resource adapter that is started and used in endpoint
activation is the one from the endpoint.
Guillaume: which should have precedence? The one from the endpoint or the one
defined on the activation spec?
> JcaConsumerProcessor.start() fails after subsequent stop()
> --
>
> Key: SM-736
> URL: https://issues.apache.org/activemq/browse/SM-736
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Windows XP, JBoss 4.0.4 GA
>Reporter: Frank Trietsch
> Fix For: 3.1
>
> Attachments: JcaConsumerProcessor.java
>
>
> When a JMS-SU ist stopped and reactivated then the start() method fails with
> the following exception:
> java.lang.IllegalArgumentException: resourceAdapter not set
> at
> org.apache.servicemix.jms.jca.JcaConsumerProcessor.start(JcaConsumerProcessor.java:92)
> This due to a wrong check in the start() method. A fixed version is attached.
> Regards,
> Frank
--
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-744) Request/Response for jms through MessageID/CorrelationID
[ https://issues.apache.org/activemq/browse/SM-744?page=all ] Grant McDonald resolved SM-744. --- Fix Version/s: incubation Resolution: Fixed Assignee: Grant McDonald Author: grantm Date: Mon Nov 13 00:06:18 2006 New Revision: 474184 URL: http://svn.apache.org/viewvc?view=rev&rev=474184 Log: SM-744: added XBean configuration option to jms endpoint to allow for using the JMS request message id as the JMS correlation id. Patch provided by Martin Landua Modified: incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/JmsEndpoint.java incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/jca/JcaConsumerProcessor.java incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingConsumerProcessor.java incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardConsumerProcessor.java > 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 > Assigned To: Grant McDonald >Priority: Minor > Fix For: incubation > > Attachments: servicemix-jms-patch > > > 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] 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_37404 ] Grant McDonald commented on SM-536: --- I thought as much. I'll update it to throw DeploymentException and add in a validate method to the AbstractWsd1Deployer > 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 > 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-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_37401 ]
Grant McDonald commented on SM-536:
---
I was having a look at the patch again and I've got a question.
in the deploy on AbstractXBeanDeployer we have the following code snippet:
if (validate(endpoint)) {
su.addEndpoint(endpoint);
} else {
logger.warn("Endpoint " + endpoint + "has not been
validated");
}
And in the validate method on the AbstractXBeanDeployer we have:
protected boolean validate(Endpoint endpoint) throws DeploymentException {
endpoint.validate();
return true;
}
The problem with this is that when there is a validation error the endpoint
does throw a DeploymentException which means that it exits the deploy method
and we never get the warning message. So was the intent that endpoint
validation errors should always be a warning or should we remove the validate
method and just call endpoint.validate() instead?
> 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
> 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] Assigned: (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 reassigned SM-721: - Assignee: 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 > > the xbean.xml file below is processed via the jbi maven plugin > -- > > http://servicemix.apache.org/jsr181/1.0"; > xmlns:demo="urn:servicemix:soap-binding" > xmlns:test="urn:servicemix:status-test" > xmlns:km="urn:iconnect:km"> > > . > > annotations="jsr181" service="demo:simple-JSR-service" > endpoint="simple-JSR-service-endpoint" /> > annotations="jsr181" endpoint="SM-JSR181-service-endpoint"> > > class="com.company.product.SMServiceHttpImpl"> > > > > > -- > and the resulting jbi.xml is > -- > > http://java.sun.com/xml/ns/jbi"; version="1.0"> >xmlns:ns1="urn:iconnect:km"> > service-name="ns1:simple-JSR-service" > endpoint-name="simple-JSR-service-endpoint"/> > service-name="ns1:SM-JSR181-service" > endpoint-name="SM-JSR181-service-endpoint"/> > > > -- > 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-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=all ] Work on SM-582 started by Grant McDonald. > 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: validation-component.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] Commented: (SM-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
[ https://issues.apache.org/activemq/browse/SM-582?page=comments#action_37089 ] Grant McDonald commented on SM-582: --- No. I will do it tonight. > 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: validation-component.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] Created: (SM-582) Current ErrorHandler implementation used by ValidateComponent is not thread safe
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: validation-component.patch 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] Work started: (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 ] Work on SM-536 started by Grant McDonald. > 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.0 > > 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] Updated: (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 updated SM-536: -- Attachment: SM-536.patch Patch reorganises validations from HttpXBeanDeployer into HttpEndpoint and adds the validation on defaultMep for consumer endpoints into the SoapEndpoint. > 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.0 > > 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] Updated: (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 updated SM-536: -- Patch Info: [Patch Available] added patch > 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.0 > > 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] Assigned: (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 reassigned SM-536: - Assignee: Grant McDonald > 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.0 > > -- 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] Closed: (SM-530) Update of New Validation Component Error Handler to add in a namespace prefix
[ https://issues.apache.org/activemq/browse/SM-530?page=all ] Grant McDonald closed SM-530. - Resolution: Won't Fix Thanks for the feedback :) after looking into it some more I find that I agree with you. The inclusion of prefix definitions on nodes can create other issues with XSL transformation and the XPath issue is more elegantly solved using a PrefixResolver. > Update of New Validation Component Error Handler to add in a namespace prefix > - > > Key: SM-530 > URL: https://issues.apache.org/activemq/browse/SM-530 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-components > Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD >Reporter: Grant McDonald > Attachments: servicemix-components.zip > > Original Estimate: 5 minutes > Remaining Estimate: 5 minutes > > I realised that without a namespace prefix the XML generated by the > MessageAwareErrorHandler will not be accessible via xpath. An example of > this: > http://www.servicemix.org/demo";> > > > > > To retrieve the child elements of the messages node we would need to specify > "//messages/*" but with the namespace declared at the top this will return > nothing. Instead the XML should be: > http://www.servicemix.org/demo"; > xmlns:smdemo="http://www.servicemix.org/demo";> > > > > > and the xpath "//smdemo:messages/* > The provided patch adds this functionality and updates the example.xml test > resource. -- 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-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
[ https://issues.apache.org/activemq/browse/SM-526?page=comments#action_36755 ] Grant McDonald commented on SM-526: --- The patch in the zip file was created using the svn diff command, but I put it in the zip to preserve the path information. I guess the command should have just been issued from the ServiceMix root directory :) I'll do that next time instead. > 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: servicemix-bpe.zip > > 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 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. -- 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] Created: (SM-530) Update of New Validation Component Error Handler to add in a namespace prefix
Update of New Validation Component Error Handler to add in a namespace prefix - Key: SM-530 URL: https://issues.apache.org/activemq/browse/SM-530 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-components.zip I realised that without a namespace prefix the XML generated by the MessageAwareErrorHandler will not be accessible via xpath. An example of this: http://www.servicemix.org/demo";> To retrieve the child elements of the messages node we would need to specify "//messages/*" but with the namespace declared at the top this will return nothing. Instead the XML should be: http://www.servicemix.org/demo"; xmlns:smdemo="http://www.servicemix.org/demo";> and the xpath "//smdemo:messages/* The provided patch adds this functionality and updates the example.xml test resource. -- 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] Created: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
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: servicemix-bpe.zip 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. -- 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] Created: (SM-525) Enhancement to ValidateComponent to implement a complete and flexible error handling scheme for schema validation
Enhancement to ValidateComponent to implement a complete and flexible error handling scheme for schema validation - Key: SM-525 URL: https://issues.apache.org/activemq/browse/SM-525 Project: ServiceMix Issue Type: Improvement Components: servicemix-components Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD Reporter: Grant McDonald Attachments: servicemix-components.zip The purpose of this enchancement was to provide the following: 1) Allow error messages to be captured by the ValidateComponent and sent back as the content of a fault message; 2) Preserve existing functionality; and 3) Provide a framework for extending the functionality It was noted that the existing functionality only dealt with simple case valid or not valid schemas. It was decided to make the standard component more extensible and functional and as such this code is being contributed back to the ServiceMix project. To this end the following changes have been made and are available in the attached zip file: 1) Added MessageAwareErrorHandler interface - this interface extends the org.xml.sax.ErrorHandler interface and adds contracts for determining if the error handler has errors, whether it captures messages from the validator, and what message formats it supports. 2) Refactored CountingErrorHandler to extend from MessageAwareErrorHandler and implement the above mentioned methods 3) Created MessageAggregatingErrorHandler - this class aggregates all warning, error and fatal error messages into an XML format (via CDATA). It provides the ability to set the root document path and namespace via configuration and supports DOMSource, StringSource and String formats for the encapsulated data. 4) modified ValidateComponent - added errorHandler property to facilitate dependency injection, with a default value of CountingErrorHandler to preserve existing functionality. Refactored the handling of validation errors to use the new interfaces. errorHandlers which do not support the capturing of messages will use the previous method of sending the DOMResult back as the fault message content. errorHandlers which do support the capture of messages will send the error message xml back as the fault message content. The src document is now set as a property on the fault message. Additionally, a null pointer check was added to the init on the schemaResource.getURL() method call. A testcase has been added to ValidationTest and the example.xml in the validation test/resources package demonstrates the configuration of this functionality. -- 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] Assigned: (SM-474) Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements
[ https://issues.apache.org/activemq/browse/SM-474?page=all ] Grant McDonald reassigned SM-474: - Assign To: Grant McDonald > Add validation code in for jbi descriptor to enforce the inclusion of > bootstrap classname and classpath elements > > > Key: SM-474 > URL: https://issues.apache.org/activemq/browse/SM-474 > Project: ServiceMix > Type: Improvement > Components: servicemix-core > Versions: incubation > Environment: Ubuntu Linux 5.10, Windows XP SP2 > Reporter: Grant McDonald > Assignee: Grant McDonald > > Original Estimate: 30 minutes > Remaining: 30 minutes > > Installers whose jbi.xml doesn't contain a bootstrap classpath and class name > are invalid as described by the jbi spec and also cause an NPE to be thrown > when the component is installed. Add in a validation on the jbi.xml to this > effect (hint: JbiElementProcessor or for an easier implementation - > DescriptorFactory) -- 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] Closed: (SM-473) jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library type
[ https://issues.apache.org/activemq/browse/SM-473?page=all ] Grant McDonald closed SM-473: - Resolution: Fixed Already fixed in latest trunk > jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library > type > - > > Key: SM-473 > URL: https://issues.apache.org/activemq/browse/SM-473 > Project: ServiceMix > Type: Bug > Components: tooling > Versions: incubation > Environment: Ubuntu Linux 5.10, Windows XP SP2 > Reporter: Grant McDonald > Attachments: components.xml.patch > > Original Estimate: 15 minutes > Remaining: 15 minutes > > The components.xml in the jbi-maven-plugin has a typo for the artifact > handler for the jbi-shared-library. It is actually specced out for the > jbi-service-assembly which is already defined. I have tested this mod and > attached a patch for immediate release. > The attached patch file is for > tooling\jbi-maven-plugin\src\main\resources\META-INF\plexus -- 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-473) jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library type
[ https://issues.apache.org/activemq/browse/SM-473?page=comments#action_36469 ] Grant McDonald commented on SM-473: --- I am closing this as I see it has been fixed in trunk (my copy was 5 days out - so let that be a lesson to me!) > jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library > type > - > > Key: SM-473 > URL: https://issues.apache.org/activemq/browse/SM-473 > Project: ServiceMix > Type: Bug > Components: tooling > Versions: incubation > Environment: Ubuntu Linux 5.10, Windows XP SP2 > Reporter: Grant McDonald > Attachments: components.xml.patch > > Original Estimate: 15 minutes > Remaining: 15 minutes > > The components.xml in the jbi-maven-plugin has a typo for the artifact > handler for the jbi-shared-library. It is actually specced out for the > jbi-service-assembly which is already defined. I have tested this mod and > attached a patch for immediate release. > The attached patch file is for > tooling\jbi-maven-plugin\src\main\resources\META-INF\plexus -- 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] Created: (SM-474) Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements
Add validation code in for jbi descriptor to enforce the inclusion of bootstrap classname and classpath elements Key: SM-474 URL: https://issues.apache.org/activemq/browse/SM-474 Project: ServiceMix Type: Improvement Components: servicemix-core Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Installers whose jbi.xml doesn't contain a bootstrap classpath and class name are invalid as described by the jbi spec and also cause an NPE to be thrown when the component is installed. Add in a validation on the jbi.xml to this effect (hint: JbiElementProcessor or for an easier implementation - DescriptorFactory) -- 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] Created: (SM-473) jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library type
jbi-maven-plugin plexus component descriptor has typo for jbi-shared-library type - Key: SM-473 URL: https://issues.apache.org/activemq/browse/SM-473 Project: ServiceMix Type: Bug Components: tooling Versions: incubation Environment: Ubuntu Linux 5.10, Windows XP SP2 Reporter: Grant McDonald Attachments: components.xml.patch The components.xml in the jbi-maven-plugin has a typo for the artifact handler for the jbi-shared-library. It is actually specced out for the jbi-service-assembly which is already defined. I have tested this mod and attached a patch for immediate release. The attached patch file is for tooling\jbi-maven-plugin\src\main\resources\META-INF\plexus -- 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
