Singleton *Plugins* don't resolve dependencies recurrently

[hinerm]

If you have a non-contextual object that you want to connect with other contextual objects, and thus try to Context.inject it, any @Parameters that are SingletonServices will NOT be created/injected. You will get a [ERROR] java.lang.IllegalArgumentException: Required service is missing.

If those singleton services are initialized beforehand, e.g. as an @Parameter or another contextual object that is used before injecting the non-contextual object, then the injection will proceed without errors.

[ctrueden]

Sorry, I don't understand the issue. Can you make an MCVE?

[hinerm]

@ctrueden I think I may have misunderstood the root cause here myself, but I am not sure if there are two separate issues or not.

The use case that brought up the issue is:

• I have a class with Contextual parameters
• In the constructor, I tried to pass a Context and call inject(this) to auto-pop the fields. But this would fail specifically on injecting the SingletonService parameters.

However, I have now noticed that there may be a more general error state:

• I have a singleton service
• One of the singleton plugins of that service has an @Parameter on legacy service
• If I try to load that plugin greedily (e.g. in the initialize method) it will emit an [ERROR] java.lang.IllegalArgumentException: Required service is missing: net.imagej.legacy.LegacyService. But if I do it lazily, everything is fine.

adjusting service priority didn't seem to matter. I don't know.. it needs more exploration. But there were times I resolved errors in my singleton plugin's initialization by adding a dependency to that plugin's required service, to my singleton service.

[hinerm]

yeah I just double-checked and it wasn't about injection but timing.. I can inject that FijiAssistantChat now, probably because I'm doing things not at initialization.

[hinerm]

Nope I was wrong. I was just confused about when the error appears. Since going back to manual context injection, I get [ERROR] java.lang.IllegalArgumentException: Required service is missing: sc.fiji.llm.chat.ContextItemService when starting the Fiji Chat... plugin.

I "fixed" it by adding an @Parameter on ContextItemService to the SwingChatbotService in this commit

[ctrueden]

The ContextItemService does not extend an appropriate marker interface (either SciJavaService or ImageJService), and so it won't be included in the SciJava Context upon creation under normal circumstances. How are you launching the program? From a main method? From a unit test? From Fiji itself? Regardless: either add the marker interface declaration, or else construct the SciJava Context to include all services on the classpath (new Context()).

[hinerm]

it won't be included in the SciJava Context upon creation under normal circumstances.

@ctrueden Something is buggy in this logic and it does not follow expectations. I am running in Fiji itself. The problem is that within the same Context in Fiji, my marker-less services are not discovered when I call Context.inject, but are discovered when referred to with @Parameter.

In fact, most of my services are SingletonServices that I had written marker-less. The ContextItemService was apparently just the only one that wasn't being used as an @Parameter elsewhere prior to the inject call. But I never would have had any indication that this wasn't the intended pattern if I didn't try to manually inject the context in a class.

I am questioning how marker interfaces are being used. My expectation as a developer is that I annotate something as a @Plugin(type=Service) and that gets it included in the Context.

Side note: when I extended SingletonService I didn't manually check the type hierarchy but assumed I was "buying in" as a SciJavaService. The fact that PTService operates on SciJavaPlugins but is not itself a SciJavaService feels unintuitive to me from an "inclusion" standpoint - although it totally makes sense if marker interfaces are to facilitate developers creating custom, restricted Contexts.

But even the javadoc for SciJavaService is confusing: a "marker for core SciJava-Common Services," doesn't sound like something I should implement in a Fiji chatbot library.

I'll also say that my expectation as a user is that I build my app by what I download - not by which entry point I run.

So, in order of preference, these are the potential paths forward I see:

1. Keep marker interfaces but when starting Fiji (and ImageJ2), include all services by default.
2. Remove marker interfaces
3. Keep marker interfaces and the current restricted IJ2/Fiji startup, but make the behavior consistent - whatever mechanism Fiji is discovering marker-less services as @Parameters, should also work when manually injecting the Context (or not work in both cases)

What do you think?

[ctrueden]

@hinerm While I agree that the current design of "marker interfaces" and Context scopes are a serious PoLA violation, I doubt we can change behavior in scijava-common v2.x without causing major downstream breakage.

That said, we can rethink the design for SciJava 3, as part of a new scijava-context component in the scijava core repository.

3. Keep marker interfaces and the current restricted IJ2/Fiji startup, but make the behavior consistent - whatever mechanism Fiji is discovering marker-less services as @parameters, should also work when manually injecting the Context (or not work in both cases)

This is where I think any immediate bug-fix needs to focus. I do not understand why SciJava can inject an unmarked service successfully from a Context that does not include them. Have you checked what services are actually in the Context by examining its ServiceIndex?