[MAGNOLIA-2471] Make Magnolia run on Websphere Application Server 6.1 under RAD (IBM Rational Application Developer) 7.5 Created: 09/Nov/08  Updated: 23/Jan/13  Resolved: 09/Nov/08

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.6.3
Fix Version/s: 4.0

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-2476 Rework ClasspathResourcesUtil in orde... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 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.



 Comments   
Comment by Fabrizio Giustina [ 09/Nov/08 ]

Committed to trunk.

This fix may also have the nice side effect to make Magnolia work on Websphere also when modules are deployed as ear shared libraries instead than in the standard webapp lib folder (something that looks unfortunately pretty common when working with Websphere)

Comment by Philipp Bracher [ 14/Nov/08 ]

For now we can live with that. My experience in the past was that when ever we tried to be nice to yet another container setup the code starts to fail for one it worked for before the change.

In the future we should probably use different implementations of a ClasspathResolver configured by magnolia properties. This can then be part of the container specific modules and the module can change the default implementation in its descriptor by using the module properties.

We used the same mechanism for similar problems.

The user has just to drop the extra jar and everything works as expected. But still the code is not cluttered with container related code.

Comment by Fabrizio Giustina [ 14/Nov/08 ]

well, actually the whole ClasspathResourcesUtil is written in a way that is totally container dependant. Looking at it you can see several workaround added specifically for tomcat, jetty, different URL sintaxes...

IMHO a different, configurable classpathResolver is not a good path too. I am sure it can be rewrite the whole think using standard apis (so: without looking explicitely for folders called WEB-INF/lib or WEB-INF/classes which is really bad). I know for example that Spring is able to do the same think (importing for example any /spring/*.xml) file from the classpath without using anything so hardcoded.

I'll open a new task in jira about this and I'll try to investigate, WDYT?

Comment by Philipp Bracher [ 14/Nov/08 ]

As I said we can live with it for now. But spying around how others solve that is definitely not a bad idea

Generated at Mon Feb 12 03:37:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.