gnodet wrote: > > > How do you "reconfigure" endpoints ? > Could you do that individually for each endpoint using the > EndpointListener ? > You can intercept all endpoints activation / deactivation. > >
I will study this EndpointListener, in the mean time let me tell you what we did It's a little embarrassing to describe this without a bit more background. This is a big shop in which we have to develop something that (unix) administrators are happy with, and that end-users are happy with. It's a requirement that nodes may be shut down at any moment without the applications being affected. It's also a requirement that (for example) a quartz scheduler be reconfigured with a few clicks on a gui, in (quasi-)real time. I was given the task of evaluating an esb to achieve two particular tasks. I'm not after something immaculate, but rather of good examples of coming up with a set of atomic services that are useful, accessible, and reusable, and interact via message exchange, even if the granularity of services is too fine. So the tasks are: 1) a legacy cics transaction was exposed as a webservice (cics 3.1) and an esb transforms the xml messages into a more convenient format (the wsdl is automatically generated by cics). This is essentially solved, and works very well with servicemix 2) files from an external ftp site are fetched at regular intervals, some processing applied, and then uploaded to the mainframe. The interval, user id, password, directory on the server(s), etc, should be re-configurable by the end-user with minimal or no intervention of developers or administrators. Here we had to come up with our own way of doing it, as it was not obvious whether servicemix offered support for it, out of the box. See my other mail about our issues with the ftp component; this mail is about the configuration bit So, this is what we came up with (not saying we're too proud about it, but it's done to the best of my ability). Let's say the cron expression has to be changed. Originally, it sits in the xbean.xml file: <beans xmlns:quartz="http://servicemix.apache.org/quartz/1.0"; xmlns:foo="http://foo.org/foo";> <quartz:endpoint service="foo:scheduler" endpoint="endpoint" targetService="foo:quartzFilter"> <quartz:trigger> <quartz:cron cronExpression="0 0 * * * ?" /> </quartz:trigger> </quartz:endpoint> </beans> Now imagine six months after this is in production, it's realised that one hour is too long, and thirty minutes is the way to go. User wants to change it, but nobody wants to redeploy the whole thing just to add three bytes to a file. So, we came up with a configuration service, that sits on the bus and accepts the following message: <cfg> <service> <namespaceURI>http://foo.org/foo</namespaceURI> <localPart>scheduler</localPart> </service> <endpoint>endpoint</endpoint> <pre>getTrigger</pre> <field>cronExpression</field> <value>0 0/30 * * * ?</value> </cfg> The configuration endpoint receives this message, (desperately) asks the container to give it a reference to the object (we're using reflection because the object is in another classloader), invokes whatever methods are in the <pre> element, and then calls the setter specified in <field>, with argument <value>. It also saves this request on a table, and replays all requests if the container restarts. Couldn't be more messy, couldn't be more ugly, but works. Please tell me this is wrong and there's a much cleaner way to do it. BTW, before you ask, "quartzFilter" is an eip-filter configured like this: <eip:message-filter service="foo:quartzFilter" endpoint="endpoint"> <eip:target> <eip:exchange-target service="foo:process"/> </eip:target> <eip:filter> <shared:xpath-persistent-predicate xpath="concat(string(/timer/fullname), '::', string(/timer/fireTime))" dataSource="#dataSource"/> </eip:filter> </eip:message-filter> and xpath-persistent-predicate is the one I was referring to, and is at the root of the SM-774 issue ... /** * @org.apache.xbean.XBean element="xpath-persistent-predicate" */ public class XPathPersistentPredicate extends JAXPStringXPathExpression implements Predicate { private static final Log log = LogFactory.getLog(XPathPersistentPredicate.class); public XPathPersistentPredicate() { } public XPathPersistentPredicate(String xpath) throws Exception { super(xpath); } public boolean matches(MessageExchange exchange) { try { NormalizedMessage in = MessageUtil.copyIn(exchange); String match = (String) evaluate(exchange, in); if (doneTable.containsKey(match)) return false; doneTable.save(match); return true; } catch (Exception e) { log.warn("Could not evaluate xpath expression", e); return false; } } DataSource dataSource = null; DBTable doneTable; public DataSource getDataSource() { return dataSource; } public void setDataSource(DataSource dataSource) { this.dataSource = dataSource; doneTable = new DBTable(); ... } } We did it this way to achieve a clustered quartz (couldn't figure out a better way to do it) I also have some comments on the ftp process, but will do this on a separate thread Thanks for yor valuable feedback -- View this message in context: http://www.nabble.com/listeners-in-container-and-MessageExchange-tf2815007s12049.html#a7869290 Sent from the ServiceMix - User mailing list archive at Nabble.com.
