[ http://jira.jboss.com/jira/browse/JBESB-445?page=comments#action_12354412 ] Tom Fennelly commented on JBESB-445: ------------------------------------ What was the CDATA section issue with the XSD? I remember trying this when we were doing the XSD stuff. I may be wrong, but I thought it actually did support a CDATA section in the properties, but it just didn't make it through to the XMLBeans binding classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-445?page=comments#action_12354416 ] Tom Fennelly commented on JBESB-445: ------------------------------------ Ah OK. Wouldn't it be useful to inject the properties/ConfigTree into the script (as well as the message). This way you can parameterize the scripts from the config. I wonder how this action will perform? I'd imagine that creating a new instance of it every time will be a bit of a dog. But I suppose this is an issue we have with all our actions - they're non-singleton. I'd suggest that if/when we make the actions (or whatever they'll be called in the new architecture) singleton (by default), we could look at using the GroovyClassloader and require the Groovy scripts to implement our ActionProcessor interface (or whatever we call that). Then we can just treat Groovy scripts like any other java class (plus cache the instance on a per action basis). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira