[SCIFIO] Service construction

Tue Jan 21 16:08:39 CST 2014

Hi Christian & everyone,

> Curtis can expand on this if necessary, but by avoiding one static
> Context, we allow multiple instances of applications to run in the
> same JVM with differing sets of Services, Plugins, and any other state
> that could be desired.

Right. There are valid use cases for having multiple Contexts in the same
JVM. But I would not suggest proliferating several Context objects within
the same instance of the KNIME application, if you can avoid it.

As a rule of thumb: two objects from different Contexts should not
interact. There is currently no way to pass objects between Contexts. Each
Contextual object has exactly *one* Context associated with it, which
cannot be changed once it is set. This is by design. I am open to changing
the design, but at the moment, that's how it works. So if you create object
Foo using Context F, and then create object Bar using Context B, and then
later Foo and Bar need to interact somehow... the behavior will be
undefined at best, unstable or explosive at worst. Such interactions do not
always check for "context consistency" but that assumption is definitely
implicit throughout the codebase right now.

So I agree with Mark: best if you can create one Context that has all the
services you need, and you can reuse that Context everywhere. If this is a
problem for OSGi-related reasons (e.g., class loaders) then perhaps we can
tackle those issues at our next hackathon. :-)

Regards,
Curtis

On Tue, Jan 14, 2014 at 8:39 AM, Mark Hiner <hiner at wisc.edu> wrote:

> Hi Christian,
>
> These are both great questions, so no worries!
>
> * If I want to use a global "Context" in my complete "KNIME Application",
>> why is there the possibility to create several contexts?
>>
>
> Curtis can expand on this if necessary, but by avoiding one static
> Context, we allow multiple instances of applications to run in the same JVM
> with differing sets of Services, Plugins, and any other state that could be
> desired. I don't have specific use cases off hand, but fundamentally,
> avoiding static classes and allowing state to be encapsulated with each
> instance of a Context is considerably more flexible. I think the only
> advantage a static Context would have is that it might mitigate some
> confusion. ;)
>
> Also, if you know you want a static Context, it's easy enough to create a
> static utility class with a getContext() method that provides a consistent
> Context instance for everything in your application.
>
> * How can I use the class "Scifio" in a global way, s.t. this context also
>> knows all other services? The "Scifio" Context class itself suggests to
>> create one context for ImageJ2, one for SCIFIO, etc.?!
>>
>
> I'm not sure exactly what you mean when you reference the "Scifio"
> Context. But note that the SCIFIO class<https://github.com/scifio/scifio/blob/master/scifio/src/main/java/io/scif/SCIFIO.java#L97>has a constructor that accepts an existing Context. The SCIFIO class was
> designed, fundamentally, to act as a wrapper for existing Contexts. So you
> can maintain your one application context, and create a new SCIFIO around
> it when needed. The zero-param constructor is primarily a convenience for
> when you don't have/need a Context already in your application.
>
> So to make SCIFIO global, just have a single global Context and then wrap
> it with a SCIFIO whenever you need the SCIFIO API. There are many ways you
> could implement this - using a static utility method as above, or adding a
> HasSCIFIO layer on top of AbstractContextual<https://github.com/scijava/scijava-common/blob/master/src/main/java/org/scijava/AbstractContextual.java>classes (which we actually had at one point and then moved away from),
> etc...
>
> Hope this helps. Let me know if anything is unclear.
>
> - Mark
>
>
> On Tue, Jan 14, 2014 at 4:43 AM, Christian Dietz <
> christian.dietz at uni-konstanz.de> wrote:
>
>>  Hi Mark,
>>
>> maybe a very stupid questions, but I got two more very general ones:
>>
>> * If I want to use a global "Context" in my complete "KNIME Application",
>> why is there the possibility to create several contexts?
>> * How can I use the class "Scifio" in a global way, s.t. this context
>> also knows all other services? The "Scifio" Context class itself suggests
>> to create one context for ImageJ2, one for SCIFIO, etc.?!
>>
>> Don't misunderstand me, I really want to use the context the way you guys
>> think its best, but I understand too little since now I guess :)
>>
>> Have a nice day!
>>
>> Christian
>>
>>
>> Am 13.01.2014 17:34, schrieb Mark Hiner:
>>
>>  Hi Christian,
>>
>> On Sat, Jan 11, 2014 at 12:05 PM, Christian Dietz <
>> christian.dietz at uni-konstanz.de> wrote:
>>
>>> If so, I thought about an "exclude service" option in the Context?
>>> Something like: Include all SingletonService, but if you include them, make
>>> sure that they are of type ImageJService or SCIFIOService or something like
>>> that? Or: The user can provide a "ServiceFilter" Implementation where he
>>> can exclude/Include certain services? I don't know if this makes sense at
>>> all, just a naive thinking I guess.
>>
>>
>>  I understand what you're saying, but there are significant problems
>> with excluding services like this. It's really not extensible - it will
>> always be possible for something downstream to add a problematic service.
>> Unless you have complete control of the classpath - but if you have that,
>> you can limit which services and plugins are discovered, and thus loaded,
>> anyway.
>>
>>  So let's go more into the philosophy of what you're trying to do:
>>
>>  - Why severely limit Services available to the Context? From what I
>> understood (and please correct me if I'm wrong here) you have one class
>> loader and one context per plugin? So you want to limit the number of
>> services because each plugin is going to load a new context? Is that right?
>>
>>  If so, I feel like the Context use is a bit too narrowly scoped here.
>> It's developed as more of an application-level context, so I think it will
>> be a continuous struggle to use it as something else. Would it be possible
>> to refactor your context usage to simply have one Context, that loads all
>> of the services/plugins available, and is then passed around/reused by
>> other modules?
>>
>>  Thanks,
>> Mark
>>
>>
>> On Sat, Jan 11, 2014 at 12:05 PM, Christian Dietz <
>> christian.dietz at uni-konstanz.de> wrote:
>>
>>>  Hi Mark,
>>>
>>> I figured out my problem and I have no clue how to solve it in a nice
>>> way :-)
>>>
>>> We restrict our the context we create to very limited amount of
>>> services. We only want to load the services we really need.
>>> Since now, I told my Context to load all SingletonService.class. I
>>> needed to load all SingletonServices, such that the method
>>> isMultipleChoiceObject (line 382) returns "true" for e.g. the
>>> "CalculatorOp" and KNIME can generate the dialog for e.g. the
>>> ImageCalculator. This only worked if the CalculatorService.class is
>>> available in the context.
>>>
>>> The important part actually is: If I request to load _any_
>>> SingletonService, of course also the SingletonServices from SCIFIO etc are
>>> also loaded, which I actually don't need here. On the other hand, I don't
>>> want to manually add SingletonServices from ImageJ2 I need (this is what I
>>> do now with CalculatorSerice, ThresholdService, etc... see line 128/129 at
>>> https://github.com/knime-ip/knip-imagej2/blob/master/org.knime.knip.imagej2.core/src/org/knime/knip/imagej2/core/IJGateway.java
>>> ).
>>>
>>> Does this make sense?
>>>
>>> If so, I thought about an "exclude service" option in the Context?
>>> Something like: Include all SingletonService, but if you include them, make
>>> sure that they are of type ImageJService or SCIFIOService or something like
>>> that? Or: The user can provide a "ServiceFilter" Implementation where he
>>> can exclude/Include certain services? I don't know if this makes sense at
>>> all, just a naive thinking I guess.
>>>
>>> Thanks for your support again,
>>>
>>> Christian
>>>
>>>
>>>
>>> Am 10.01.2014 19:57, schrieb Mark Hiner:
>>>
>>>    OK, so I'm questioning how the IJAdapterProvider<https://github.com/knime-ip/knip-imagej2/blob/master/org.knime.knip.imagej2.core/src/org/knime/knip/imagej2/core/IJGateway.java#L428>assembles the list of services..
>>>
>>>
>>> It seems like it's trying to manually assemble a list of services to
>>> construct the context with. Is that right? When constructing the context
>>> and providing a list of services, you basically can give it just the
>>> superclass services, and all children will be discovered. We did that so
>>> you can make a context with say SCIFOService and SciJavaService and then
>>> plugins that add more SCIFIOServices will automatically be included.
>>>
>>> Does that make sense?
>>>
>>>    So I would possibly refactor this to make a context with
>>> ImageJServices, SCIFIOServices, and SciJavaServices.. because those are the
>>> relevant components you're using, right?
>>>
>>>    Also, yes whenever you try to get objects from an ObjectIndex, ALL
>>> pending initializations occur. This just defers the initialization until
>>> it's required.
>>>
>>>    All SingletonServices add each of their singleton instances to the
>>> ObjectIndex lazily during their initialize() method. So that's why these
>>> translators are being loaded. And they fail because SCIFIOServices aren't
>>> included.
>>>
>>> So, context creation is part of the problem.. but I think the
>>> classpath/class loader is still incorrect, because you have OME-Formats
>>> stuff in it.
>>>
>>> I will try to update the Context so that when that error comes up, it
>>> prints out the services that WERE used to create the context, and maybe the
>>> classpath of the current class loader. Because that error is extremely
>>> cryptic and unhelpful.
>>>
>>> Then maybe we can discuss more tomorrow!
>>>
>>>   Take care
>>>  Mark
>>>
>>>
>>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "scijava" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scijava+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://scif.io/pipermail/scifio/attachments/20140121/9bfc79fd/attachment-0002.html>