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

Model loader resolution failure #1810

Closed
vietj opened this Issue Sep 20, 2014 · 58 comments

Comments

Projects
None yet
3 participants
@vietj

vietj commented Sep 20, 2014

I'm trying to deploy a Ceylon module from a Ceylon module and I'm hitting a:

com.redhat.ceylon.compiler.loader.ModelResolutionException: Failed to resolve ceylon.promise.Deferred
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.convertToDeclaration(AbstractModelLoader.java:1332)
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.getDeclaration(AbstractModelLoader.java:4048)

How to reproduce:

1/ clone ceylon-vertx and install it
2/ clone mod-lang-ceylon and checkout the branch deploy-bug
3/ run the integration test with mvn verify, the failing test is org.vertx.ceylon.IntegrationTester#testDeployFromVerticle

@FroMage FroMage added this to the 1.1 milestone Sep 20, 2014

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

I suppose this is not expected in ceylon-vertx?

[ceylon-compile] /home/stephane/src/java-eclipse/ceylon-vertx/source/io/vertx/ceylon/core/util/AnythingVoidHandler.ceylon:4: warning: non-varargs call of varargs method with inexact argument type for last parameter;
[ceylon-compile] shared class AnythingVoidHandler(void done(Anything n)) satisfies Handler_<Void_> {
[ceylon-compile]                                  ^
[ceylon-compile]   cast to Object for a varargs call
[ceylon-compile]   cast to Object[] for a non-varargs call and to suppress this warning
[ceylon-compile] 1 warning
Member

FroMage commented Sep 24, 2014

I suppose this is not expected in ceylon-vertx?

[ceylon-compile] /home/stephane/src/java-eclipse/ceylon-vertx/source/io/vertx/ceylon/core/util/AnythingVoidHandler.ceylon:4: warning: non-varargs call of varargs method with inexact argument type for last parameter;
[ceylon-compile] shared class AnythingVoidHandler(void done(Anything n)) satisfies Handler_<Void_> {
[ceylon-compile]                                  ^
[ceylon-compile]   cast to Object for a varargs call
[ceylon-compile]   cast to Object[] for a non-varargs call and to suppress this warning
[ceylon-compile] 1 warning
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

Nor this:

java.lang.ClassCastException: java.lang.Exception cannot be cast to ceylon.language.Exception
    at org.vertx.ceylon.StartFailureVerticleTest.testDeploy(StartFailureVerticleTest.java:16)
Member

FroMage commented Sep 24, 2014

Nor this:

java.lang.ClassCastException: java.lang.Exception cannot be cast to ceylon.language.Exception
    at org.vertx.ceylon.StartFailureVerticleTest.testDeploy(StartFailureVerticleTest.java:16)
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

I also get lots of:

Running org.vertx.ceylon.LifeCycleVerticleTest
[debug] No vertxRepo found
[error] Compilation error at (3,2) in /home/stephane/src/java-eclipse/mod-lang-ceylon/target/test-classes/lifecycleverticle/module.ceylon:cannot find module artifact io.vertx.ceylon.platform-0.4.0(.car|.jar)
    - dependency tree: lifecycleverticle/1.0.0 -> io.vertx.ceylon.platform/0.4.0
Compiled lifecycleverticle 1.0.0
[debug] No vertxRepo found
sysRepo = flat:/home/stephane/src/java-eclipse/mod-lang-ceylon/target/system-repo
userRepo = /home/stephane/src/java-eclipse/mod-lang-ceylon/target/modules

Member

FroMage commented Sep 24, 2014

I also get lots of:

Running org.vertx.ceylon.LifeCycleVerticleTest
[debug] No vertxRepo found
[error] Compilation error at (3,2) in /home/stephane/src/java-eclipse/mod-lang-ceylon/target/test-classes/lifecycleverticle/module.ceylon:cannot find module artifact io.vertx.ceylon.platform-0.4.0(.car|.jar)
    - dependency tree: lifecycleverticle/1.0.0 -> io.vertx.ceylon.platform/0.4.0
Compiled lifecycleverticle 1.0.0
[debug] No vertxRepo found
sysRepo = flat:/home/stephane/src/java-eclipse/mod-lang-ceylon/target/system-repo
userRepo = /home/stephane/src/java-eclipse/mod-lang-ceylon/target/modules

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

First one filed as #1822

Member

FroMage commented Sep 24, 2014

First one filed as #1822

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

I suppose this is not expected in ceylon-vertx?

right, I wanted to tell you about this but you seemed overloaded :-) . Is it normal ?

vietj commented Sep 24, 2014

I suppose this is not expected in ceylon-vertx?

right, I wanted to tell you about this but you seemed overloaded :-) . Is it normal ?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

java.lang.ClassCastException: java.lang.Exception cannot be cast to ceylon.language.Exception at org.vertx.ceylon.StartFailureVerticleTest.testDeploy(StartFailureVerticleTest.java:16)

I never had this, how did you get it ?

vietj commented Sep 24, 2014

java.lang.ClassCastException: java.lang.Exception cannot be cast to ceylon.language.Exception at org.vertx.ceylon.StartFailureVerticleTest.testDeploy(StartFailureVerticleTest.java:16)

I never had this, how did you get it ?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

so are you are not able to run tests ?

vietj commented Sep 24, 2014

so are you are not able to run tests ?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

Well, no, it's missing the vertxRepo, I think that's the big one.

Member

FroMage commented Sep 24, 2014

Well, no, it's missing the vertxRepo, I think that's the big one.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj commented Sep 24, 2014

the vertxRepo is normally created by the build : https://github.com/vietj/mod-lang-ceylon/blob/master/pom.xml#L233

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

It is created. It's just not found.

Member

FroMage commented Sep 24, 2014

It is created. It's just not found.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj commented Sep 24, 2014

why ?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

perhaps there are changes in latest Ceylon 1.1 ?

vietj commented Sep 24, 2014

perhaps there are changes in latest Ceylon 1.1 ?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

I've no clue

Member

FroMage commented Sep 24, 2014

I've no clue

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

Apparently the tests do not run the code that is in /src/main/java/ because if I change ./src/main/java/org/vertx/ceylon/platform/impl/CeylonVerticle.java to print something it is not printed.

Member

FroMage commented Sep 24, 2014

Apparently the tests do not run the code that is in /src/main/java/ because if I change ./src/main/java/org/vertx/ceylon/platform/impl/CeylonVerticle.java to print something it is not printed.

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

Well, it's weirder than that because my changes from ./src/test/java/org/vertx/ceylon/VertxHelper.java are reflected at runtime.

Member

FroMage commented Sep 24, 2014

Well, it's weirder than that because my changes from ./src/test/java/org/vertx/ceylon/VertxHelper.java are reflected at runtime.

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

Ah, I had to force a mvn clean. Now it compiles.

Member

FroMage commented Sep 24, 2014

Ah, I had to force a mvn clean. Now it compiles.

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member
com.redhat.ceylon.compiler.loader.ModelResolutionException: Failed to resolve ceylon.promise.Deferred
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.convertToDeclaration(AbstractModelLoader.java:1338)
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.getDeclaration(AbstractModelLoader.java:4065)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Class.toProducedType(TypeDescriptor.java:220)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Class.toProducedType(TypeDescriptor.java:212)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.getProducedType(Metamodel.java:243)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Member.toProducedType(TypeDescriptor.java:452)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.getProducedType(Metamodel.java:243)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.isReified(Metamodel.java:228)
    at com.redhat.ceylon.compiler.java.Util.isReified(Util.java:58)
    at ceylon.promise.Deferred.update$priv$(Deferred.ceylon:95)
    at ceylon.promise.Deferred.reject(Deferred.ceylon:115)

Notice the irony in the stack trace :(

Member

FroMage commented Sep 24, 2014

com.redhat.ceylon.compiler.loader.ModelResolutionException: Failed to resolve ceylon.promise.Deferred
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.convertToDeclaration(AbstractModelLoader.java:1338)
    at com.redhat.ceylon.compiler.loader.AbstractModelLoader.getDeclaration(AbstractModelLoader.java:4065)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Class.toProducedType(TypeDescriptor.java:220)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Class.toProducedType(TypeDescriptor.java:212)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.getProducedType(Metamodel.java:243)
    at com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Member.toProducedType(TypeDescriptor.java:452)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.getProducedType(Metamodel.java:243)
    at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.isReified(Metamodel.java:228)
    at com.redhat.ceylon.compiler.java.Util.isReified(Util.java:58)
    at ceylon.promise.Deferred.update$priv$(Deferred.ceylon:95)
    at ceylon.promise.Deferred.reject(Deferred.ceylon:115)

Notice the irony in the stack trace :(

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

  • yes you need to clean otherwise you are doing an incremental compilation or something like that
  • why is it ironic ?

vietj commented Sep 24, 2014

  • yes you need to clean otherwise you are doing an incremental compilation or something like that
  • why is it ironic ?
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

well code from ceylon.promise can't find itself.

Member

FroMage commented Sep 24, 2014

well code from ceylon.promise can't find itself.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

BTW I added a test that deploys a JavaScript script from Ceylon and it works fine, to check the problem was not in the Ceylon deploy.

vietj commented Sep 24, 2014

BTW I added a test that deploys a JavaScript script from Ceylon and it works fine, to check the problem was not in the Ceylon deploy.

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

so how do I run just that test again?

Member

FroMage commented Sep 24, 2014

so how do I run just that test again?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

Which one ?

vietj commented Sep 24, 2014

Which one ?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

the one that fails obviously

Member

FroMage commented Sep 24, 2014

the one that fails obviously

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

didn't you just run it ?

vietj commented Sep 24, 2014

didn't you just run it ?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

yes how

Member

FroMage commented Sep 24, 2014

yes how

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

je veux savoir comment executer un seul test, pas tous

Member

FroMage commented Sep 24, 2014

je veux savoir comment executer un seul test, pas tous

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

un putain de flag de maven quoi

Member

FroMage commented Sep 24, 2014

un putain de flag de maven quoi

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

What is this?

main:
     [exec] ceylon: 'copy' is not a ceylon command
     [exec] Run 'ceylon help' for more help
     [exec] Result: 3
[INFO] Executed tasks
Member

FroMage commented Sep 24, 2014

What is this?

main:
     [exec] ceylon: 'copy' is not a ceylon command
     [exec] Run 'ceylon help' for more help
     [exec] Result: 3
[INFO] Executed tasks
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

CEYLON_HOME=pwd/../ceylon-dist/dist mvn verify -Dmaven.surefire.debug does not work, it terminates the debug process before the failing test starts.

Member

FroMage commented Sep 24, 2014

CEYLON_HOME=pwd/../ceylon-dist/dist mvn verify -Dmaven.surefire.debug does not work, it terminates the debug process before the failing test starts.

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 24, 2014

Member

CEYLON_HOME=pwd/../ceylon-dist/dist mvn verify '-Dtest=org.vertx.ceylon.IntegrationTester#testDeployFromVerticle' did not work

Member

FroMage commented Sep 24, 2014

CEYLON_HOME=pwd/../ceylon-dist/dist mvn verify '-Dtest=org.vertx.ceylon.IntegrationTester#testDeployFromVerticle' did not work

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

In case you want to connect a debugger you have to configure Maven itself in debug mode via MAVEN_OPTS because the integration test in this case are executed in the Maven VM itself (via the exec:java plugin)

vietj commented Sep 24, 2014

In case you want to connect a debugger you have to configure Maven itself in debug mode via MAVEN_OPTS because the integration test in this case are executed in the Maven VM itself (via the exec:java plugin)

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 24, 2014

you should do:

> MAVEN_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
> mvn clean verify -DskipTests

vietj commented Sep 24, 2014

you should do:

> MAVEN_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
> mvn clean verify -DskipTests
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

Doesn't work. It says it's listening but it goes on and fails the test without waiting for my debugger.

Member

FroMage commented Sep 25, 2014

Doesn't work. It says it's listening but it goes on and fails the test without waiting for my debugger.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

try change to suspend=y

vietj commented Sep 25, 2014

try change to suspend=y

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

note: this will run maven itself in debug mode

vietj commented Sep 25, 2014

note: this will run maven itself in debug mode

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

I'm trying to bypass maven to run it from the CLI but I fail:

$ java -cp target/classes:target/test-classes:$HOME/.m2/repository/io/vertx/vertx-core/2.1.2/vertx-core-2.1.2.jar:$HOME/.m2/repository/junit/junit/4.8.2/junit-4.8.2.jar:$HOME/.m2/repository/io/netty/netty-all/4.0.20.Final/netty-all-4.0.20.Final.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.2.2/jackson-core-2.2.2.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.2.2/jackson-databind-2.2.2.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.2.2/jackson-annotations-2.2.2.jar:$HOME/.m2/repository/io/vertx/vertx-platform/2.1.2/vertx-platform-2.1.2.jar org.vertx.ceylon.IntegrationTester
[debug] Deploying name : deployment-e6dd160e-af66-46e1-a9f0-6a31226056cf main: ceylon:deployerverticle/1.0.0 instances: 1
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.vertx.ceylon.IntegrationTester.run(IntegrationTester.java:60)
    at org.vertx.ceylon.IntegrationTester.main(IntegrationTester.java:38)
Caused by: org.vertx.java.platform.PlatformManagerException: Module io.vertx~lang-ceylon~null not found in any repositories
    at org.vertx.java.platform.impl.DefaultPlatformManager.getModule(DefaultPlatformManager.java:1441)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doInstallMod(DefaultPlatformManager.java:1430)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doLoadIncludedModules(DefaultPlatformManager.java:1301)
    at org.vertx.java.platform.impl.DefaultPlatformManager.loadIncludedModules(DefaultPlatformManager.java:1284)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doDeploy(DefaultPlatformManager.java:1689)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doDeployVerticle(DefaultPlatformManager.java:894)
    at org.vertx.java.platform.impl.DefaultPlatformManager.access$1500(DefaultPlatformManager.java:57)
    at org.vertx.java.platform.impl.DefaultPlatformManager$15.run(DefaultPlatformManager.java:520)
    at org.vertx.java.platform.impl.DefaultPlatformManager$14.run(DefaultPlatformManager.java:487)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)

Member

FroMage commented Sep 25, 2014

I'm trying to bypass maven to run it from the CLI but I fail:

$ java -cp target/classes:target/test-classes:$HOME/.m2/repository/io/vertx/vertx-core/2.1.2/vertx-core-2.1.2.jar:$HOME/.m2/repository/junit/junit/4.8.2/junit-4.8.2.jar:$HOME/.m2/repository/io/netty/netty-all/4.0.20.Final/netty-all-4.0.20.Final.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.2.2/jackson-core-2.2.2.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.2.2/jackson-databind-2.2.2.jar:$HOME/.m2/repository/com/fasterxml/jackson/core/jackson-annotations/2.2.2/jackson-annotations-2.2.2.jar:$HOME/.m2/repository/io/vertx/vertx-platform/2.1.2/vertx-platform-2.1.2.jar org.vertx.ceylon.IntegrationTester
[debug] Deploying name : deployment-e6dd160e-af66-46e1-a9f0-6a31226056cf main: ceylon:deployerverticle/1.0.0 instances: 1
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.vertx.ceylon.IntegrationTester.run(IntegrationTester.java:60)
    at org.vertx.ceylon.IntegrationTester.main(IntegrationTester.java:38)
Caused by: org.vertx.java.platform.PlatformManagerException: Module io.vertx~lang-ceylon~null not found in any repositories
    at org.vertx.java.platform.impl.DefaultPlatformManager.getModule(DefaultPlatformManager.java:1441)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doInstallMod(DefaultPlatformManager.java:1430)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doLoadIncludedModules(DefaultPlatformManager.java:1301)
    at org.vertx.java.platform.impl.DefaultPlatformManager.loadIncludedModules(DefaultPlatformManager.java:1284)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doDeploy(DefaultPlatformManager.java:1689)
    at org.vertx.java.platform.impl.DefaultPlatformManager.doDeployVerticle(DefaultPlatformManager.java:894)
    at org.vertx.java.platform.impl.DefaultPlatformManager.access$1500(DefaultPlatformManager.java:57)
    at org.vertx.java.platform.impl.DefaultPlatformManager$15.run(DefaultPlatformManager.java:520)
    at org.vertx.java.platform.impl.DefaultPlatformManager$14.run(DefaultPlatformManager.java:487)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

Ah, thanks, that worked!

Member

FroMage commented Sep 25, 2014

Ah, thanks, that worked!

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

So, apparently the metamodel is just not initialised at all. It's empty. How do you run this ceylon code?

Member

FroMage commented Sep 25, 2014

So, apparently the metamodel is just not initialised at all. It's empty. How do you run this ceylon code?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

I guess you reset the metamodel before that verticle is done running, is why.

Member

FroMage commented Sep 25, 2014

I guess you reset the metamodel before that verticle is done running, is why.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

This ceylon code is ran by the CeylonVerticle in this scenario with a module containing two Verticles. One of the two Verticles, deploys the same module but runs the other Verticle:

shared class VerticleImpl1() extends Verticle() {
  shared actual Promise<Anything> asyncStart(Vertx vertx, Container container) {
    return container.deployVerticle {
      main = "ceylon:deployerverticle/1.0.0";
      conf = JsonObject { "main"->"deployerverticle::VerticleImpl2" };
    };
  }
}
shared class VerticleImpl2() extends Verticle() {
  shared actual void start(Vertx vertx, Container container) {
    print("starting");
  }
}

So the same module is executed twice with different classloaders.

vietj commented Sep 25, 2014

This ceylon code is ran by the CeylonVerticle in this scenario with a module containing two Verticles. One of the two Verticles, deploys the same module but runs the other Verticle:

shared class VerticleImpl1() extends Verticle() {
  shared actual Promise<Anything> asyncStart(Vertx vertx, Container container) {
    return container.deployVerticle {
      main = "ceylon:deployerverticle/1.0.0";
      conf = JsonObject { "main"->"deployerverticle::VerticleImpl2" };
    };
  }
}
shared class VerticleImpl2() extends Verticle() {
  shared actual void start(Vertx vertx, Container container) {
    print("starting");
  }
}

So the same module is executed twice with different classloaders.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

Is the metamodel global for if there are several modules (not the same) ?

vietj commented Sep 25, 2014

Is the metamodel global for if there are several modules (not the same) ?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

so if the metamodel is cleared after execution, it would improve things. However there is the case the user deploys 2 Ceylons modules, then undeploys one of them. What happens ?

vietj commented Sep 25, 2014

so if the metamodel is cleared after execution, it would improve things. However there is the case the user deploys 2 Ceylons modules, then undeploys one of them. What happens ?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

So actually reset happens in stop:

  @Override
  public void stop() {
    if (verticle != null) {
      verticle.stop();
    }
    if (runner != null) {
      runner.cleanup();
    }
    Metamodel.resetModuleManager();
  }

vietj commented Sep 25, 2014

So actually reset happens in stop:

  @Override
  public void stop() {
    if (verticle != null) {
      verticle.stop();
    }
    if (runner != null) {
      runner.cleanup();
    }
    Metamodel.resetModuleManager();
  }
@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

Right, well, if every ceylon module is run in the same classloader for the language module, then they will share the metamodel, so you should only reset the metamodel after every ceylon module is stopped, no?

Member

FroMage commented Sep 25, 2014

Right, well, if every ceylon module is run in the same classloader for the language module, then they will share the metamodel, so you should only reset the metamodel after every ceylon module is stopped, no?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

Thing is that for now, it is not supposed to be invoked. In this case. Isn't it ?

vietj commented Sep 25, 2014

Thing is that for now, it is not supposed to be invoked. In this case. Isn't it ?

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

In any case, this is not a model loader bug.

Member

FroMage commented Sep 25, 2014

In any case, this is not a model loader bug.

@FroMage FroMage closed this Sep 25, 2014

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

What is not supposed to be invoked?

Member

FroMage commented Sep 25, 2014

What is not supposed to be invoked?

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

no no no :-)

vietj commented Sep 25, 2014

no no no :-)

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

is cleanup call when you run the case ? because cleanup is in stop not in in start

vietj commented Sep 25, 2014

is cleanup call when you run the case ? because cleanup is in stop not in in start

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

Metamodel.resetModuleManager()

vietj commented Sep 25, 2014

Metamodel.resetModuleManager()

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

I know it's in stop. I'm saying if you reuse the same CL for the Metamodel class across ceylon modules, then only reset the metamodel after EVERY module is stopped. Not just one. If one is still running it will need the metamodel.

Member

FroMage commented Sep 25, 2014

I know it's in stop. I'm saying if you reuse the same CL for the Metamodel class across ceylon modules, then only reset the metamodel after EVERY module is stopped. Not just one. If one is still running it will need the metamodel.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

I don't get why it does fail in that case if it's not called. as you say that it is because of that .

vietj commented Sep 25, 2014

I don't get why it does fail in that case if it's not called. as you say that it is because of that .

@FroMage

This comment has been minimized.

Show comment
Hide comment
@FroMage

FroMage Sep 25, 2014

Member

stop is called, I saw that in the logs. One of the two is stopped before the second runs, I assume the first one is stopped before the second runs.

Member

FroMage commented Sep 25, 2014

stop is called, I saw that in the logs. One of the two is stopped before the second runs, I assume the first one is stopped before the second runs.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 25, 2014

it does happen after the bug happens no ? I will double check.

vietj commented Sep 25, 2014

it does happen after the bug happens no ? I will double check.

@vietj

This comment has been minimized.

Show comment
Hide comment
@vietj

vietj Sep 26, 2014

I confirm it was indeed invoked (due to a silent failure in the nested Verticle). I removed it from the CeylonVerticle and I use it in a junit before rule as it was actually needed for unit tests.

vietj commented Sep 26, 2014

I confirm it was indeed invoked (due to a silent failure in the nested Verticle). I removed it from the CeylonVerticle and I use it in a junit before rule as it was actually needed for unit tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment