James Server
  1. James Server
  2. JAMES-803

Add ability to load resources from the classpath instead of the file system

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: Trunk
    • Fix Version/s: 3.0-M1
    • Component/s: James Core
    • Labels:
      None

      Description

      Currently lots of components try to get their configuration files from the filesystem, but most of the time it's simpler to get from the classpath.

      1. loading-from-the-classpath.patch
        15 kB
        Zsombor
      2. loading-from-the-classpath-spring.patch
        1 kB
        Zsombor
      3. bayes.patch
        3 kB
        Zsombor Gegesy
      4. spring.patch
        1 kB
        Zsombor Gegesy

        Activity

        Zsombor created issue -
        Hide
        Zsombor added a comment -

        The patch which enables to load resources from the classpath.

        Show
        Zsombor added a comment - The patch which enables to load resources from the classpath.
        Zsombor made changes -
        Field Original Value New Value
        Attachment loading-from-the-classpath.patch [ 12363569 ]
        Hide
        Zsombor added a comment -

        The patch file for the spring-deployment module.

        Show
        Zsombor added a comment - The patch file for the spring-deployment module.
        Zsombor made changes -
        Attachment loading-from-the-classpath-spring.patch [ 12363570 ]
        Hide
        Stefano Bagnara added a comment -

        I wrote the FileSystem service to encapsulate the service and remove some avalon specific dependency from most modules.

        I think the best approach to this change would be:

        1) Add the getResource method to the interface that simply return an InputStream instead of a file.
        2) Create the default implementation of the avalon file system to call the getFile and simply provide the stream for that file
        3) Change the FileSystem users to use getResouce instead of getFile when they don't need a File instance.

        Then I would probably leave to the spring implementation the loading of resources from the classpath: in a phoenix environment IMHO it make sense to keep using the "phoenix way".

        So, this is similar, but done in 2 separate steps (refactoring of the api first, new features after): what do you think?

        Show
        Stefano Bagnara added a comment - I wrote the FileSystem service to encapsulate the service and remove some avalon specific dependency from most modules. I think the best approach to this change would be: 1) Add the getResource method to the interface that simply return an InputStream instead of a file. 2) Create the default implementation of the avalon file system to call the getFile and simply provide the stream for that file 3) Change the FileSystem users to use getResouce instead of getFile when they don't need a File instance. Then I would probably leave to the spring implementation the loading of resources from the classpath: in a phoenix environment IMHO it make sense to keep using the "phoenix way". So, this is similar, but done in 2 separate steps (refactoring of the api first, new features after): what do you think?
        Bernd Fondermann made changes -
        Assignee Bernd Fondermann [ brainlounge ]
        Hide
        Zsombor added a comment -

        The provided patch file contains the changes which suggested by Stefano. I'm happy that we concluded to the same solution

        Show
        Zsombor added a comment - The provided patch file contains the changes which suggested by Stefano. I'm happy that we concluded to the same solution
        Hide
        Stefano Bagnara added a comment -

        The main difference (excluding the 2 steps approach) is that for avalon I would simply use this implementation:
        + public InputStream getResource(String url) throws IOException

        { + return new FileInputStream(getFile(url)); + }

        removing all of the checks for the classpath.
        I would leave it to the spring solution as it is more likely to use a different packaging and a different way to use configurations.

        Thank you for the idea!

        Show
        Stefano Bagnara added a comment - The main difference (excluding the 2 steps approach) is that for avalon I would simply use this implementation: + public InputStream getResource(String url) throws IOException { + return new FileInputStream(getFile(url)); + } removing all of the checks for the classpath. I would leave it to the spring solution as it is more likely to use a different packaging and a different way to use configurations. Thank you for the idea!
        Hide
        Bernd Fondermann added a comment -

        Step 3) is now completed for all SQL Query loaders (except JDBCBayesianAnalyzer).

        Show
        Bernd Fondermann added a comment - Step 3) is now completed for all SQL Query loaders (except JDBCBayesianAnalyzer).
        Hide
        Zsombor Gegesy added a comment -

        There is one little problem with the current code, it's explicitly checks that the config file name is starts with file://, so the components are not usable, so please change the code

        • if (!sqlFileName.startsWith("file://")) {
          + if (!sqlFileName.startsWith("file://") && !sqlFileName.startsWith("classpath:")) {
          throw new ConfigurationException
        • ("Malformed sqlFile - Must be of the format 'file://<filename>'.");
          + ("Malformed sqlFile - Must be of the format 'file://<filename>' or 'classpath:<resource>'.");

        in the following files:

        core-library/src/main/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java core-library/src/main/java/org/apache/james/vut/JDBCVirtualUserTable.java core-library/src/main/java/org/apache/james/mailrepository/JDBCMailRepository.java

        Show
        Zsombor Gegesy added a comment - There is one little problem with the current code, it's explicitly checks that the config file name is starts with file:// , so the components are not usable, so please change the code if (!sqlFileName.startsWith("file://")) { + if (!sqlFileName.startsWith("file://") && !sqlFileName.startsWith("classpath:")) { throw new ConfigurationException ("Malformed sqlFile - Must be of the format 'file://<filename>'."); + ("Malformed sqlFile - Must be of the format 'file://<filename>' or 'classpath:<resource>'."); in the following files: core-library/src/main/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java core-library/src/main/java/org/apache/james/vut/JDBCVirtualUserTable.java core-library/src/main/java/org/apache/james/mailrepository/JDBCMailRepository.java
        Hide
        Bernd Fondermann added a comment -

        Zsombor, thanks for testing. I will look into this this week.

        Show
        Bernd Fondermann added a comment - Zsombor, thanks for testing. I will look into this this week.
        Hide
        Zsombor Gegesy added a comment -

        The best would be omit the checking, and rethrow the exception which comes from the 'FileSystem' implementation.

        Show
        Zsombor Gegesy added a comment - The best would be omit the checking, and rethrow the exception which comes from the 'FileSystem' implementation.
        Hide
        Bernd Fondermann added a comment -

        now works in both deployments, James/Phoenix and James/Spring

        Show
        Bernd Fondermann added a comment - now works in both deployments, James/Phoenix and James/Spring
        Bernd Fondermann made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Zsombor Gegesy added a comment -

        The patch for BayesianAnalyzer to fix loading from the classpath

        Show
        Zsombor Gegesy added a comment - The patch for BayesianAnalyzer to fix loading from the classpath
        Zsombor Gegesy made changes -
        Attachment bayes.patch [ 12367227 ]
        Hide
        Zsombor Gegesy added a comment -

        This modification at least enables to locate the referenced xml entities from a folder from a classpath. The correct patch would be a full xml-entity resolver, but I don't want to dig too deep, for this little problem.

        Show
        Zsombor Gegesy added a comment - This modification at least enables to locate the referenced xml entities from a folder from a classpath. The correct patch would be a full xml-entity resolver, but I don't want to dig too deep, for this little problem.
        Zsombor Gegesy made changes -
        Attachment spring.patch [ 12367228 ]
        Bernd Fondermann made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Norman Maurer made changes -
        Assignee Bernd Fondermann [ brainlounge ] Norman Maurer [ norman ]
        Hide
        Norman Maurer added a comment -

        done

        Show
        Norman Maurer added a comment - done
        Norman Maurer made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Fix Version/s 3.0-M1 [ 12314294 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12410365 ] Default workflow, editable Closed status [ 12566239 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12566239 ] jira [ 12581612 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        41d 11h 11m 1 Bernd Fondermann 20/Sep/07 20:54
        Resolved Resolved Reopened Reopened
        20d 8h 55m 1 Bernd Fondermann 11/Oct/07 05:49
        Reopened Reopened Resolved Resolved
        841d 4h 40m 1 Norman Maurer 29/Jan/10 09:29

          People

          • Assignee:
            Norman Maurer
            Reporter:
            Zsombor
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development