How can a package rename cause a dependency loop?

[mdhirsch30345]

I am confused and stuck.  I am trying to rename a java package which should be simple.  I have a package com.termalabs.ac and I'm renaming it com.termalabs.ti.  I used Intellij's refactoring tools to do that.  The java all compiles, but when I try to build my resulting app I get:

   Computing all possible rebind results for 'org.jboss.errai.ioc.client.Bootstrapper'

java.util.concurrent.ExecutionException: org.jboss.errai.ioc.rebind.ioc.exception.UnsatisfiedDependenciesException:  @> com.termalabs.ti.client.widgets.filters.StateFilterController

- parameter jawsJerseyService could not be satisfied for type: com.termalabs.ti.rest.JawsJerseyService

  Message: your object graph has cyclical dependencies and the cycle could not be proxied. use of the @Dependent scope and @New qualifier may not produce properly initalized objects for: com.termalabs.ti.rest.JawsJerseyService

         Offending node: com.termalabs.ti.client.widgets.filters.StateFilterController

         Note          : this issue can possibly be resolved by making com.termalabs.ti.rest.JawsJerseyService proxyable. Introduce a default no-arg constructor and make sure the class is non-final.

If I roll my changes back everything compiles again.

I've done a clean to erase both the build directory and the .errai directory to try to make the build be completely clean.

The message is correct that StateFilterController does depend on JawsJerseyService, which in turn has a couple of dependencies, but the dependency chains all terminate quickly.

I feel like there are build artifacts sitting around somewhere that I don't know about.  I don't understand how my simple refactoring could be causing this problem, otherwise, but I don't know where they could be.

Any clues would be greatly appreciated.

Michael

[csa]

Hi Michael,

We are processing all translatable types known to GWT to generate our IOC bootstrapper. Whether a type should be translatable to JavaScript is decided based on the package the type is in. So, one explanation I have is that, after your refactoring, there are either more or less translatable types available.

Another explanation would be that there's something wrong with your build.

Did you try the suggested workaround, btw: "this issue can possibly be resolved by making com.termalabs.ti.rest.JawsJerseyService proxyable. Introduce a default no-arg constructor and make sure the class is non-final"?

Cheers,

Christian

[mdhirsch30345]

Thanks for the reply, Christian.

Can you explain who merely changing the package name would make more/fewer types be translatable?  I don't understand how what I did could have that effect.

I did notice the suggestion to make JawsJersetService proxyable.  But I need it to have injected arguments.  And, again, how did that change by changing the package name?  Some have suggested that the old name, "ac", comes alphabetically before the new name, "ti"...

Thanks,

Michael