question about Flow interface

[Marshall Schor <ms...@schor.com>]

In putting in the hooks for changing the class path when calling user 
code, for the Flow object methods like "next", I need to have the 
framework access the CAS that the flow object is associated with.

The Flow object implementations (there are 2 impl bases - one for cas 
and one for jcas) have a setter and getter.  The setter is public, but 
the getter is protected.  The setter, although public, is not in the 
Flow interface, I'm guessing, because the flow object is always expected 
to be derived from either the cas impl base or the jcas impl base, both 
of which are abstract classes.

2 questions: would it be better to move the setting of this out of 
user-code into framework code (have the framework do the setting)?  Any 
objection to my changing the "protected" method of the getter to a 
public one, so the framework can get the CAS for purposes of setting up 
the classloader and other things before calling into user code?

-Marshall

Re: question about Flow interface

[Adam Lally <al...@alum.rpi.edu>]

On 6/1/07, Marshall Schor <ms...@schor.com> wrote:
> In putting in the hooks for changing the class path when calling user
> code, for the Flow object methods like "next", I need to have the
> framework access the CAS that the flow object is associated with.
>
> The Flow object implementations (there are 2 impl bases - one for cas
> and one for jcas) have a setter and getter.  The setter is public, but
> the getter is protected.  The setter, although public, is not in the
> Flow interface, I'm guessing, because the flow object is always expected
> to be derived from either the cas impl base or the jcas impl base, both
> of which are abstract classes.
>

Neither the setter nor the getter are on the interface.  Flow objects
are not required to extend the cas impl base or the jcas impl base -
they just need to implement the Flow interface.  The get/set methods
are entirely convenience methods for the user and the framework has no
dependency on them.

> 2 questions: would it be better to move the setting of this out of
> user-code into framework code (have the framework do the setting)?

The model now is:  the framework calls FlowController.computeFlow,
which returns a Flow object.  The Flow object is expected to be fully
set up and ready to be used, which means it has its CAS reference set
(assuming it needs a CAS reference - something like Fixed Flow might
not even need one).

Are you proposing that FlowController.computeFlow would return a Flow
object that was not fully set up (was missing its CAS reference) and
that the caller would supply one.  I think I like the current way
better.

> Any
> objection to my changing the "protected" method of the getter to a
> public one, so the framework can get the CAS for purposes of setting up
> the classloader and other things before calling into user code?
>

I think the real question is whether we add this method to the Flow
interface (which would then require it to be public).  Just making it
public means you have to reply on a particular ImplBase class which is
not what we want to do.

I'd prefer not to change the interface unless we need to.  I believe a
reference to the CAS is easily accessible at the point where the
framework calls Flow.next(), anyway.  It seems like it must be, since
the next thing the framework does is to dispatch that CAS to the
indicated destination.

-Adam