Hi again,

I think that the ComponentClassResolver should expose it's configuration via the service interface; i.e. it should say which packages are library packages. Of course this configuration should be immutable.

public List<LibraryMapping> getLibraryMappings();

The need for this can be illustrated by the tapestry-hibernate module. In HibernateModule we see that the HibernateSessionSource service accepts a configuration of packages that should be searched for entities.

So in the module we have:

    /**
* Contributes the package "&lt;root&gt;.entities" to the configuration, so that it will be
     * scanned for annotated entity classes.
     */
public static void contributeHibernateSessionSource (Configuration<String> configuration,

    @Inject
    @Symbol(InternalConstants.TAPESTRY_APP_PACKAGE_PARAM)
    String appRootPackage)
    {
        configuration.add(appRootPackage + ".entities");
    }

Which adds the application standard entity package to the sessions source configuration. Now, this is ok for single module applications. When you have an application that is composed of several sub-apps, in each of them you have to contribute

public void contributeComponentClassResolver (Configuration<LibraryMapping> conf)
    {
        conf.add(new LibraryMapping("subapp1", "com.example.subapp1");
    }

public void contributeHibernateSessionSource (Configuration<String> configuration)
    {
        configuration.add("com.example.subapp1.entities");
    }

This is not so DRY. I'm also developing a service that adds type coercions for all entities. It too needs to scan the entity packages so it too must be configured with a package. Then I have a navigation service + component that builds up a navigation tree by scanning for pages that have a @Navigable annotation. it too needs to receive yet the same packages as configuration so it can scan. So in each sub-app module I have 4 different contribution method contribution more or less the same information on different places.

But if the ComponentClassResolver would expose the library mappings then I would have something like:

    public static void contributeHibernateSessionSource(
        @Inject componentClassResolver componentClassResolver,
        Configuration<String> configuration
)
    {
for (LibraryMapping lib : componentClassResolver.getLibraryMappings ()) {
          configuration.add(lib.getRootPackage() + ".entities");
        }
    }

So all these services (hibernate source, navigation service, hibernate entity coercer) will be able to automatically configure themselves and the modules would need (again) only to specify library mappings to the component class resolver.

What do you think?

Cheers,
Ognen
--
Ognen Ivanovski | ognen.ivanovski [at] netcetera.com.mk
phone +389 -2- 30 64 532 | fax +389 -2- 30 79 495
Netcetera | 1000 Skopje | Macedonia | http://netcetera.com.mk



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to