Guillaume,
You're right,
In my opinion the problem is not to regenerate code to use the new
endpoint instead the old one, but
to reuse the "old groovy script" just developed, that are using the old
set of named variables exchanged,
by servicemix and the script.
It's possibel to have the new component have the same variables and
helpers with the old names used by
the new endpoint too???
Andrea
Guillaume Nodet ha scritto:
I do understand the problem, however i'm a bit concerned that backward
compatibility is not kept. This means a disruptive effect on our
users who will have to change their configuration, or even their
scripts :-(
Maybe a solution would be to create a new engine if we can't keep both
endoints in the same one.
On Wed, Jun 11, 2008 at 12:53 PM, lhein <[EMAIL PROTECTED]> wrote:
Hi,
currently I am reworking the servicemix-script component to have a jsr-223
enabled endpoint.
The JSR-223 is an abstraction layer for scripting for java. There are
already engine implementations for lots of languages...for example groovy,
javascript, jruby, bsh, xpath, xslt, velocity etc.
A list of available engines can be found here:
https://scripting.dev.java.net/
In my opinion the old endpoint which uses Spring Dynamic Languages (there
are only 3 languages supported by Spring) should be abandoned in 3.3
Release. This old endpoint causes problems with dependency managment. Today
I tried to get JRuby running on both old and new endpoint and figured out
that this is impossible. The reason is, that JSR223 needs JRuby >=1.1 and
Spring JRuby <=1.0....so what :)
What do you think?
Regards
Lars
--
View this message in context:
http://www.nabble.com/-DISCUSS--Abandon-old-servicemix-script-endpoint-tp17774828p17774828.html
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
