Hello Florin,
this is not an issue with Spring but with the injection pre-existing instances
in general. With "pre-existing" I mean instances that are not managed by the
UIMA framework. If you deploy a UIMA component somewhere, the UIMA framework
usually knows how to create all involved instances. Now let's say you want to
your UIMA component in a Spring application and in that application you have a
database connection pool. Now you may want to create a CasConsumer that uses
this existing DB connection pool to write stuff to a database. Obviously the
UIMA framework shouldn't create the pool, you only need some way to may it
accessible within the CasConsumer. That's where you can use the methods I have
outlined.
Now regarding scale-out. Your CasConsumer would of course only work somewhere,
where such a DB connection pool is already present, because UIMA does not know
how to create such a pool for you. So you have to make sure that in each
environment that you use for your scale-out, the pool is somehow set up.
If you do not want to use pre-existing instances, but only want to use a Spring
application context XML file for configuration, you could just implement a
normal UIMA external resource, have it load the XML file and return the
ApplicationContext. There wouldn't be any particular dependency injection
involved in that on the UIMA side though. Something like this I suppose
(untested):
class SpringResource implements SharedResourceObject {
private ApplicationContext context;
public void load(DataResource aData) throws ResourceInitializationException
{
context = new ClassPathXmlApplicationContext(aData.getUri().toString());
}
public String getContext() {
return context;
}
}
You can point the URI to a file or to a classpath location which contains
different Spring configurations on your test and on your production environment.
-- Richard
Am 20.11.2012 um 16:58 schrieb Spico Florin <[email protected]>
:
> Hello!
> Thank you for your response Richard. As far as I know (please correct me
> if I'm wrong) the scale out is referring to create many instances of the
> same analyzing engine that will process CASes. The Analyzing engine should
> be also remote AE.
> Can you please provide more details why adding how the objects created
> with Spring affect the scale-out capability?
>
> Regards,
> Florin
>
> On Tue, Nov 20, 2012 at 5:07 PM, Richard Eckart de Castilho <
> [email protected]> wrote:
>
>> Hello Florin,
>>
>> first of all, UIMA does not support injections of pre-existing instances.
>> You are not supposed to access any object instances that are not created
>> within the context of UIMA. If you can live with the consequences of doing
>> this (i.e. no UIMA supported scale-out), you can have a look at the
>> following possibilities that I have implemented as proof-of-concept in
>> uimaFIT:
>>
>>
>>
>> == SimpleNamedResourceManager ==
>>
>> The uimaFIT SimpleNamedResourceManager takes a key-value map of names and
>> instances. When you create your analysis instance with this resource
>> manager, you can fetch the instances via the UIMA external resource
>> mechanism. Example:
>>
>>
>> // Create a custom resource manager that allows to inject any Java object
>> as an external
>> // dependency
>> final Map<String, Object> externalContext = new HashMap<String, Object>();
>> externalContext.put("pojoName2", new AtomicInteger(5));
>>
>> // Create resource manager
>> SimpleNamedResourceManager resMgr = new SimpleNamedResourceManager();
>> resMgr.setExternalContext(externalContext);
>>
>> // Instantiate component
>> AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(desc, resMgr,
>> null);
>>
>> More test code is here:
>>
>>
>> http://code.google.com/p/uimafit/source/browse/trunk/uimaFIT/src/test/java/org/uimafit/factory/ExternalResourceFactoryTest.java
>>
>>
>>
>> == SpringContextResourceManager ==
>>
>> The uimaFIT SpringContextResourceManager makes all Spring beans from a
>> given Spring application context available via the UIMA external resource
>> mechanism. Example:
>>
>> // Acquire application context
>> ApplicationContext ctx = getApplicationContext();
>>
>> // Create resource manager
>> SpringContextResourceManager resMgr = new SpringContextResourceManager();
>> resMgr.setApplicationContext(ctx);
>>
>> // Instantiate component
>> AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(desc, resMgr,
>> null);
>>
>> See also:
>>
>>
>> http://code.google.com/p/uimafit/source/browse/trunk/uimaFIT-spring/src/test/java/org/uimafit/spring/SpringContextResourceManagerTest.java
>>
>>
>>
>> == UIMA Factory Patching ==
>>
>> This is an invasive mechanism that patches the UIMA framework at runtime
>> so that every UIMA component that is created is post-processed by a Spring
>> application context. This means, UIMA components can directly use any
>> annotations supported by Spring (e.g. @PersistenceContext, …). Only one
>> application context is supported per JVM because the UIMA framework is
>> (unfortunately) internally statically configured. This should work, but I
>> didn't really test it yet beyond the proof-of-concept unit test.
>>
>> Example code:
>>
>>
>> http://code.google.com/p/uimafit/source/browse/trunk/uimaFIT-spring/src/test/java/org/uimafit/spring/UimaFactoryInjectionTest.java
>>
>> Cheers,
>>
>> -- Richard
>>
>> Am 20.11.2012 um 14:22 schrieb Spico Florin <[email protected]>:
>>
>>> Hello!
>>> I have a connection to data source (triplestore) that is used by
>>> multiple annotators. With the current implementation of UIMA I have to
>>> provide this connection in for all these annotators descriptors, making
>> the
>>> deployment very tedious when switching from one environment to another
>> (for
>>> example test env to production env).
>>> I have read the posts from
>>> http://comments.gmane.org/gmane.comp.apache.uima.general/3340 but still
>> is
>>> not clear for me how to handle the DI. Basically I would like to inject
>>> this connection to all of annotators that need it from a single
>>> configuration file, thus eliminating the mentioned inconvenience.
>>> Can you please provide what is the best approach for handling this kind
>>> of problems?
>>>
>>> I look forward for your answers.
>>>
>>> Regards,
>>> Florin
>>>
>>> P.S. I was thinking to use Spring and ApplicationContext and its
>>> configuration file. Is this a suitable solution?
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)
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
-------------------------------------------------------------------
