Uploaded image for project: 'Fuse Tooling'
  1. Fuse Tooling
  2. FUSETOOLS-1267

Properties editor for File endpoint converts relative paths to absolute paths so files are not read

    XMLWordPrintable

Details

    • Hide

      Run the attached CBRroute project as a Local Camel Context (without tests)

      Show
      Run the attached CBRroute project as a Local Camel Context (without tests)

    Description

      I cannot get my project to run as a Local Camel Context with or without tests, even after:
      Deleting my old repository;

      • Creating a new workspace (workspace99);
      • Creating a new CBRroute project that uses the 2.14.0 version of camel-
        archetype-blueprint in the new workspace;
      • Updating the pom.xml file in the new workspace to depend on commons-io
        (for the customized JUNit test case I created); and
      • Copying the camelContext.xml routing file, the
        CBRroute/src/data/message#.xml (1 through 6) files, and my customized
        camelContextXmlTest.java file from the old workspace into the new one.

      In the Properties editor for the Filesystem (file) component, the Uri field on the Generic tab and the Path field on the File Binding tab are auto filled. In my case, Uri contains file:/Applications/jbdevstdio/studio/jbdevstudio.app/Contents/MacOS/src/data/?noop=true, and Path contains /Applications/jbdevstdio/studio/jbdevstudio.app/Contents/MacOS/src/data/.

      These properties seem to be hardcoded because when I try to change them they revert back. My new 2.14.0-based project lives in jmurphey/workspace99/CBRroute/...

      Now, when I try to run my camelContext.xml file as a Local Camel Context (without tests), the runtime starts up the routes (there are two in the routing context), but then it hangs, never reading any of the files from the CBRroute/src/data dir. My customized JUnit test case fails because it doesn't get the message body it expects.

      I tried changing the Uri string on the Generic tab to file:/src/data?noop=true, which worked just once, delivering all 6 messages to their correct destinations. But the runtime spawned lots of error messages that it could not find/connect to the JMX connector.

      Attachments

        Activity

          People

            lheinema@redhat.com Lars Heinemann
            jmurphey_jira Jane Murphey (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: