Open quintesse opened 11 years ago
I don't see how this could work if it's not the env that starts the whole thing that sets-up / instantiates the callbacks. Or that all callbacks "communicate" with starting env via static variables or ThreadLocals.
But I'll think about this a bit more, and try to hack some poc.
How soon do you need this? (not that I have too much time ...)
No no, the env setting up everything is good, the idea is exactly that I'd have something like:
interface Progress {
void notify(String blah, int whatever);
}
Progress progressListener = createProgressListener();
// And HERE something to pass --^ to --v
org.jboss.modules.Module.setModuleLogger(new JDKModuleLogger());
org.jboss.modules.Main.main(setupArguments(argList, sysRep, ceylonVersion));
ModuleLoader ml = Module.getBootModuleLoader();
runtimeModule = ml.loadModule(ModuleIdentifier.create(CEYLON_RUNTIME, ceylonVersion));
while the code being run by JB Modules would be something like:
Progress progress = getProgressListenerSomehow();
do {
// Work
progress.notify("foo", x);
} while(...);
And you needn't spend too much on it, I'm willing to try it myself if you say for example that using ThreadLocal
for this is perfectly acceptable. But with all the special class loading that JB Modules does I was expecting not to have access to the (same) Progress interface or whatever. But maybe I'm just too paranoid anf things are much easier than I make them out to be?
Moved to 1.1
Moving to 1.2, unfortunately.
We need to figure out how we can have code running inside a JBoss Modules environment use callbacks provided by their caller / environment.
Examples of two situations where we need this right now are:
Assigning this to @alesj for now so he reads this and can leave feedback. (I've talked to him on IRC, but I think it's important to leave any information he can give documented here)