[jira] Created: (SM-676) In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed
In the instance2 of the ws-notification example, the org.apache.servicemix.tck.ReceiverComponent should be removed -- Key: SM-676 URL: https://issues.apache.org/activemq/browse/SM-676 Project: ServiceMix Issue Type: Bug Components: servicemix-assembly Affects Versions: 3.0 Reporter: Guillaume Nodet Priority: Trivial Fix For: 3.0.1, 3.1 -- 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] Created: (SM-678) Jsr181Component not using SU classloader to load service interface
Jsr181Component not using SU classloader to load service interface -- Key: SM-678 URL: https://issues.apache.org/activemq/browse/SM-678 Project: ServiceMix Issue Type: Bug Components: servicemix-jsr181 Affects Versions: 3.0 Reporter: Ken Berthelot When deploying a jsr181endpoint using the serviceInterface attribute, a ClassNotFoundException is generated for the java interface class specified for the attribute. -- 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
Declarative Exception Handling in ServiceMix
Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Problem with servicemix-lwcontainer-3.0
We have recently been updating form servicemix-3.0-M2 to servciemix-3.0. I encountered a problem with the lwcontainer with one of my components. This component has several service units that comprise the service assembly. Two of these service units requrie jars at runtime, which I included in their servicemix.xml to add them to the classpath. Once I run my test I get NoClassDefFound errors. I got around this by adding those jars to my lib/optional directory. The odd thing is we have developed several other components that require jars at runtime and none of those other components had problems. One of the other developers here tried deploying the component with the servicemix-lwcontainer-3.0-M2 version and everything worked fine. Any thoughts on why a service assembly with multiple service units would have problems adding jars to the classpathe with the servicemix-lwcontainer-3.0 component. Thanks -- View this message in context: http://www.nabble.com/Problem-with-servicemix-lwcontainer-3.0-tf2388377.html#a6658350 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Sounds good. Nice work ! A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? If you want to donate this code, feel free to raise a JIRA issue and attach the code. I think it would be a nice addition. On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: Ralf Wunsch wrote: We are starting a new EAI project. At this time ServiceMix is our choice for the implementation plattform. We have strong requirements for monitoring and control issues. At this one aspect is the handling of unexpected errors. For this reason i have implemented the following error handler solution. The error handling solution delegates errors or faults detected in analysis of the MessageExchange objects to an ErrorHandler implemented as XBean. This bean is used by an ErrorHandlerComponent (a JBI component embedded in the flow) or by the JBIContainer (the centralized way) or both. http://www.nabble.com/file/290/error-handler-embedding.png The ErrorHandler can cancel transactions and stop the container or the source component (all cofigurable). Furthermore it's possible to route the error or fault messages and the actuating message to a configurable target. In this case ist possible to embed one or more ErrorHandlerComponents into the flow. http://www.nabble.com/file/291/error-handler-flow.png Such an ambedded ErrorHandlerComponent borrowed by the EIP WireTap ensures that the rerouted message from the source will be in a well know format (the centralised approach can't accomplish this). The embedded and the centralized approach can be used in combination. For synchronization the ErrorHandlerComponent sets a Property on the outgoing MessageExchange and the ErrorEventListener does nothing as long as this property can be found in the MessageEchange which signals a fault or an error. A sample configuration... lt;bean id=errorHandler class=de.eval.eai.error.DefaultErrorHandlergt; lt;/beangt; ... lt;bean id=errorHandlerConfig class=de.eval.eai.error.ErrorHandlerConfiggt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/beangt; ... lt;test:container id=jbi useMBeanServer=true createMBeanServer=false dumpStats=true statsInterval=10 errorHandler=#errorHandler errorHandlerConfig=#errorHandlerConfiggt; ... lt;sm:activationSpecsgt; ... lt;sm:activationSpec componentName=errorHandlergt; lt;sm:componentgt; lt;eai:componentgt; lt;eai:endpointsgt; lt;eai:errorHandler service=errorHandler endpoint=endpointgt; lt;eai:targetgt; lt;eai:exchange-target service=transformer /gt; lt;/eai:targetgt; lt;eai:disqualifyTargetgt; lt;eai:exchange-target service=failedQueue /gt; lt;/eai:disqualifyTargetgt; lt;eai:errorTargetgt; lt;eai:exchange-target service=errorQueue /gt; lt;/eai:errorTargetgt; lt;eai:faultTargetgt; lt;eai:exchange-target service=faultQueue /gt; lt;/eai:faultTargetgt; lt;property name=shutdownOnFault value=true /gt; lt;property name=rollbackOnFault value=false /gt; lt;/eai:errorHandlergt; lt;/eai:endpointsgt; lt;/eai:componentgt; lt;/sm:componentgt; lt;/sm:activationSpecgt; ... Two questions: Ist this a accurate ServieMix way (in accordance with the ideas of ServiceMix)? Is it on behalf of the project or the communitiy to reuse this solution? Thanks, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6658179 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
out-of-the-box experience very limited
Hej! I just discovered that installing the binary distribution like described in the http://goopen.org/confluence/display/SM30UG/3.+Installation#3.Installation-WindowsBinaryInstallation User's Guide / installation presents errors even for the simplest configurations (at least with the default machine settings in our depatment = maybe something additional (classpath,...) has to be set up?). It's just missing packages, so nothing really bad, but not a nice out-of-the-box-experience -- first having to search for information (that was't available till some minutes ago) and to try around. Two files to demonstrate what I mean: http://www.nabble.com/file/292/Timer2Screen.xml Timer2Screen.xml is generated by CIMERO and connects a timer with a screen output. Does not run, a user has to install servicemix-components-3.0-incubating.jar and quartz-1.5.2.jar manually. http://www.nabble.com/file/293/Timer2WireTap2File_and_Screen.xml Timer2WireTap2File_and_Screen.xml adds a wire tap a file writer to the above config. Requires to install servicemix-eip-3.0-incubating.jar manually. Though quartz is not any more in the examples, it is for sure piece of a lot of try out configs, and EIP is certainly very common to use and it's use encouraged by us. Is there any way to include at least ServiceMix' sub-projects into the libs-dir / classpath, so it at least our own components simply work out of the box? Georg -- View this message in context: http://www.nabble.com/out-of-the-box-experience-very-limited-tf2389329.html#a6661175 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
On 10/5/06, Ralf Wunsch [EMAIL PROTECTED] wrote: gnodet wrote: A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? * If i have more than one ErrorHandlerComponent in the flow it should be possible to use one ErrorHandler with different configurations for each ErrorHandlerComponent (e.g. to specify different targets for different types of failed messages). To provide this the configuration for the ErrorHandler has been extracted and assembled in the ErrorHandlerConfig XBean. * In my opinion the error handler hook and the handlers strategy should be separated. I am involved in a migration project (from a commercial EAI solution to open source). In the current EAI system an error handler is always implemented. We want to migrate this solution that is based on a set of database stored rules. I think there can be a lot of error handler strategy implementations. One default handler can be an implementation as discussed before. * At this time i am using my own extension of the JBIContainer. This extension registeres an ErrorEventListener as EventListener by default. I have not found a way to configure event listeners in the deployment descriptor. The ErrorHandler is a attribute of the extended container (the getter/setter methods are using the ErrorEventListerners 'errorHandler' attribute). Have you tried something like: sm:container id=jbi embedded=true sm:listeners bean class= / /sm:listeners It works. Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a6661952 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Looking for servicemix samples using a specific component ?
Try http://google.com/codesearch?hl=enlr=q=file%3A.xml+TraceComponent+package%3A%22http%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fincubator%2Fservicemix%2Ftrunk%22btnG=Search It's a lot faster than looking on your hard drive (at least for me). -- Cheers, Guillaume Nodet
