Hello Marshal, your point is well taken. I'll go a bit into detail now. My intention was this:
1) if a spring context provides a bean by the name of the resource use that 2) use the default UIMA logic to initialize the resource By subclassing, this works nice. First I add all beans from the context to the mInternalResourceRegistrationMap. Then I call super.initializeExternalResources(...), which is written so that it then only instantiates all resources with a name that has not yet been registered. Instead of subclassing, it would be possible to implement a completely new ResourceManager, but that would mean to copy lots of code from the ResourceManager_Impl and change just a minor detail. It would also be possible implement a delegation pattern, remove those resources and resource bindings that could be covered by the Spring context from the ResourceManagerConfiguration instance before passing it on to the delegate ResourceManager, but that would make quite a bit more complex. It is definitely worth considering in the long run. The main point though is that, independent of subclassing vs delegation, there is something very odd here. The mInternalResourceRegistrationMap is protected, but the type of the instances inside it (ResourceRegistration) are package private. This seems quite pointless because there is no way for a subclass to make use of mInternalResourceRegistrationMap in that manner. So either mInternalResourceRegistrationMap should be package private as well, or ResourceRegistration should be protected. I'd opt for the latter because most parts of the ResourceManager_Impl are protected (and because it makes my code simpler for the time being). Even though delegation provides a better separation that subclassing, is it necessary for a framework to make it particularly difficult to use subclassing? Shouldn't it be the choice of the developer to couple tightly or loosely? Best regards, Richard Am 18.08.2011 um 22:29 schrieb Marshall Schor: > Hi Richard, > > before we do something here, I'm wondering if you've considered a delegation > model, rather than subclassing. > > Subclassing tends to create a rather tight coupling between a class and its > subclass, in terms of maintenance and changes, while delegation doesn't; > several > articles I've seen seem to favor delegation over inheritance. > > Would a delegation model work in this case for what you want to experiment > with? > > -Marshall > > On 8/18/2011 2:29 AM, Richard Eckart de Castilho wrote: >> Hi, >> >> would you mind addressing https://issues.apache.org/jira/browse/UIMA-2102 >> before the 2.3.2 release? >> >> Cheers, >> >> Richard >> >> Am 17.08.2011 um 17:37 schrieb Marshall Schor: >> >>> ok, I'll do this restructuring, under >>> https://issues.apache.org/jira/browse/UIMA-1967 >>> >>> -Marshall >>> >>> On 8/17/2011 10:21 AM, Jörn Kottmann wrote: >>>> On 8/17/11 4:10 PM, Marshall Schor wrote: >>>>> I'd like to do a release of the base UIMA SDK soon. >>>>> >>>>> We've tried the alternative structure, of putting a top-level pom in the >>>>> directory above the projects, for the addons. This structure is more >>>>> conventional for Maven projects, but creates a bit of "noise" in the >>>>> Eclipse IDE >>>>> (the projects appear twice). >>>>> >>>>> I'm personally comfortable with moving to the more conventional >>>>> structure; would >>>>> others object if I convert the base UIMAJ project structure to that style? >>>>> >>>> I am also +1, because it makes things easier. >>>> >>>> Jörn >>>> >> Richard Eckart de Castilho >> Richard Eckart de Castilho -- ------------------------------------------------------------------- Richard Eckart de Castilho Technical Lead Ubiquitous Knowledge Processing Lab FB 20 Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
