PDA

View Full Version : Adapters on demand



clandestino_bgd
Mar 11th, 2010, 05:05 AM
Hi,

I plan to use SI for different client applications.
Each application has its own set of adapters for example:
APP1 has mail and smpp adapter
APP2 has file and mail adapter
APP3 has mail, smpp and file adapter.

Upon the transformation the message processing is more less the same for each application.
It looks sound to me to have the same integration.xml for all applications,
since transformer supports all inbound types, only by changing method parameter type. No need to say how much I like this feature in SI :)

Now the question is: what would be the best way to turn off existing adapters, if they are not needed?
In other words if I don't want APP1 to poll file system, how I can turn off inbound file adapter either in xml (with some dynamically resolved property value) or in initialisation time inside SpringContextLoaderListener?

Thanks very much for any hint in advance,
Milan

Mark Fisher
Mar 11th, 2010, 09:14 AM
You can provide an "auto-startup" attribute with a value of "false" for an adapter, and then you can programmatically invoke the "start" method for the ones you do want to start.

However, you might want to consider modularizing your configuration files and simply not including the configuration for certain adapters in some of the apps.

oleg.zhurakousky
Mar 11th, 2010, 09:14 AM
I think what you are looking for is PropertyPlaceholderConfigurer


<int-file:inbound-channel-adapter directory="/some/dirr" auto-startup="${auto.start}". . ./>

<context:property-placeholder/>

and then you can either provide a property file to property-placeholder or system property: -Dauto.start=false

clandestino_bgd
Mar 23rd, 2010, 11:59 AM
solved by putting adapters in separate files, as suggested.
They all however produce message into the same "input" channel.
Then in build time, depending on the list of required adapers, copy matched files (by name) into WEB-INF folder.
In general, I am aiming to split adapter configuration files from service context which remains the same for each type of the external message.

works well so far.
best,
milan