[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] Kevin Conner updated JBESB-1918: -------------------------------- Fix Version/s: 4.4 CP2 (was: 4.2.1 CP4) -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] Kevin Conner commented on JBESB-1918: ------------------------------------- The following description is not correct and should be removed. "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." If the language is not explicitly specified then the extension is used to determine which language to use. This extension can either be the language name *or* the recognised extension as specified within the Languages.properties file. There should have been a check to see if the language was supported though, this is a valid comment. There is already a check for a 'null' language. -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- I'm working on enhancing the ScriptingAction per this jira item. Kevin is correct in his comment, however. -- 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

[ 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- I have yet to add documentation to this jira item. I'll have to do that tomorrow night. I did upload a jbossesb-scripting-enhancements.zip file, however, with the following contained therein. ScriptingAction.java: 1. The LANGUAGES map was renamed to EXTN2LANG and various code comments were added to make it evident what the code was doing to the general reader. 2. Script extensions can now be case insensitive with regards to being mapped back to a script language. 3. There is now a check to make sure a language is registered during the initialise() method rather than waiting for it to fail in the process() method. 4. A log4j Logger is now made available to scripts as the variable "logger" (as were "message", "config", and "payloadProxy"). This is so scripts have someplace to log to rather than System.out. 5. BSFManager is now cleaned up after via a call to terminate() in a finally block. ScriptingActionUnitTest.java 6. A new test method "test_unregistered_language()" has been added. This is to test the new language registration check referred to in #3 above. test.bsh: 7. The logger is now used as part of unit testing. GroovyActionProcessor.java 8. A log4j Logger is now made available to groovy scripts as the variable "logger" just like ScriptingAction.java in #4 above. scripting_chain 9. A new quickstart was added (.../samples/quickstarts/scripting_chain) which exercises various scripts of different languages in a chain, each adding a "link" to the chain by modifying the message's payload as the action pipeline progresses. -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward updated JBESB-1918: ------------------------------ Attachment: jbossesb-scripting-enhancements.zip newer version that has better javadoc of bound variables -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward updated JBESB-1918: ------------------------------ Attachment: Scripting.odt I am uploading a Scripting.odt file to replace that section of ProgrammersGuide.odt. I am not uploading the whole thing because if svn merging is necessary, it would be a pain. ;) Please someone with commit privileges just swap out the current Scripting section with the contents of this uploaded file. I might significant corrections and notes to both the ScriptingAction *and* GroovyActionProcessor sections. Thanks! -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- One last thing: please note that some the documentation changes I made are only valid per some tweaks I made to ScriptingAction.java and GroovyActionProcessor.java, thus the reason why the Scripting.odt is part of this same Jira task as the jbossesb-scripting-enhancements.zip. -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] Work on JBESB-1918 started by Mark Little. -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] Kevin Conner commented on JBESB-1918: ------------------------------------- "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. " I have to admit that when I suggested we investigate this it was under the assumption that BSF would offer some means of precompiling scripts for execution, an assumption that I thought was reasonable. It appears this is not the case. BSF does have a compileScript method but this appears to have very limited functionality (generating java code to call the interpreter's exec method mostly). I know that JSR 223 defines a Compilable interface (albeit optional) which would allow us to drop the repeated interpretation of the scripts, is there a reason why BSF was chosen over JSR 223? -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- Oh yeah... "ant" actually does something interesting, where it's <script/> tag will dynamically use BSF or javax.script (depending on what's available on the classpath) using reflection. But I didn't want version 1 of this thing to be that convoluted. At least not yet. ;) -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] Kevin Conner commented on JBESB-1918: ------------------------------------- The real question that has to be answered is what support would we have from the engines and whether we would have the same coverage (or better) than bsf. -- 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

[ https://jira.jboss.org/jira/browse/JBESB-1918?page=com.atlassian.jira.plu... ] David Ward commented on JBESB-1918: ----------------------------------- Kevin and Burr: Sorry I've been on PTO this past week, thus my delayed responses. Kevin: The other reasons I chose BSF over javax.script: 1. BSF as a library was already available in the underlying AS. 2. Being new to engineering's processes, I didn't know the process of getting new libraries introduced. (Related: it was a pain just to get BSF - which was already there - upgraded.) I very much agree with your "real question that has to be answered" statement. Honestly I don't know how well supported javax.script is from a provider standpoint. It would be good to look into, as well as to understand it's precompilation support (and whether that piece is optional for the providers to implement, and which of them actually do). Burr: I left that comment in there such that people would know the current limitations and not open a slew of bugs just because the languages they thought would work don't, and why. I can remove it if you think it best, in fact I was going to tweak the docs again anyway to clear up the BSH confusion. However, maybe we should time it with the ESB release that will contain the AS release, which in turn contains the BSF upgrade?: https://jira.jboss.org/jira/browse/JBAS-5249 -- 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