File inbound adapters & accidental <poller/> element duplication behaviour

[kay]

Hi guys,

This issue stumped us for a little while so I thought I'd share and try figure out if it's the expected behaviour, or if an improvement can be made in the SI code (even if it's of the "fail-fast" type).

We have the following element in our applicationContext.

<sftp:inbound-channel-adapter
        id="sftpInboundAdapter"
        session-factory="sftpSessionFactory" cache-sessions="true"
        remote-directory="${sftp.remote.dir}" remote-file-separator="/"
        filename-regex=".*\.txt" delete-remote-files="true"
        local-directory="#{incomingTempDir.absolutePath}" auto-create-local-directory="true"
        channel="sftpIncomingFiles">
    <integration:poller fixed-delay="${sftp.poller.rate}" error-channel="sftpErrorChannel"/>
</sftp:inbound-channel-adapter>

Nothing particularly fancy. The applicationContext.xml used to be loaded by a ContextLoaderListener in web.xml, no servlets. Then at some point I added a SOAP interface to this app, so I created MessageDispatcherServlet in web.xml, and out of laziness assigned its contextConfigLocation to the same applicationContext.xml file as above.

This results in the <sftp:inbound-channel-adapter/> element being loaded twice, but it didn't cause any warnings or errors. What it also does is create two pollers on the same SFTP inbound channel adapter - silently. Which in turn results in files being downloaded and delivered to sftpIncomingFiles twice. I tried adding an "id" attribute to the <poller/> element just to see what that does but it still results in duplicates. I would have expected the bean context to either fail on startup due to the duplicate sftpInboundAdapter definition, or to only create one instance. Instead, it created a second poller which caused unexpected behaviour.

Now the correct thing is to ensure that the channel adapter definition is only loaded once, which I've done. But I'm left wondering if something could not be improved to make this less likely to happen to other people?

[Gary Russell]

The dispatcher servlet's application context is an entirely separate context, loaded after the root context.

It does have a child/parent relationship to the root context (so you can inject root beans into your web artifacts).

Beans defined in the web context do not override beans in the root context.

[Mark Fisher]

That is the expected behavior. The context created by ContextLoaderListener is the parent context for the one created by DispatcherServlet, but they are independent in their lifecycles. So, essentially, you had 2 beans. When referencing the bean in the child context you would get the local one since it essentially "hides" the one in the parent, but the bean in the parent does still exist (and incidentally was initialized *before* the DispatcherServlet is even created - since that's the way context-listeners and servlets work). If some other child were added, it might reference that one directly.

[Mark Fisher]

...and it looks like you got two replies for the price of one!

Hope the explanations make sense.

[kay]

Hmmm, that makes sense perfectly now. I always thought of the child context as overriding the root, but as you say that's not the case. Thanks for clearing it up!

I shot myself in the foot trying to be clever That poller really doesn't belong in the root application context in the first place.