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

Reply via email to