Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-2471

Make Magnolia run on Websphere Application Server 6.1 under RAD (IBM Rational Application Developer) 7.5

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Fixed
    • Major
    • 4.0
    • 3.6.3
    • core
    • None

    Description

      Magnolia seems unable to startup properly when run inside the Websphere development environment, in RAD 7.5. It just isn't able to find any module xml in the classpath so the initial bootstrap is never triggered.

      After digging a bit, I found out that the default settings for websphere publishing in RAD 7.5 make webapps run from the workspace, without really publishing jars to the server. This is pretty identical to the optional "Serve modules without publishing" option in the eclipse tomcat adapter that we already support (mh, looks like ibm borrowed the idea ).

      The bad thing is that the classloader is not set up in a way similar to the tomcat one (so it doesn't work at the moment) and that switching back to a standard deployment mode looks unusable when working with ear archives (really, you can go out for lunch each time you change a line of code).

      This is the code that used to work for tomcat, from info.magnolia.cms.util.ClasspathResourcesUtil:

              // if the classloader is an URLClassloader we have a better method for discovering resources
              // whis will also fetch files from jars outside WEB-INF/lib, useful during development
              if (cl instanceof URLClassLoader) {
                  // tomcat classloader is org.apache.catalina.loader.WebappClassLoader
                  URL[] urls = ((URLClassLoader) cl).getURLs();
                  for (int j = 0; j < urls.length; j++) {
                      final File tofile = sanitizeToFile(urls[j]);
                      collectFiles(resources, tofile, filter);
                  }
                  return (String[]) resources.toArray(new String[resources.size()]);
              }
      

      Unfortunately the classloader used by WAS doesn't implement any standard (read: non IBM) interface, but at least it clearly exposes its virtual classpath.
      This classloader is a com.ibm.ws.classloader.CompoundClassLoader which implements com.ibm.ws.classloader.WsClassLoader, who has a nice getClassPath() method.

      So, although we can't dependend on com.ibm.ws.classloader.WsClassLoader directly, we can pretty easily read the classpath as a bean property, going back to the default method if the classloader doesn't expose it... supporting it doesn't look so bad.

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                fgiust Fabrizio Giustina
                fgiust Fabrizio Giustina
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Task DoD