1 Reply Latest reply on Feb 7, 2012 7:58 PM by Steven Davelaar-Oracle

    ApplicationResources properties file now writes to wrong directory

      Good afternoon, all,
      I have aother issue with the ApplicationResources_en.properties file... Here goes:

      When JHS originaly generated, we would get the ApplicationResources_en.properties file written to the location that it knows to look for it (">" represents a node in the file/folder tree):
      ManagementViewController>Application Sources>com.engenius.remis>managementview>ApplicationResources

      This was set with the value inserted for the "NLS Resource Bundle*" under "Internalization" in the App Def Editor. As part of a solution-finding-expedition related to the original issue I posted, one of our team members tried to hard-code the path to that folder:
      Original value was:

      Team members's new hard-coded solution:

      I've no idea how or why, but this caused JHS to write the ApplicationResources_en.properties file here (">" represents a node in the file/folder tree):
      ManagementModel>Application Sources>com.engenius.remis>model>queries>ManagementViewController>src>com>engenius>remis>managementview>ApplicationResources_en.properties

      Now, no matter what you put for that "NLS Resource Bundle*" value (either the original value, or something new), it creates a new node path in the MODEL (where the running App will Never look)! It's now stuck in the model!!

      Originally, the issue had been compounded, because now anyone who opened that .jws on their computer gets their ApplicationResources file written into the model whenever the model name is ManagementModel, and the View Controller is called ManagementViewController, even if they delete the app, delete the entire folder, unzip a backup, and open a prior state of the application (before this issue existed)!! It's as if the jDev/JHS application itself has hardcoded that path to go into the model portion of the App, no matter what...

      The problem strecthes futher than that now, other modules randomly generate the file to the model now... Since the first time it happened, I've now seen this in 2 other modules where we haven't changed that value, and I fear we may not be able to get it to go back to normal before the final deployment, without recreating from scratch with a new naming convention (and there's no guarantee the issue won't mysteriously repeat itself)... We can copy/paste the contents of the one in the wrong location into the right one to get our new EDIT/NEW/VIEW tags, but that still doesn't fix the cause of the issue...

      Any insight into this issue would be greatly appreciated... and many thanks for any replies....

      Happy Thoughts,

      "People are about as happy as they make up their minds to be."
      -- Abraham Lincoln