Fancy Bread

I revisited the Metro ServiceFactory after John Whish's recent question about how Metro instantiates concrete classes. After a bit of trial and error, I'm happy to announce that the ServiceFactory now supports the creation of concrete gateways without requiring a concrete service in the same package. Before I outline how Metro resolves the class path for instantiating a Service and composed Gateways, I'll describe the basic conventions one must follow to use Metro.

• Transfer Object definitions should be placed within a <package /> tag, so that the object class name follows the pattern {packageName}.{objectName}.
• Any concrete Service or Gateway you write must reside within a directory whose name matches the Transfer package name.
• Directories containing packages of concrete classes must reside directly below the root component path (the componentPath constructor argument for the ServiceFactory) or the optional library component path (the libPath constructor argument for the ServiceFactory).

Given the above requirements, the ServiceFactory will instantiate components in the following order.

1. A Service and/or Gateway(s) found within the relative path "/{componentPath}/{packageName}".
2. A Service and/or Gateway(s) found within the relative path "/{libPath}/{packageName}".
3. A Service and/or Gateway(s) found within the relative path "/metro/{packageName}".
4. The Service and Gateway found in "/metro/core".

Additionally, concrete components can extend either the core components (metro.core.Service and metro.core.Gateway), or any other component that extends the core components within the inheritance chain. This opens the door for a developer to create their own supertype components that extend the Metro core components, which are then extended by concrete components within their application. To facilitate extending the core components (or Metro packages), I have added an optional "libPath" constructor argument to the ServiceFactory.