Re: Scheduling 3.2 release
Any word on the release? -jeff gnodet wrote: I'm going through the remaining JIRA assigned for 3.2. If anybody has any important issues to schedule there (or patches to apply), please yell ! I'd like to put 3.2 in release mode asap. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/Scheduling-3.2-release-tf4528728s12049.html#a13234751 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Basic TCP component
Hmmm. ok, likelyhood of options 2 and 3??? For my company we can use the lgpl licensed one, but I'd like this to be out of the box for servicemix, at least a basic version to begin with... -jeff gnodet wrote: AFAIK, the one provided by Spagic is LGPL and unless they plan to change its license we can't really use it in ServiceMix. So there are 3 possibilities: * you don't care about LGPL, so just use it * the component is relicensed under AL * the component is contributed to ServiceMix (which implies it is relicensed) * or you start a new one :-( On 10/9/07, jpuro [EMAIL PROTECTED] wrote: So, what to do about a TCP component? :) -jeff gnodet wrote: On 10/9/07, Andrea Zoppello [EMAIL PROTECTED] wrote: Hi Guillaume, If you take a look at the document How to cook your spagic you could find all the information, on the patches, enhnacements that we've made on servicemix. Actually spagic is based on smx 3.1.1 codebase. By the way our approach is to keep the patches that we've done in spagic until they're taken bu smx codebase. Most of the bug you are talking about have been already fixed afaik (SM-781, SM-924, SM-879). One is still pending in an unknown state (SM-888). You have raised another one recently about the split aggregator which has been included too (not released yet). But I agree some have not been relesed yet :-( In future versions of spagic the patches that we've update to JIRA will not be there anymore, because it will be included directly in smx :-) Cool, I think that's the way to go too. Hopefully we will be able to have shorter release cycles now. By the way have you seen my post about the needing for Merge components in front of a Drools or Content Based router?? Andrea Zoppello Guillaume Nodet ha scritto: Andrea, I've just downloaded the source zip of the components and it seems that there is lots of components coming from ServiceMix: are these differents in some sort ? Bug fixes, enhancements ? If so what about raising JIRAs and attaching your patches ? I know you have already done so and iirc i have applied them ... On 10/9/07, Andrea Zoppello [EMAIL PROTECTED] wrote: Hi Bruce, You can take a look at: http://forge.objectweb.org/projects/spagic In the project site you could find the source code. By the way some information the spagic TCP component is based on apache mina. Andrea Zoppello Bruce Snyder ha scritto: On 10/8/07, jpuro [EMAIL PROTECTED] wrote: Yup, that makes sense. But after looking at spagic it seems that they already use mina in a similar fashion and handle a lot of other requirements for tcp/ip etc. Take a look at their source code and let me know what you think. Otherwise I'll just implement my own version on apache mina as I have seen camel-mina do. Please provide a URL to the source of the code you're looking at. Bruce -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/Re%3A-Basic-TCP-component-tf4592566s12049.html#a13117891 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/Re%3A-Basic-TCP-component-tf4592566s12049.html#a13136109 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
ServiceMix 3.2?
When is the planned release of this? Thanks, Jeff -- View this message in context: http://www.nabble.com/ServiceMix-3.2--tf4490048s12049.html#a12805483 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: ServiceMix 3.2?
I can probably devote a little time testing in the next week or so. Although extremely busy with a project I'm working on. I'll start taking a look at it this weekend. -jeff gnodet wrote: In the coming weeks, just after releasing 3.1.2. Let's plan for first half of october or sooner if possible. Wanna help a bit and already test the examples and distribution ? On 9/20/07, jpuro [EMAIL PROTECTED] wrote: When is the planned release of this? Thanks, Jeff -- View this message in context: http://www.nabble.com/ServiceMix-3.2--tf4490048s12049.html#a12805483 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/ServiceMix-3.2--tf4490048s12049.html#a12810650 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Possible bug in SU shared library loading
It looks like there's a bug in the block of code that loads the shared
library library tags in the ClassLoaderXmlPreprocessor class. The block
of code I'm looking at starts on line 172 and appears to reference the
collection for locations and not libraries:
// Add shared libraries
ListString sls = new ArrayListString();
NodeList libraries =
classpathElement.getElementsByTagName(library);
for (int i = 0; i libraries.getLength(); i++) {
Element locationElement = (Element) locations.item(i);
String library = ((Text)
locationElement.getFirstChild()).getData().trim();
sls.add(library);
}
if (sls.size() 0 container == null) {
throw new IllegalStateException(Can not reference shared
libraries if the component is not deployed in ServiceMix);
}
-jeff
--
View this message in context:
http://www.nabble.com/Possible-bug-in-SU-shared-library-loading-tf3841041s12049.html#a10875885
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Release ServiceMix 3.1.1
Have you taken a look at SM-841, I'm still concerned about this defect... There is a patch attached to it, but not sure if it's the right way of doing things. Regards, Jeff gnodet wrote: I think it's time to release a bug fix version of ServiceMix. I will try to work on that this week, but any help is welcomed in testing the archetypes, samples and the container / components of course. -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/-DISCUSS--Release-ServiceMix-3.1.1-tf3666465s12049.html#a10244622 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Ehcache Standard JBI Component
I am planning on creating a standard JBI component for ehcache so that one can easily deploy ehcache endpoints into ServiceMix and other JBI compliant containers. Here are some high level requirements that I think would be useful for this component. Please respond to this thread with any comments are concerns. 1) There should be a way to configure endpoints that when deployed create actual Caches. The endpoints should be able to have expressions associated with them that can determine how the Cache matches information based off of the Normalized Message. So for example, if you have properties that need to be a part of your key in the cache then you can use an expression to match that. If there is an XPath expression that needs to be matched, this can also be used. 2) I'm still not sure whether it makes sense to allow for a SU to configure the CacheManager itself using the ehcache.xml configuration file. The benefit of this is that you leave the component to just worrying about configuration files and not starting up any cachemanagers itself. You will also be able to create specialized cachemanager's with their associated information on the fly. I could see this as being beneficial. However, perhaps it's better to leave the Ehcache configuration specific to the component itself. That is to say that when you deploy the component it loads up its already packaged ehcache.xml file which configures the CacheManager. If someone needs a different configuration they will have to edit the one packaged with the component or go to JMX and update the values stored there. Regards, Jeff -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Ehcache Standard JBI Component
I hear you on the configuration item. Yes, it would definately be useful to allow a SU to provide its own ehcache.xml within it. Perhaps we do something where you can specify an ehcache:configuration/ element that will let you provide an ehcache.xml file location, which will bind all of the endpoints within the SU to the CacheManager that gets created/configured by that ehcache.xml file. If you do not provide this configuration element then it will default to whatever CacheManager is already configured for the component itself. This would allow a lot of flexibility with integrations that get created and that have specialized caching requirements. So your SU may look something like: beans xmlns:ehcache=http://servicemix.apache.org/ehcache/1.0; ehcache:configuration location=/META-INF/ehcache.xml/ ehcache:endpoint service=ehcache:MyCache1 cacheName=MyCache1 keyExpression=#expression1/ ehcache:endpoint service=ehcache:MyCache2 cacheName=MyCache2 keyExpression=#expression2/ /beans Regards, -Jeff bsnyder wrote: On 12/3/06, jpuro [EMAIL PROTECTED] wrote: I am planning on creating a standard JBI component for ehcache so that one can easily deploy ehcache endpoints into ServiceMix and other JBI compliant containers. Here are some high level requirements that I think would be useful for this component. Please respond to this thread with any comments are concerns. Great idea! 1) There should be a way to configure endpoints that when deployed create actual Caches. The endpoints should be able to have expressions associated with them that can determine how the Cache matches information based off of the Normalized Message. So for example, if you have properties that need to be a part of your key in the cache then you can use an expression to match that. If there is an XPath expression that needs to be matched, this can also be used. Interesting idea. 2) I'm still not sure whether it makes sense to allow for a SU to configure the CacheManager itself using the ehcache.xml configuration file. The benefit of this is that you leave the component to just worrying about configuration files and not starting up any cachemanagers itself. You will also be able to create specialized cachemanager's with their associated information on the fly. I could see this as being beneficial. However, perhaps it's better to leave the Ehcache configuration specific to the component itself. That is to say that when you deploy the component it loads up its already packaged ehcache.xml file which configures the CacheManager. If someone needs a different configuration they will have to edit the one packaged with the component or go to JMX and update the values stored there. I think the configuration is pretty critical. Obviously there needs to be a default configuration, but allowing users to change that configuration or offer a completely different configuration both need to be top priorities. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/ -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7670741 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
Where are you on this component? Do you plan on donating the code to the ServiceMix project? I also have a use for such a component, but haven't developed one yet. Regards, Jeff Ralf Wunsch 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). Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a7019056 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: Declarative Exception Handling in ServiceMix
So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level. -Jeff jpuro wrote: I hear these arguments. My use case may not have been the best example, but I have run into many other situations where the business requires that we handle runtime exceptions more gracefully and allow for smarter routing. Perhaps just adding a new EIP pattern that specifically can handle exceptions would do the trick. -Jeff Philip Dodds-2 wrote: I Agree that I'm not sure you should build in exception routing when it is better placed as another component that handles the Call and return of an exception. It would seem that when building up services you should be handling exceptions and returning faults/exceptions in a clean fashion and that the routing of exceptions is better placed since I can see there becoming increasing details rquired for the routing. Just thinking of a SQLException and then needing the sqlCode in order to determine the meaning of the exception before routing. Philip On 8/25/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess that if you want to handle exceptions in a JBI compliant way, you should put in the flow some specific components to do that. First, we need to make a distinction between faults and errors. Imho, faults are unrecoverable problems, due to the message itself. Errors are runtime problems, which may be able to be solved at a later time. In your example, depending on the reason why the data could not be stored in the database, the component should return a fault (if the data is corrupted) or an error (the database is down). In your use case, the error should be catched by a simple component (an EIP pattern) between the http component and the business component which would act as a normal proxy when no errors are reported, and redirect the flow elsewhere when an error occurs. Also, I don't really understand the friendly error concept ;) The http component is not designed to be a jsp server, so you won't have any nice interface there. The output should be an xml. If you want a nice interface, you should deploy a web app which would call the jbi bus and return a nice html page when an error occurs. Last, while I think declarative transactions may be really useful for POJO based components (servicemix-jsr181, or the yet to be defined new component, see other threads on the list), it would be difficult to apply it in a real JBI world. Let's discuss it, it' s just my thoughts. On 8/25/06, jpuro [EMAIL PROTECTED] wrote: I think it would be useful to add declarative exception handling to ServiceMix. The usefullness of such a feature can be seen from the following simple use case involving a client submitting an order to a fulfillment company: 1) The use case starts when the client sends an order to an HTTP endpoint exposed in ServiceMix. The message representing the order is routed to a business service component. 2) The business service component attempts to process the Order and save it to a database. However, an exception occurs during this process and gets bubbled up. The fulfillment company would like to be notified via email when an order fails to be processed. Since we have configured the business service component to pass all exceptions to an email component, the flow moves to step 3. 3) The email component sends out an email notification to the fulfillment company indicating that an error occurred while processing the order. 4) After the email has been sent out, the flow moves to another component that returns a more user friendly error message to the original HTTP endpoint. This way we do not send back a hard to read error message to the client. The purpose of such a flow is that we handle exceptions more gracefully than currently is supported by ServiceMix. Instead of bubbling up exceptions to the calling component, we should allow components to change the flow of a message when an exception occurs. The configuration could look something like the following: activationSpec componentName=businessServiceComponent service=example:businessService exceptionDestionationService=example:emailService sm:component bean class= com.mycompany.MyClass / /sm:component /activationSpec Alternatively, perhaps we can just use AOP to catch exceptions that occur within a component: sm:exceptionHandler
Re: Declarative Exception Handling in ServiceMix
I hear these arguments. My use case may not have been the best example, but I have run into many other situations where the business requires that we handle runtime exceptions more gracefully and allow for smarter routing. Perhaps just adding a new EIP pattern that specifically can handle exceptions would do the trick. -Jeff Philip Dodds-2 wrote: I Agree that I'm not sure you should build in exception routing when it is better placed as another component that handles the Call and return of an exception. It would seem that when building up services you should be handling exceptions and returning faults/exceptions in a clean fashion and that the routing of exceptions is better placed since I can see there becoming increasing details rquired for the routing. Just thinking of a SQLException and then needing the sqlCode in order to determine the meaning of the exception before routing. Philip On 8/25/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I guess that if you want to handle exceptions in a JBI compliant way, you should put in the flow some specific components to do that. First, we need to make a distinction between faults and errors. Imho, faults are unrecoverable problems, due to the message itself. Errors are runtime problems, which may be able to be solved at a later time. In your example, depending on the reason why the data could not be stored in the database, the component should return a fault (if the data is corrupted) or an error (the database is down). In your use case, the error should be catched by a simple component (an EIP pattern) between the http component and the business component which would act as a normal proxy when no errors are reported, and redirect the flow elsewhere when an error occurs. Also, I don't really understand the friendly error concept ;) The http component is not designed to be a jsp server, so you won't have any nice interface there. The output should be an xml. If you want a nice interface, you should deploy a web app which would call the jbi bus and return a nice html page when an error occurs. Last, while I think declarative transactions may be really useful for POJO based components (servicemix-jsr181, or the yet to be defined new component, see other threads on the list), it would be difficult to apply it in a real JBI world. Let's discuss it, it' s just my thoughts. On 8/25/06, jpuro [EMAIL PROTECTED] wrote: I think it would be useful to add declarative exception handling to ServiceMix. The usefullness of such a feature can be seen from the following simple use case involving a client submitting an order to a fulfillment company: 1) The use case starts when the client sends an order to an HTTP endpoint exposed in ServiceMix. The message representing the order is routed to a business service component. 2) The business service component attempts to process the Order and save it to a database. However, an exception occurs during this process and gets bubbled up. The fulfillment company would like to be notified via email when an order fails to be processed. Since we have configured the business service component to pass all exceptions to an email component, the flow moves to step 3. 3) The email component sends out an email notification to the fulfillment company indicating that an error occurred while processing the order. 4) After the email has been sent out, the flow moves to another component that returns a more user friendly error message to the original HTTP endpoint. This way we do not send back a hard to read error message to the client. The purpose of such a flow is that we handle exceptions more gracefully than currently is supported by ServiceMix. Instead of bubbling up exceptions to the calling component, we should allow components to change the flow of a message when an exception occurs. The configuration could look something like the following: activationSpec componentName=businessServiceComponent service=example:businessService exceptionDestionationService=example:emailService sm:component bean class= com.mycompany.MyClass / /sm:component /activationSpec Alternatively, perhaps we can just use AOP to catch exceptions that occur within a component: sm:exceptionHandler exceptionType=javax.jbi.messaging.MessagingException destinationService=example:emailService activationSpec componentName=businessServiceComponent service=example:businessService sm:component bean class= com.mycompany.MyClass/ /sm:component
Declarative Exception Handling in ServiceMix
I think it would be useful to add declarative exception handling to ServiceMix. The usefullness of such a feature can be seen from the following simple use case involving a client submitting an order to a fulfillment company: 1) The use case starts when the client sends an order to an HTTP endpoint exposed in ServiceMix. The message representing the order is routed to a business service component. 2) The business service component attempts to process the Order and save it to a database. However, an exception occurs during this process and gets bubbled up. The fulfillment company would like to be notified via email when an order fails to be processed. Since we have configured the business service component to pass all exceptions to an email component, the flow moves to step 3. 3) The email component sends out an email notification to the fulfillment company indicating that an error occurred while processing the order. 4) After the email has been sent out, the flow moves to another component that returns a more user friendly error message to the original HTTP endpoint. This way we do not send back a hard to read error message to the client. The purpose of such a flow is that we handle exceptions more gracefully than currently is supported by ServiceMix. Instead of bubbling up exceptions to the calling component, we should allow components to change the flow of a message when an exception occurs. The configuration could look something like the following: activationSpec componentName=businessServiceComponent service=example:businessService exceptionDestionationService=example:emailService sm:component bean class=com.mycompany.MyClass/ /sm:component /activationSpec Alternatively, perhaps we can just use AOP to catch exceptions that occur within a component: sm:exceptionHandler exceptionType=javax.jbi.messaging.MessagingException destinationService=example:emailService activationSpec componentName=businessServiceComponent service=example:businessService sm:component bean class=com.mycompany.MyClass/ /sm:component /activationSpec /sm:exceptionHandler Here are a few concerns of mine: 1) The problem with the first example configuration is that it doesn't allow you to get creative with how certain types of exceptions are handled, it just acts like a catch all. We may need to create a more flexible way of configuring exception handling. 2) Because of the way JBI service units/assemblies are packaged and deployed, would this work? Is there any discussion on declaratively handling exceptions in the JBI spec? Regards, Jeff -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a5974450 Sent from the ServiceMix - Dev forum at Nabble.com.
