[SCIFIO] Service construction

Tue Jan 14 08:39:38 CST 2014

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
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://scif.io/pipermail/scifio/attachments/20140114/89f1e264/attachment-0002.html>