Re: Service construction

[Mark Hiner]

Hi Christian,

On Sat, Jan 11, 2014 at 12:05 PM, Christian Dietz <christi...@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 <christi...@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 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

[Mark Hiner]

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 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 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 <christi...@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

[Curtis Rueden]

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

--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.