[chain] Update servlet implementation classes to be aware of CatalogFactory

• Key: CHAIN-4
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Niall Pemberton
• Reporter: Joe Germuska
• Affects Version/s: 1.0
• Fix Version/s: 1.2

Environment

Operating System: other
Platform: Other

Description

As brought up by Howard Lin in this thread
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/63506

the ChainProcessor and related classes were not updated to work with
CatalogFactory in the 1.0 release.

This should be corrected before the next release of commons-chain.

Comments

[Joe Germuska]

This link is a better pointer to the initial statement of the problem:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/63264

I'm attaching a patch and a new class which I think deal with the main issue –
that the catalog is sometimes stored in the request scope instead of in the
context – but I would really prefer someone who is using this stuff to champion
this ticket, review the patches and such. I don't have time to build and test a
ChainProcessor servlet.

[Joe Germuska]

Created an attachment (id=14495)
Superclass for mappers to share common behavior.

[Joe Germuska]

Created an attachment (id=14496)
Patch three *Mapper classes to extend AbstractMapper

Since the mappers all work in about the same way, it makes sense to have an
AbstractMapper which looks up the commands and just uses a different mechanism
for determining the command name.

I used the basis of your solution Joe to resolve this - but modified the LookupCommand so that the "mapper" implementations could inherit directly from that.

Solution retains backwards compatibility with previous versions by checking for a catalog in the context under the catalogKey - but catalogKey (i.e. setCatalogKey/getCatalogKey methods) are now deprecated and LookupCommand "catalogName" should be used instead.