<div dir="ltr">Hi Christian,<br><div><br></div><div>These are both great questions, so no worries!<br></div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

* If I want to use a global "Context" in my complete "KNIME
      Application", why is there the possibility to create several
      contexts?<br></blockquote><div><br></div><div>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. ;)<br>

<br></div><div>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.<br>

</div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
      * 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.?!<br></blockquote><br></div><div>I'm not sure exactly what you mean when you reference the "Scifio" Context. But note that <a href="https://github.com/scifio/scifio/blob/master/scifio/src/main/java/io/scif/SCIFIO.java#L97">the SCIFIO class</a> 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.<br>

<br></div><div>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 <a href="https://github.com/scijava/scijava-common/blob/master/src/main/java/org/scijava/AbstractContextual.java">AbstractContextual</a> classes (which we actually had at one point and then moved away from), etc...<br>

<br></div><div>Hope this helps. Let me know if anything is unclear.<br><br></div><div>- Mark<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 4:43 AM, Christian Dietz <span dir="ltr"><<a href="mailto:christian.dietz@uni-konstanz.de" target="_blank">christian.dietz@uni-konstanz.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Hi Mark,<br>
      <br>
      maybe a very stupid questions, but I got two more very general
      ones:<br>
      <br>
      * If I want to use a global "Context" in my complete "KNIME
      Application", why is there the possibility to create several
      contexts?<br>
      * 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.?!<br>
      <br>
      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 :)<br>
      <br>
      Have a nice day!<br>
      <br>
      Christian<br>
      <br>
      <br>
      Am 13.01.2014 17:34, schrieb Mark Hiner:<br>
    </div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">Hi Christian,</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sat, Jan 11, 2014 at 12:05 PM,
            Christian Dietz <span dir="ltr"><<a href="mailto:christian.dietz@uni-konstanz.de" target="_blank">christian.dietz@uni-konstanz.de</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote>
            <div><br>
            </div>
            <div>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.<br>
              <br>
            </div>
            <div>So let's go more into the philosophy of what you're
              trying to do:<br>
              <br>
            </div>
            <div>- 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?<br>
              <br>
            </div>
            <div>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?<br>
            </div>
          </div>
        </div>
        <br>
        <div> Thanks,<br>
          Mark<br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Sat, Jan 11, 2014 at 12:05 PM,
          Christian Dietz <span dir="ltr"><<a href="mailto:christian.dietz@uni-konstanz.de" target="_blank">christian.dietz@uni-konstanz.de</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <div>Hi Mark,<br>
                <br>
                I figured out my problem and I have no clue how to solve
                it in a nice way :-)<br>
                <br>
                We restrict our the context we create to very limited
                amount of services. We only want to load the services we
                really need. <br>
                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.<br>
                <br>
                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
                <a href="https://github.com/knime-ip/knip-imagej2/blob/master/org.knime.knip.imagej2.core/src/org/knime/knip/imagej2/core/IJGateway.java" target="_blank">https://github.com/knime-ip/knip-imagej2/blob/master/org.knime.knip.imagej2.core/src/org/knime/knip/imagej2/core/IJGateway.java</a>).<br>


                <br>
                Does this make sense?<br>
                <br>
                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.<br>
                <br>
                Thanks for your support again,<br>
                <br>
                Christian
                <div><br>
                  <br>
                  <br>
                  Am 10.01.2014 19:57, schrieb Mark Hiner:<br>
                </div>
              </div>
              <blockquote type="cite">
                <div dir="ltr">
                  <div>
                    <div>
                      <div>
                        <div>
                          <div>OK, so I'm questioning how the <a href="https://github.com/knime-ip/knip-imagej2/blob/master/org.knime.knip.imagej2.core/src/org/knime/knip/imagej2/core/IJGateway.java#L428" target="_blank">IJAdapterProvider</a>
                            assembles the list of services..
                            <div>
                              <div><br>
                                <br>
                                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.<br>
                                <br>
                                Does that make sense?<br>
                                <br>
                              </div>
                            </div>
                          </div>
                          <div>
                            <div> 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?<br>
                              <br>
                            </div>
                          </div>
                        </div>
                        <div>
                          <div> Also, yes whenever you try to
                            get objects from an ObjectIndex, ALL pending
                            initializations occur. This just defers the
                            initialization until it's required.<br>
                            <br>
                          </div>
                        </div>
                      </div>
                      <div>
                        <div> 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.<br>
                          <br>
                          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.<br>
                          <br>
                          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.<br>
                          <br>
                          Then maybe we can discuss more tomorrow!<br>
                          <br>
                        </div>
                      </div>
                    </div>
                    Take care<br>
                  </div>
                  Mark<br>
                </div>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>