Hi Paddy, Am Sonntag, den 30.12.2007, 18:51 -0800 schrieb Padraic Hannon: > Do you think we could treat the script engines as resources as well? > I'm thinking if so we could have resource bundles (stored in jcr) to > provide scripting providers. The providers would still conform to the > jcr spec, however, they would be loaded via the jcr using the resource > locator mechanism you describe on the wiki page.
Hmm, first off this looks interesting. But I see some drawbacks: (1) Classloading: A ScriptEngineFactory is not a single class but a conglomerate of classes, that is at least a ScriptEngineFactory and ScriptEngine implementation plus a library implementing the respecting scripting language. So providing this in the repository is not impossible (we have the RepositoryClassLoader after all). I could imagine that a repository observation listener would listen for specific jar files deployed to the repository and could register the respective ScriptEngineFactory as an OSGi service for use by the ScriptEngineManager. (2) Separation of concern: I think with OSGi we have an excellent and well-known framework for lifecycle management and application deployment. In Sling we currently implement the Sling framework which I look at as "infrasructure" as OSGi bundles. Adding scripting language support looks more like infrastructure enhancement and thus should live in the OSGi framework. In addition, OSGi provides proper lifecycle management, I am not eager to reimplement it for the repository but keep using, what we have. Therefore, at long last (sorry), I don't think, that the "Everything is a Resource" fits for scripting language implementations. Of course, you are free to submit a patch - I would imagine this to be a separate project implementing the class loading and provisioning part (see (1) above). Regards Felix
