Awesome! Thank you! Tobias On 25 Aug 2014, at 20:03, Curtis Rueden <ctrue...@wisc.edu> wrote:
> Hi Tobias, > > > This is a critical bug in SJC which I will work on resolving today if > > possible. > > Latest released versions of the SciJava software stack now have this bug > fixed. > > You can get the needed component versions by using pom-imagej 2.49 as parent. > > Regards, > Curtis > > > On Fri, Aug 22, 2014 at 11:51 AM, Curtis Rueden <ctrue...@wisc.edu> wrote: > Hi Tobias, > > > I imagine that in many cases it would be helpful to somehow produce an > > explicit list of transitive (runtime) dependencies at compile time. > > But this is probably not possible because these dependencies are > > specified as interfaces and there is no way of knowing beforehand the > > dependencies of the implementing class that will be used at runtime. > > Actually, you can do it either way. If you ask for an interface, it adds all > concrete service plugins that implement that interface. If you ask for a > concrete class, you get that concrete class only. But it is true that > whenever you ask for an interface, you will also transitively bring in all > dependencies of all implementing classes. > > > In the present case it is even worse, because, if I understand > > correctly, simply put the problem was not a missing dependency is > > missing but additional stuff being present? > > Right. There was an additional AppEventService that had a dependency on the > most problematic and limited ImageJ service: the DefaultLegacyService. > > Another way I plan to (eventually!) mitigate that is to make the > DefaultLegacyService less crabby: I want it to be possible to have more than > one, that simply ends up referencing the same instance of ImageJ 1.x. This > shouldn't be too hard to do but haven't had to time explore that yet. This > would "paper over" the problem you had in that you wouldn't have received an > exception, but still would have brought in a whole bunch of unneeded service > dependencies for the purposes of ImgOpener. > > The real fix here is to retool the AppEvent API as described here: > https://github.com/scijava/scijava-common/commit/852f05cf1dbfb3ce99ccd416fee64573a0692764 > > This is a critical bug in SJC which I will work on resolving today if > possible. > > Regards, > Curtis > > > > On Fri, Aug 22, 2014 at 11:45 AM, Tobias Pietzsch <pietz...@mpi-cbg.de> wrote: > Hi Curtis, > > On 22 Aug 2014, at 16:51, Curtis Rueden <ctrue...@wisc.edu> wrote: > >> Hi Tobias, >> >> > Except now all dependencies are not there anymore because now there >> > are non-obvious (to me) implicit runtime dependencies. >> > >> > I find this unfortunate. >> >> 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. >> >> 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. >> >> IMO, it would not be worth it to eliminate these powerful extension points >> just because of this possibility. The flexibility gained outweighs any >> disadvantages. > > I agree that it is very powerful and I’m not proposing to eliminate it. > > I’m happy that my problem is just a quirk and that I will be able to continue > just calling new ImgOpener(), in blissfull ignorance of what is going on > behind the scenes. > >> 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. >> >> 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. >> >> I am very open to ideas for mitigating the extensibility issues here. > > I currently have only limited knowledge of the workings of scijava-common so > I admit that I have no ideas here. > > I imagine that in many cases it would be helpful to somehow produce an > explicit list of transitive (runtime) dependencies at compile time. But this > is probably not possible because these dependencies are specified as > interfaces and there is no way of knowing beforehand the dependencies of the > implementing class that will be used at runtime. > In the present case it is even worse, because, if I understand correctly, > simply put the problem was not a missing dependency is missing but additional > stuff being present? > > best regards, > Tobias > >> >> Regards, >> Curtis >> >> >> On Fri, Aug 22, 2014 at 9:35 AM, Tobias Pietzsch <pietz...@mpi-cbg.de> wrote: >> Hi Johannes, >> >> On 22 Aug 2014, at 09:04, Johannes Schindelin <johannes.schinde...@gmx.de> >> wrote: >> >>> Hi Tobias, >>> >>> On Fri, 22 Aug 2014, Tobias Pietzsch wrote: >>> >>>> Currently >>>> new io.scif.img.ImgOpener(); >>>> fails with >>>> java.lang.IllegalArgumentException: Invalid service: >>>> net.imagej.legacy.LegacyAppEventService >>> >>> Yep, the explanation is very easy: >>> >>>> [...] >>>> Caused by: java.lang.UnsupportedOperationException: Cannot instantiate >>>> more than one DefaultLegacyService >>>> […] >> >> I missed that... >> >>> >>> There is already a context, including a legacy service. Unfortunately, the >>> best way to get at this context from an *ImageJ 1.x plugin* that I could >>> come up with is: >>> >>> import org.scijava.Context; >>> >>> ... >>> >>> final Context context = (Context) >>> IJ.runPlugIn(Context.class.getName(), ""); >>> final ImgOpener opener = new ImgOpener(context); >>> >>> (There is no way to make that more convenient without letting SCIFIO >>> depend on ImageJ 1.x, which is of course a big no-no). >> >> The problem with this solution you suggested is that it does not work in >> Eclipse: >> Exception in thread "main" java.lang.IllegalArgumentException: Invalid >> service: net.imagej.legacy.DefaultLegacyService >> >> As much as I understand the need for the runtime service discovery used by >> the scijava stack, there are certainly downsides to it. >> My feeling is that in some ways it undermines the advantages that we have >> gained by switching to maven. >> I can import a maven project into my Eclipse, and all the dependencies are >> there, explicitly and automatically, which is really very convenient. >> Except now all dependencies are not there anymore because now there are >> non-obvious (to me) implicit runtime dependencies. >> I find this unfortunate. >> >> That being said, I found a solution that works for now, both in Eclipse and >> in Fiji >> final ImgOpener opener = new ImgOpener( new Context( >> SCIFIOService.class, AppService.class, StatusService.class ) ); >> This avoids requiring the net.imagej.legacy.LegacyAppEventService. >> It seems to work, but I’m not sure: Are there any downsides to that? >> >> best regards, >> Tobias >> >>> >>> Of course, you could also turn your plugin into an ImageJ2 plugin -- which >>> is handled properly in Fiji thanks to Fiji Just Being ImageJ2 -- and then >>> it would become as easy as: >>> >>> @Parameter >>> private IOService io; >>> >>> ... >>> // use the IOService (which lets SCIFIO handle >>> // things) to open your dataset >>> >>> Ciao, >>> Johannes >>> >>> -- >>> -- >>> Please avoid top-posting, and please make sure to reply-to-all! >>> >>> Mailing list web interface: http://groups.google.com/group/fiji-devel >>> >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Fiji-devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to fiji-devel+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
