-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cassalog may define a Classloader to load resources from #4
Comments
If there is something we can do in CassalogImpl.groovy to improve loading scripts, I am open to suggestions. I am not so sure about passing a class or class loader to the include function. The include function is used within cassalog scripts. While any groovy/Java code can be embedded in a script, the focus is certainly on schema changes. I fear that having class loader stuff in the scripts adds complexity where it does not really belong. |
Perhaps implementation could be as easy as add an optional object on the CassalogBuilder CassalogBuilder builder = new CassalogBuilder(); So, that object if present can reference to the getClass() used in the include. def include() { It's optional, so current behaviour should be the default, but this addition will let to play better with classloading scenarios (cassalog loaded from a different module where it is used). Just an idea, but hey, if there is another possibility, I'm fine if we can use cassalog from several classloaders. It's not a blocker at the moment, so just a nice to have for future versions. |
def include() {
...
def scriptURI = getClass().getResource(script).toURI()
...
}
The current design works well when cassalog is loaded from the same .war, but in a shared environment where cassalog library might be loaded from a different module, it could be nice if a class or classloader can be passed to include() (or globally on a setter) to define from which CL load those resources.
The text was updated successfully, but these errors were encountered: