Consider a plugin locator that automatically loads plugins from specified context config files rather than from the ApplicationContext

[erizzo]

Before I discovered spring-plugin I wrote my own solution to the problem (https://github.com/erizzo/spring-pluggable). The main difference between my solution and spring-plugin is the XML scanning PluginLocator (https://github.com/erizzo/spring-pluggable/blob/master/spring-pluggable/src/main/java/com/rizzoweb/spring/pluggable/XMLConfigScanningPluginLocater.java). The locator is injected with a filename pattern for XML bean configs and loads them dynamically, thus eliminating the need for those configs to be imported. Would spring-plugin be interested in a concept like that? It seems that I could easily adapt my code to fit into spring-plugin, assuming it's a desirable idea.

[erizzo]

How should the lack of response to this proposal/question be interpreted: A) Project comitters have no interest in the idea, or it's without merit B) Spring-plugin is a dead project that nobody is actively working on C) Comitters simply too busy to respond so far D) other?

None of these is intended as an accusation or slight against the project; I just want to set my own expectations about involvement.

[tgkprog]

If its good and you have time, just implement it and link a version out here. Maybe they will look at it or maybe others will use it directly and then it will get attention if it works well.

[odrotbohm]

One very fundamental design decision here was not to get into the question of how you actually find plugin implementations (i.e. Spring beans). That responsibility is well served by various means on the Spring container. I've see various approaches to that: simply using component scanning for packages, having a core module that loads XML configuration files from wild-carded, well known locations with explicitly defined Spring beans or even a combination of the two.

So your implementation is basically what <import resource="classpath*:/spring/MyPlugins-*.xml" /> does. Deciding to bootstrap those plugins in a separate ApplicationContext is already something that's a pretty far reaching design decision which I wouldn't necessarily want to impose on users. Again as I said, all of this can be done already, resorting to core Spring Framework features.

I am not convinced this is something that we should change. So unless we find compelling arguments I'd close this one as won't fix. Yes, you are right. The project is on a very low pace, very much for the reason that it's current state seems to serve all clients very well and we haven't had any important feature request of bug reports. There will be casual updates to adhere to changes in the core container but besides that, the amount of work put into it is not going to increase.

[erizzo]

The scanning locator wouldn't be imposed on anyone, it's just another option for locating plugins. It's been a year since I wrote that and almost that long since I used it, but IIRC there was a need or desire to keep the plugin beans out of the main ApplicationContext; that need led to the scanning locator as you see it. Moreover, I liked the idea that the lifecycle of plugins is contained within the pluggable component itself, not directly managed by the ApplicationContext. I think in most cases the plugins are, conceptually at least, owned by the pluggable and don't really have a standalone purpose; thus it makes sense for the pluggable to be able to discover and "own" them itself (of course that's not always the case, which is why I'm not proposing to replace plugin discovery, just provide this alternative implementation). I do believe that this is in the spirit of Spring, namely providing alternative implementations that make certain tradeoffs in order to provide usefulness in different contexts. Maybe I've made that case convincingly, maybe not...like I said it's been a year since I worked on this stuff.

[erizzo]

I want to reiterate, too, that I'm not making any criticism about the "pace" of the project; I was a little disappointed about the pace of response to this particular question, but I totally get the "it's stable and it works" status and corresponding lack of activity.

[odrotbohm]

The point here is: there is no plugin discovery currently as they have to be provided to the registry manually. We have no intention in getting into that business as — as I already outlined — Spring Framework does a pretty decent job of providing a model to discover components using various means.