<div dir="ltr">Hi Tobias,<div><br></div><div><div><div>> Except now all dependencies are not there anymore because now there</div><div>> are non-obvious (to me) implicit runtime dependencies.</div><div>></div><div>
> I find this unfortunate.</div></div></div><div><br></div><div>I agree that this is a two-edged sword. We have more types of plugins now, which can alter the runtime behavior in more ways, so of course it becomes possible for ill-behaved plugins to bring down the system.</div>
<div><br></div><div>This is already true in ImageJ 1.x though, because it is extensible at runtime: any plugin class could have a static initializer block that hoses up the JVM however it can imagine. It is just easier to do now.</div>
<div><br></div><div>IMO, it would not be worth it to eliminate these powerful extension points just because of this possibility. The flexibility gained outweighs any disadvantages.</div><div><br></div><div>We have already taken great pains to mitigate the issue with services in the context: when you create a new ImgOpener without specifying an SJC context, it uses _only_ relevant service types: things that implement the SciJavaService and SCIFIOService interfaces. In other words: _not_ ImageJServices or other service types. The reason LegacyService is being (erroneously!) pulled in here is due to a bug in the design of the SJC AppEventService, as I said. I introduced a "LegacyAppEventService" which is a SciJavaService but depends on the ImageJ LegacyService. Hence, any Context that asks for SciJavaServices now pulls in a DefaultLegacyService whenever the LegacyAppEventService is on the classpath. The fix is to stop doing that.</div>
<div><br></div><div>Anyway, if it still bothers you that any ol' developer can add something to the classpath which hoses up your programs, then you can stop it: create a more carefully controlled SJC Context and pass that to the ImgOpener. Alternately, we could change ImgOpener to be even more conservative in which services it uses. Of course, there are downsides there: any additional file format plugins, codec plugins, etc., might not be work properly if they do not have access to the services they need.</div>
<div><br></div><div>I am very open to ideas for mitigating the extensibility issues here.</div><div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 9:35 AM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de" target="_blank">pietzsch@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Johannes,<div class=""><div><br></div><div>On 22 Aug 2014, at 09:04, Johannes Schindelin <<a href="mailto:Johannes.Schindelin@gmx.de" target="_blank">Johannes.Schindelin@gmx.de</a>> wrote:</div>
</div><div><div><br><blockquote type="cite"><div class="">Hi Tobias,<br><br>On Fri, 22 Aug 2014, Tobias Pietzsch wrote:<br><br><blockquote type="cite">Currently<br>new io.scif.img.ImgOpener();<br>fails with<br>java.lang.IllegalArgumentException: Invalid service: net.imagej.legacy.LegacyAppEventService<br>
</blockquote><br>Yep, the explanation is very easy:<br><br></div><blockquote type="cite"><div class="">[...]<br>Caused by: java.lang.UnsupportedOperationException: Cannot instantiate more than one DefaultLegacyService<br>
</div>[…]<br></blockquote></blockquote><div><br></div><div>I missed that...</div><div class=""><br><blockquote type="cite"><br>There is already a context, including a legacy service. Unfortunately, the<br>best way to get at this context from an *ImageJ 1.x plugin* that I could<br>
come up with is:<br><br><span style="white-space:pre-wrap"> </span>import org.scijava.Context;<br><br><span style="white-space:pre-wrap"> </span>...<br><br><span style="white-space:pre-wrap"> </span>final Context context = (Context)<br>
<span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>IJ.runPlugIn(Context.class.getName(), "");<br><span style="white-space:pre-wrap"> </span>final ImgOpener opener = new ImgOpener(context);<br>
<br>(There is no way to make that more convenient without letting SCIFIO<br>depend on ImageJ 1.x, which is of course a big no-no).<br></blockquote><div><br></div></div><div><div>The problem with this solution you suggested is that it does not work in Eclipse:</div>
<div><div style="margin:0px;font-size:11px;font-family:Monaco;color:rgb(255,38,0)">Exception in thread "main" <span style="text-decoration:underline;color:#0433ff">java.lang.IllegalArgumentException</span>: Invalid service: net.imagej.legacy.DefaultLegacyService</div>
</div><div><br></div></div><div>As much as I understand the need for the runtime service discovery used by the scijava stack, there are certainly downsides to it.</div><div>My feeling is that in some ways it undermines the advantages that we have gained by switching to maven.</div>
<div>I can import a maven project into my Eclipse, and all the dependencies are there, explicitly and automatically, which is really very convenient.</div><div>Except now all dependencies are not there anymore because now there are non-obvious (to me) implicit runtime dependencies.</div>
<div>I find this unfortunate.</div><div><br></div><div>That being said, I found a solution that works for now, both in Eclipse and in Fiji</div><div> final ImgOpener opener = new ImgOpener( new Context( SCIFIOService.class, AppService.class, StatusService.class ) );</div>
<div><div>This avoids requiring the net.imagej.legacy.LegacyAppEventService.</div><div>It seems to work, but I’m not sure: Are there any downsides to that?</div><div><br></div><div>best regards,</div><div>Tobias</div><div>
<br></div></div><div class=""><blockquote type="cite"><br>Of course, you could also turn your plugin into an ImageJ2 plugin -- which<br>is handled properly in Fiji thanks to Fiji Just Being ImageJ2 -- and then<br>it would become as easy as:<br>
<br><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>@Parameter<br><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>private IOService io;<br><br><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>...<br>
<span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>// use the IOService (which lets SCIFIO handle<br><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span><span style="white-space:pre-wrap"> </span>// things) to open your dataset<br>
<br>Ciao,<br>Johannes<br><br>-- <br>-- <br>Please avoid top-posting, and please make sure to reply-to-all!<br><br>Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
<br>--- <br>You received this message because you are subscribed to the Google Groups "Fiji-devel" group.<br>To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:fiji-devel+unsubscribe@googlegroups.com" target="_blank">fiji-devel+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br></blockquote></div></div><br></div></div></blockquote></div><br></div>