Hitachi Vantara Pentaho Community Forums
Results 1 to 2 of 2

Thread: Corrupted Solutions Page

  1. #1
    Join Date
    Oct 2007
    Posts
    18

    Default Corrupted Solutions Page

    I am getting a corrupted solutions page (Navigate.jsp) in certain
    circumstances on my Pentaho system (1.6.0.GA) running under
    Tomcat 5.55.5 with Postgres 8.2.

    The problem occurs if I do the following:

    - Install Pentaho with the sample solution.

    - Log on and do a Go -> Solutions. At this point the solutions page
    displays correctly, showing the samples.

    - Now update the modification time of metadata.xmi (using touch) in the
    Pentaho solutions main directory (or update the mod time of anything else
    in the directory).

    - Restart Tomcat.

    - Log on and do Go -> Solutions again. Now the solutions page is corrupted.
    An example is attached. In brief, the title for nearly all folders is
    displayed as "Samples" and the description as "A collection of examples ...".
    In other words, the folders are using the title and description intended
    for the solution itself.

    This problem is significant since it also happens when generating waqr
    reports, which change files in the solutions directory.

    After some investigation, the problem is related to the localization done by
    method getLocaleString of class SolutionsRepository.java. The method uses
    URLClassLoader and ResourceBundle to find the correct index.properties file
    from which it obtains the title and description text. Even though it appears
    that getLocaleString is correctly calling the URLClassLoader and
    ResourceBundle methods, the wrong text is returned by
    ResourceBundle.getString(). In most cases, the title and description is
    coming from the index.properties file of the directory above the directory
    from which it should be.

    I am stumped as to why this is happening. A minor change in the solutions
    directory seems to be confusing URLClassLoader / ResourceBundle. I wonder
    if it is related to Tomcat, in that there might be an unfortunate interaction
    between Tomcat's class loading and URLClassLoader.

    Does anyone have any ideas?

    Regards,
    Larry
    Attached Files Attached Files
    Last edited by larrybennett; 02-05-2008 at 06:31 AM. Reason: clarify

  2. #2
    Join Date
    Oct 2007
    Posts
    18

    Default

    I think I have figured out what the problem is. In method getLocaleString
    of class SolutionsRepository, the call to create a new URLClassLoader
    does not specify a parent class loader (i.e. does not pass second parameter)
    and thus gets the default class loader. Since class loaders delegate
    to their parent before doing the job themselves, this appears to be
    causing the wrong properties file to get loaded in certain circumstances
    under Tomcat.

    I changed getLocaleString to pass null as the parent class loader and this
    seems to fix the problem. I can't see any reason that it is desirable to
    delegate to a parent class loader in this situation.

    I will test a bit more and if it continues to work will open a Jira case with
    my fix.

    Regards,
    Larry

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.