Perhaps then the servlet init method is best. I would rather edit the
web.xml than re-compile the script engine and all of the plugin
mechanism seem to overblown for what microsling is tackling.
-paddy
On Oct 31, 2007, at 12:18 PM, Felix Meschberger wrote:
Hi,
Am Mittwoch, den 31.10.2007, 15:37 +0100 schrieb David Nuescheler:
maybe thats a stupid idea and i am not sure if i even want
to bring up this option ;) :
This idea is probably not stupid at all, but not appropriate for
microsling, maybe.
(3) how about using the workspace itself as an extension mechanism...
something like:
/.microsling/script-engines/esp
/.microsling/script-engines/fm
/.microsling/script-engines/rb
... which would host all the mapping information also allow for
dynamic extension
and distribution/installation as a content package.
Sounds really easy, but has some implications which make it
inappropriate for microsling (keep in mind that microsling stands for
small, limited, easy to understand, quick to fire-up): It needs class
loader trickery as either the libraries are loaded through a JCR
ClassLoader or are copied to some filesystem location to try to load
them from there. Second phase is then "update": What happens if a
library is updated or removed in the repository ?
So, I would say, that for microsling, we should not use this.
Regards
Felix
