Re: Sofa-unaware AEs that create new views in an AAE
I think so too. Have created https://issues.apache.org/jira/browse/UIMA-3765to cover this work. Eddie On Tue, Apr 22, 2014 at 12:26 PM, Peter Klügl wrote: > Am 22.04.2014 18:20, schrieb Peter Klügl: > > Am 22.04.2014 18:10, schrieb Eddie Epstein: > >> The current design supports passing a specific view to an annotator: > >> map the desired view to the default view and do not declare the > >> annotator view aware by declaring input or output sofas. > >> > >> An alternate, unambiguous design would be that the default view > >> should always be delivered to the process method. Is this a better > >> model for you? > > Well, yes, if the analysis engine specifies no input views. I think that > would be reasonable and a better solution since the aggregate can only > map to that view. > > Peter > > >
Re: Deduplicating Annotations With Same coveredText
If you plan on running your pipeline in one JVM (rather than having it scaled out over multiple JVMs), you can consider using an external resource which would be a plain Java Set of the unique covered text so far found. Then, in the annotator (or annotators) that are adding new FeatureStructures representing the possibly duplication annotation, you can first check the shared resource to see if its been already annotated, and if so, skip both creating the additional FeatureStructure, and adding it to the indexes. Would that work for your use case? -Marshall On 4/21/2014 10:20 PM, Petr Baudis wrote: > Hi! > > I'm facing a task of deduplicating annotations that have the same > getCoveredText() value (possibly at different sofa locations) - I'd > like to keep just a single of each; for example if I were to make > a bag-of-words with only single annotation per word and number of > occurences as a feature. (Or, in my case, the annotations are scored > candidate answers in a QA system that I'd like to merge if they are > textually the same.) > > Is there a better way than simply loading all annotations of the type > to a java map, mass-dropping them from indexes, then readding some of > them? > > My idea was to simply index them by coveredText and then by sequential > iteration, it's enough to just compare getCoveredText() of current and > previous annotation to decide whether to merge them. However, it appears > that coveredText is not supported as a key feature, I'd have to make an > explicit copy of it as a separate feature. Is there any other option? > > Thanks, > > Petr "Pasky" Baudis > >
Re: Sofa-unaware AEs that create new views in an AAE
Am 22.04.2014 18:20, schrieb Peter Klügl:
> Am 22.04.2014 18:10, schrieb Eddie Epstein:
>> The current design supports passing a specific view to an annotator:
>> map the desired view to the default view and do not declare the
>> annotator view aware by declaring input or output sofas.
>>
>> An alternate, unambiguous design would be that the default view
>> should always be delivered to the process method. Is this a better
>> model for you?
Well, yes, if the analysis engine specifies no input views. I think that
would be reasonable and a better solution since the aggregate can only
map to that view.
Peter
> I actually solved the problem without changing any code.
>
> What I wanted, or what I would have expected, is that the CAS given in
> the process method is already the view mapped in the aggregate. The
> component that made the problems has a code fragment that checks the
> name of the given CAS and, if that is null, takes view with the default
> CAS (_InitialView). I actually don't remember why I added that.
>
> The aggregate maps now to that default view of the analysis engine
> instead of a specific one, and the analysis engine retrieves that view
> if the base CAS is given. So, no need for an additional parameter.
> That's all I wanted :-)
>
> Thanks Eddie,
>
> Peter
>
>
>> Eddie
>>
>>
>>
>>
>> On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl wrote:
>>
>>> Am 18.04.2014 15:23, schrieb Eddie Epstein:
On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >>> wrote:
> Am 17.04.2014 15:01, schrieb Eddie Epstein:
>> Hi Peter,
>>
>> The logic is that since a sofa aware component may have one or
>> more input and/or output views, such a component needs to use
>> getView to specify which to use.
>>
>> For sofa aware delegates, sofa mapping enables the delegate to
>> hard wire input and/or output View names in annotator code (or
>> annotator config parameters) and then have the real View names
>> assigned via mapping in the aggregate.
> Is the real view name in the mapping important at all since the view get
> accessed by the implementation in the process() method?
>
The real view name is what will be used when the CAS is serialized
to a file or to a remote service.
>>> Yes, but that has nothing to do with the mapping, which is still obsolete.
>>>
>>>
> I don't see the effect of the mapping to the default input view of an
> sofa aware AE without input view capabilities at all. The mapping says
> view1 is linked, but another one arrives.
>
The input view for a sofa aware component is always the base CAS view,
for the reason given above.
>>> I don't see the reasons. Why shouldn't the analysis engine get the view
>>> mapped in the aggregate? If the analysis engine has more input views,
>>> then it gets the base view and still can access them in the
>>> implementation. It actually has to anyway right now. If it has only one
>>> (or only the default view), then it can directly use the given one
>>> without a static implementation (getView("name")) or an additional
>>> parameter. I think this would enable the creation of better components
>>> and I actually have a use case right now.
>>>
>>>
> So, the best practice is to introduce a parameter for specifying the
> input view? In case that the AE implementation should be used several
> times in an AAE for different views.
>
Many if not most view aware components I've seen do not have a single
input view.
>>> Ruta has some, which do not work in pipelines when cascaded.
>>>
>>> Maybe I missed something, but I do not yet see any reasons why it should
>>> get the base view.
>>>
>>> Peter
>>>
>>>
Eddie
Re: Sofa-unaware AEs that create new views in an AAE
Am 22.04.2014 18:10, schrieb Eddie Epstein:
> The current design supports passing a specific view to an annotator:
> map the desired view to the default view and do not declare the
> annotator view aware by declaring input or output sofas.
>
> An alternate, unambiguous design would be that the default view
> should always be delivered to the process method. Is this a better
> model for you?
I actually solved the problem without changing any code.
What I wanted, or what I would have expected, is that the CAS given in
the process method is already the view mapped in the aggregate. The
component that made the problems has a code fragment that checks the
name of the given CAS and, if that is null, takes view with the default
CAS (_InitialView). I actually don't remember why I added that.
The aggregate maps now to that default view of the analysis engine
instead of a specific one, and the analysis engine retrieves that view
if the base CAS is given. So, no need for an additional parameter.
That's all I wanted :-)
Thanks Eddie,
Peter
> Eddie
>
>
>
>
> On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl wrote:
>
>> Am 18.04.2014 15:23, schrieb Eddie Epstein:
>>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >> wrote:
>>>
Am 17.04.2014 15:01, schrieb Eddie Epstein:
> Hi Peter,
>
> The logic is that since a sofa aware component may have one or
> more input and/or output views, such a component needs to use
> getView to specify which to use.
>
> For sofa aware delegates, sofa mapping enables the delegate to
> hard wire input and/or output View names in annotator code (or
> annotator config parameters) and then have the real View names
> assigned via mapping in the aggregate.
Is the real view name in the mapping important at all since the view get
accessed by the implementation in the process() method?
>>> The real view name is what will be used when the CAS is serialized
>>> to a file or to a remote service.
>>>
>>
>> Yes, but that has nothing to do with the mapping, which is still obsolete.
>>
>>
I don't see the effect of the mapping to the default input view of an
sofa aware AE without input view capabilities at all. The mapping says
view1 is linked, but another one arrives.
>>> The input view for a sofa aware component is always the base CAS view,
>>> for the reason given above.
>>>
>> I don't see the reasons. Why shouldn't the analysis engine get the view
>> mapped in the aggregate? If the analysis engine has more input views,
>> then it gets the base view and still can access them in the
>> implementation. It actually has to anyway right now. If it has only one
>> (or only the default view), then it can directly use the given one
>> without a static implementation (getView("name")) or an additional
>> parameter. I think this would enable the creation of better components
>> and I actually have a use case right now.
>>
>>
So, the best practice is to introduce a parameter for specifying the
input view? In case that the AE implementation should be used several
times in an AAE for different views.
>>> Many if not most view aware components I've seen do not have a single
>>> input view.
>>
>> Ruta has some, which do not work in pipelines when cascaded.
>>
>> Maybe I missed something, but I do not yet see any reasons why it should
>> get the base view.
>>
>> Peter
>>
>>
>>> Eddie
>>>
>>
Re: Sofa-unaware AEs that create new views in an AAE
The current design supports passing a specific view to an annotator:
map the desired view to the default view and do not declare the
annotator view aware by declaring input or output sofas.
An alternate, unambiguous design would be that the default view
should always be delivered to the process method. Is this a better
model for you?
Eddie
On Tue, Apr 22, 2014 at 6:47 AM, Peter Klügl wrote:
> Am 18.04.2014 15:23, schrieb Eddie Epstein:
> > On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl >wrote:
> >
> >> Am 17.04.2014 15:01, schrieb Eddie Epstein:
> >>> Hi Peter,
> >>>
> >>> The logic is that since a sofa aware component may have one or
> >>> more input and/or output views, such a component needs to use
> >>> getView to specify which to use.
> >>>
> >>> For sofa aware delegates, sofa mapping enables the delegate to
> >>> hard wire input and/or output View names in annotator code (or
> >>> annotator config parameters) and then have the real View names
> >>> assigned via mapping in the aggregate.
> >> Is the real view name in the mapping important at all since the view get
> >> accessed by the implementation in the process() method?
> >>
> > The real view name is what will be used when the CAS is serialized
> > to a file or to a remote service.
> >
>
>
> Yes, but that has nothing to do with the mapping, which is still obsolete.
>
>
> >> I don't see the effect of the mapping to the default input view of an
> >> sofa aware AE without input view capabilities at all. The mapping says
> >> view1 is linked, but another one arrives.
> >>
> > The input view for a sofa aware component is always the base CAS view,
> > for the reason given above.
> >
>
> I don't see the reasons. Why shouldn't the analysis engine get the view
> mapped in the aggregate? If the analysis engine has more input views,
> then it gets the base view and still can access them in the
> implementation. It actually has to anyway right now. If it has only one
> (or only the default view), then it can directly use the given one
> without a static implementation (getView("name")) or an additional
> parameter. I think this would enable the creation of better components
> and I actually have a use case right now.
>
>
> >> So, the best practice is to introduce a parameter for specifying the
> >> input view? In case that the AE implementation should be used several
> >> times in an AAE for different views.
> >>
> > Many if not most view aware components I've seen do not have a single
> > input view.
>
>
> Ruta has some, which do not work in pipelines when cascaded.
>
> Maybe I missed something, but I do not yet see any reasons why it should
> get the base view.
>
> Peter
>
>
> > Eddie
> >
>
>
Re: Sofa-unaware AEs that create new views in an AAE
I think there is no problem at all after I noticed that the analysis
engine can use its local names of the views. I cannot use an arbitrary
input view, but the initialView. It's not what I preferred, but it
solves my problem.
Sorry about the inconveniences.
Best,
Peter
Am 22.04.2014 12:47, schrieb Peter Klügl:
> Am 18.04.2014 15:23, schrieb Eddie Epstein:
>> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl wrote:
>>
>>> Am 17.04.2014 15:01, schrieb Eddie Epstein:
Hi Peter,
The logic is that since a sofa aware component may have one or
more input and/or output views, such a component needs to use
getView to specify which to use.
For sofa aware delegates, sofa mapping enables the delegate to
hard wire input and/or output View names in annotator code (or
annotator config parameters) and then have the real View names
assigned via mapping in the aggregate.
>>> Is the real view name in the mapping important at all since the view get
>>> accessed by the implementation in the process() method?
>>>
>> The real view name is what will be used when the CAS is serialized
>> to a file or to a remote service.
>>
>
> Yes, but that has nothing to do with the mapping, which is still obsolete.
>
>
>>> I don't see the effect of the mapping to the default input view of an
>>> sofa aware AE without input view capabilities at all. The mapping says
>>> view1 is linked, but another one arrives.
>>>
>> The input view for a sofa aware component is always the base CAS view,
>> for the reason given above.
>>
> I don't see the reasons. Why shouldn't the analysis engine get the view
> mapped in the aggregate? If the analysis engine has more input views,
> then it gets the base view and still can access them in the
> implementation. It actually has to anyway right now. If it has only one
> (or only the default view), then it can directly use the given one
> without a static implementation (getView("name")) or an additional
> parameter. I think this would enable the creation of better components
> and I actually have a use case right now.
>
>
>>> So, the best practice is to introduce a parameter for specifying the
>>> input view? In case that the AE implementation should be used several
>>> times in an AAE for different views.
>>>
>> Many if not most view aware components I've seen do not have a single
>> input view.
>
> Ruta has some, which do not work in pipelines when cascaded.
>
> Maybe I missed something, but I do not yet see any reasons why it should
> get the base view.
>
> Peter
>
>
>> Eddie
>>
Re: Hanging UIMA AS requests
Hi, do you see any evidence in the service log of any problems? The client side will block in sendAndReceive() until a reply comes back from the service. You can attach jconsole to the service to see if it is hung somewhere. Please check UIMA-AS README for instructions how to configure service to enable jmx. Jerry On Tue, Apr 22, 2014 at 4:38 AM, Frank Enders wrote: > Dear all, > > we are using a synchronous sendAndReceiveCAS() call within a webservice > endpoint (JAX WS RI). > Doing so, in some cases we find hanging requests, which are not getting > completed. > I am attaching a corresponding part of a thread dump. > > We are using UIMA AS 2.4.0. Application environment is Tomcat 6.0.32, JAX > WS RI 2.1.7. > > Have you encountered a similar behaviour? > > Thank and all the best > Frank > > "catalina-exec-77" Id=3412437 in WAITING cpu=2083520 ms usr=2056580 ms > blocked 547742 for -1 ms waited 297560 for -1 ms > locks java.util.concurrent.locks.ReentrantLock$NonfairSync@19c88785 > at sun.misc.Unsafe.park(Native Method) > - waiting on (a java.util.concurrent.Semaphore$NonfairSync@3c3939fc) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) > at java.util.concurrent.locks.AbstractQueuedSynchronizer. > parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) > at java.util.concurrent.locks.AbstractQueuedSynchronizer. > doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) > at java.util.concurrent.locks.AbstractQueuedSynchronizer. > acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) > at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) > at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineComm > on_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineCommon_impl.java:2062) > at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineComm > on_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineCommon_impl.java:1952) > at de.averbis.extraction.[...].webservice.WebservicePort. > getLanguage(WebservicePort.java:1214) > at sun.reflect.GeneratedMethodAccessor2765.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.sun.xml.ws.api.server.InstanceResolver$1.invoke( > InstanceResolver.java:246) > at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) > at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke( > EndpointMethodHandler.java:257) > at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest( > SEIInvokerTube.java:93) > at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598) > at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557) > at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542) > at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) > - locked (a com.sun.xml.ws.api.pipe.Fiber@5a8fe32) index 19 frame > com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) > at com.sun.xml.ws.server.WSEndpointImpl$2.process( > WSEndpointImpl.java:243) > at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit. > handle(HttpAdapter.java:471) > at com.sun.xml.ws.transport.http.HttpAdapter.handle( > HttpAdapter.java:244) > at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle( > ServletAdapter.java:135) > at com.sun.xml.ws.transport.http.servlet.WSServletDelegate. > doGet(WSServletDelegate.java:129) > at com.sun.xml.ws.transport.http.servlet.WSServletDelegate. > doPost(WSServletDelegate.java:160) > at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost( > WSServlet.java:75) > at javax.servlet.http.HttpServlet.service(Unknown Source) > at javax.servlet.http.HttpServlet.service(Unknown Source) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown > Source) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown > Source) > at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown > Source) > at org.apache.catalina.core.StandardContextValve.invoke(Unknown > Source) > at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) > at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source) > at org.apache.catalina.valves.AccessLogValve.invoke(Unknown Source) > at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) > at org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source) > at org.apache.coyote.ajp.AjpAprProcessor.process(Unknown Source) > at > org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(Unknown > Source) > at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker. > runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.ja
Hanging UIMA AS requests
Dear all, we are using a synchronous sendAndReceiveCAS() call within a webservice endpoint (JAX WS RI). Doing so, in some cases we find hanging requests, which are not getting completed. I am attaching a corresponding part of a thread dump. We are using UIMA AS 2.4.0. Application environment is Tomcat 6.0.32, JAX WS RI 2.1.7. Have you encountered a similar behaviour? Thank and all the best Frank "catalina-exec-77" Id=3412437 in WAITING cpu=2083520 ms usr=2056580 ms blocked 547742 for -1 ms waited 297560 for -1 ms locks java.util.concurrent.locks.ReentrantLock$NonfairSync@19c88785 at sun.misc.Unsafe.park(Native Method) - waiting on (a java.util.concurrent.Semaphore$NonfairSync@3c3939fc) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281) at java.util.concurrent.Semaphore.acquire(Semaphore.java:286) at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineCommon_impl.java:2062) at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl.sendAndReceiveCAS(BaseUIMAAsynchronousEngineCommon_impl.java:1952) at de.averbis.extraction.[...].webservice.WebservicePort.getLanguage(WebservicePort.java:1214) at sun.reflect.GeneratedMethodAccessor2765.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246) at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) - locked (a com.sun.xml.ws.api.pipe.Fiber@5a8fe32) index 19 frame com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160) at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75) at javax.servlet.http.HttpServlet.service(Unknown Source) at javax.servlet.http.HttpServlet.service(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source) at org.apache.catalina.valves.AccessLogValve.invoke(Unknown Source) at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) at org.apache.catalina.connector.CoyoteAdapter.service(Unknown Source) at org.apache.coyote.ajp.AjpAprProcessor.process(Unknown Source) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(Unknown Source) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662)
Re: Sofa-unaware AEs that create new views in an AAE
Am 18.04.2014 15:23, schrieb Eddie Epstein:
> On Thu, Apr 17, 2014 at 9:17 AM, Peter Klügl wrote:
>
>> Am 17.04.2014 15:01, schrieb Eddie Epstein:
>>> Hi Peter,
>>>
>>> The logic is that since a sofa aware component may have one or
>>> more input and/or output views, such a component needs to use
>>> getView to specify which to use.
>>>
>>> For sofa aware delegates, sofa mapping enables the delegate to
>>> hard wire input and/or output View names in annotator code (or
>>> annotator config parameters) and then have the real View names
>>> assigned via mapping in the aggregate.
>> Is the real view name in the mapping important at all since the view get
>> accessed by the implementation in the process() method?
>>
> The real view name is what will be used when the CAS is serialized
> to a file or to a remote service.
>
Yes, but that has nothing to do with the mapping, which is still obsolete.
>> I don't see the effect of the mapping to the default input view of an
>> sofa aware AE without input view capabilities at all. The mapping says
>> view1 is linked, but another one arrives.
>>
> The input view for a sofa aware component is always the base CAS view,
> for the reason given above.
>
I don't see the reasons. Why shouldn't the analysis engine get the view
mapped in the aggregate? If the analysis engine has more input views,
then it gets the base view and still can access them in the
implementation. It actually has to anyway right now. If it has only one
(or only the default view), then it can directly use the given one
without a static implementation (getView("name")) or an additional
parameter. I think this would enable the creation of better components
and I actually have a use case right now.
>> So, the best practice is to introduce a parameter for specifying the
>> input view? In case that the AE implementation should be used several
>> times in an AAE for different views.
>>
> Many if not most view aware components I've seen do not have a single
> input view.
Ruta has some, which do not work in pipelines when cascaded.
Maybe I missed something, but I do not yet see any reasons why it should
get the base view.
Peter
> Eddie
>
