Announcement Announcement Module
No announcement yet.
Problem with CommandManager in Valkyrie Simple Sample Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with CommandManager in Valkyrie Simple Sample

    I am not git nor maven user, this is the first time for me with those tools, anyway i want to try valkyrie since i am a full user of spring rcp.

    It was quite easy to compile with maven, the only problem was with jide-oss dependency, valkyrie need version 2.10.4, but it is not in the repositories and i could not find it on the web, so i edited the pom file to use version 2.11.2 of jide-oss and it compiled very well. I created eclipse projects with mvn eclipse:eclipse, and i could open them in eclipse without any problem, i just had to create a M2_REPO var poiting to maven repository.

    Once i have all configured, i try simple sample, but this is when the error comes out. Making some debugging, valkyrie first get a DefaultCommandManager from SimpleSampleApplicationConfig, since the ApplicationConfig requires this manager, but it is declared as lazy (the whole object not just the method) and i could not find where it is requiered so i dont know why it is instantiated. Anyway after that, SimpleSampleApplicationConfig extending AbstractApplicationConfig create the ApplicationLifecycleAdvisor, which requires the CommandConfig class for creating the applicationWindowCommandManager, which is an instance of commandManager, and for that ApplicationWindowCommandManager extending DefaultCommandManager es returned. But in the method that instantiates this we have:

    //AbstractCommandConfig (parent class)
    public ApplicationWindowCommandManager applicationWindowCommandManager() {
        return new ApplicationWindowCommandManager();
    //SimpleSampleCommandConfig (child class)
    public ApplicationWindowCommandManager applicationWindowCommandManager() {
        ApplicationWindowCommandManager applicationWindowCommandManager = super.applicationWindowCommandManager();
        applicationWindowCommandManager.setSharedCommandIds("newContactCommand", "propertiesCommand", "deleteCommand");
        return applicationWindowCommandManager;
    The instantiation is with new operator, not with spring, so the @Autowired properties of the DefaultCommandManager (the base class for ApplicationWindowCommandManager) are never injected. And when setSharedCommandIds are called, obviusly there is not commandConfigurer for those commandIds, so i get a NullPointerException.

    Also i am not a spring 3 expert, i want to use it, thats why i want to learn valkyrie too, but whi this error i dont know what to do. I tried commenting out the setting commands ids line, i have another exception, i try to put the commandConfigurer property @Autowired property in AbstractCommandConfig hoping this will get injected, but not. I was reading other post in which Lieven Doclo talks aboun apectj weaving and tools, i figured out that tools was not in the classpath, and i put it but nothign changes, and well it is obiusly, becausethe object is manually instantiated and for that reason commandConfigurer are not injected and then get the null pointer exception.

    What is strange for me is that this error is so obvius, but i can bet that this work very good for Lieven, so i am short in ideas, what am i missing?, a jar? a configuration?

    Thanks to everyone for reading my post.

  • #2
    This sounds like one of the rare cases where deterministically calling GC.Collect() is the right thing to do. The ordinary argument against it is that the garbage collector is smarter than you are. But when you're dealing with WeakReference objects, you enter territory where you may know something that the garbage collector doesn't. Kicking off garbage collection is certainly better than clearing _requerySuggestedHandlers - among other things, it won't do anything to the WeakReference objects that point to controls that are still alive.

    I'd choose this over trying to figure out how to suppress RequerySuggested, since that would screw up the behavior of those commands that you still care about.