I'm currently in the process of testing 13.1 for production use within our group. AS part of this I'm going through and updating the source for our custom java based assays to build again 13.1 source. I have a question regarding changes to the AbstractAssayProvider constructor arguments:

In 13.1, the 'declaringModule' has been pushed up the class hierarchy from ModuleAssayProvider to AbstractAssayProvider and in doing so all subclasses must now specify this dependency. I'm looking at examples in labkey source and I see the usual pattern is to use ModuleLoader.getInstance().getModule(MODULECLASSHERE.class), for example:


public FCSExpressAssayProvider() {
    super(PROTOCOL_PREFIX, RUN_PREFIX, (AssayDataType) ExperimentService.get().getDataType(FCSExpressAssayDataHandler.NAMESPACE), ModuleLoader.getInstance().getModule(FCSExpressModule.class));
}


Now my question is: Would an equally valid and safe way to specify the 'declaringModule' be to pass 'this' in as a constructor argument when registering the assay provider from the module class?

For example in our custom BioanalyzerModule.java:

@Override
    public void doStartup(ModuleContext moduleContext)
    {
        // add a container listener so we'll know when our container is deleted:
        ContainerManager.addContainerListener(new BioanalyzerContainerListener());
        ExperimentService.get().registerExperimentDataHandler(new BioanalyzerDataHandler());
        AssayService.get().registerAssayProvider(new BioanalyzerRNAAssayProvider(this));
        AssayService.get().registerAssayProvider(new BioanalyzerDNAAssayProvider(this));
    }

The last 2 lines register two assay providers and pass in the declaring module as 'this'. I'm trying to avoid the AssayProvider class(es) from having a source code dependency on the module class, as it creates a circular dependency between the two classes.

Thanks!

-
Anthony