On Fri, Jul 31, 2009 at 9:47 PM, sebb<seb...@gmail.com> wrote: > On 01/08/2009, sebb <seb...@gmail.com> wrote: >> On 31/07/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote: >> > On Thu, Jul 30, 2009 at 10:54 PM, sebb<seb...@gmail.com> wrote: <snip/> >> > >> > > N.B. This implementation is deliberately different from the one which >> > > is currently included in BSF 3.0 binary distributions. >> > > >> > > That implementation (from https://scripting.dev.java.net/) does not >> > > allow multi-statement scripts, and it's handling of variable scopes is >> > > a bit odd, as one can read/write/delete global variables, but not >> > > create them. >> > > >> > >> > <snap/> >> > >> > So, should be fun when services discovery finds both :-) Have you tried >> that? >> >> >> I've not tried yet. One can use BSF 3.0 without the 3rd party engine >> definitions, which would avoid the problem, but of course someone >> might want to use Jexl + one of the other scripting languages. >> >> One way to guarantee access to the new Jexl version would be to add an >> alias for the language, e.g. ApacheJexl. >> > > Just seen your comments regarding JEXL casing. > > The Sun factory uses only "jexl", so if we don't use that (apart from > the extension name) our factory won't get confused with the Sun one. > <snap/>
Yeah, but its a little more than that, I suspect theres similar issues with extension names, mime types as well. So I suggest testing all of those cases having both jars available for discovery. If we can make things be mutually exclusive (through casing etc.), thats probably best. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
