[esb-issues] [JBoss JIRA] Commented: (JBESB-1918) Implementation of ScriptingAction is inefficient and incomplete

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- Upon further consideration, I will be rejecting most (not all) of what is being requested in this Jira item. My reasoning is explained in the comments interwoven below: Jiri> The ScriptingAction should be polished for beter perfromance and functionality as Groovy scripting action The GroovyActionProcessor has direct access to the groovy API, which allows for the caching of a pre-compiled "Script". Although in BSF there is a notion of a "CodeBuffer" object, there is no API allowing one to execute it. BSF thus forces one to recompile each time. Also, please note that GroovyActionProcessor synchronizes on the cached Script, so I would be curious what that does to performance in a concurrent environment. Jiri> - BSFManager should be created in intialize(), not process() method (credit goes to Kevin :-)) Nope. Unfortunately in BSF the BSFManager itself holds references to the declared beans. In our case, this includes the JBoss ESB "Message" object. In looking at BSFManager code, it is apparent it is not thread safe. Thus, a new BSFManager must be created during each process() method. Sorry. Jiri> - The script reload should be supported This becomes moot given my above comments. Jiri> - Is it necessary to process BSF config file? Cannot we use getLangFromFilename method? There's nothing wrong with using the BSFManager's getLangFromFilename method because it is static (I wouldn't want to create an non-reusable BSFManager instance), however there was a reason for creating the static LANGUAGES map beyond just getting the scripting language by extension. Basically, one can configure the language property of the ScriptingAction to be either language *or* extension if he/she wants to, and I will still be able to figure out the language. One might argue that my code does not take into consideration the registering of multiple engines per language (which in BSF would add the ":" property value separator), however it is moot in our case because we don't expose the BSFManager for others to do that. Jiri> - It should be probably stated in the docs that for compiled scriping languages it is not guranteed that the compliation is done only once which can lead to performance degradation - native action can be preferred in such case This is a good point, and I will donate some documentation and attach it to this Jira item. Understand that this is because of limitations of BSF. It would be nice to use the JDK 1.6 javax.script functionality, but remember that JBoss ESB needs to work with JDK 1.5... Jiri> - If the language is not recognized (not in Map) during initialization an exception should be thrown. Currently it is supposed that the file extension is language name, which is probably unintentional, and could lead to exception while processing the first message. I will add a check in the initialise() method to make sure an engine has been registered per the language. However, you are incorrect on the "file extension is language" assumption. It gets swapped out as Kevin noted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira