Hi,

I've tried to override the ActionKeys class in the ext-service plugin and it's working perfectly at my local install (Win 7). But as soon as I deploy this jar file to a debian server of our customer running the same Liferay 6.1.0-ce-ga1 tomcat bundle with the same oracle/sun jdk it's not working anymore and an exception is thrown that my newly added constants (into the ActionKeys class) can't be found.

As a workaround I've created a new class ActionKeysExt and put all of my new constants there. If I'm using this class in the jsps (after importing it at first in the init.jsp) it's working. So it seems to be a class loading issue but only for the ext-service.jar file, the ext-impl overrides are ok. The ext-service jar file is named so that it's listed before the portal-service.jar file. I've found a similar ticket LPS-29029 but without any feedback.

Has any of you discovered the same "feature" ??

Greets Oli

Hi Oli,

The problem is related to a class loading issue with the app server / servlet container. The order of loading files usually depends on the jvm, filesystem, OS and the weather.

You need to configure your app server to load the ext in the global class loader before the portal-service.jar. In tomcat, it can be done by creating a new folder and changing the common.loader property to load that folder earlier than lib/ext. Of course, this configuration is different in other application servers.

I hope it helps you to find the problem.

Cheers,
Zsolt

Hi Zsolt,

putting the ext-service.jar into the "lib / ext" folder has been working at least for liferay v5.2.3 (debian server too). So maybe there are some small changes/ differences to v6.1.0??!!?? Or simply the weather changed .

But thanks for your fast answer and the good explanation. I will try to setup a test server and modify the tomcat configuration accordingly.

As you've described it it's not directly a liferay bug but wouldn't it be better if Liferay would put the ext-service.jar into a seperate folder as default and change the order of the common.loader property?? Maybe you can rename the folder "lib / ext" to "lib / liferay" and then create an additional "lib / liferay-ext" folder. The loading order should then be liferay-ext first and then liferay afterwards. Changing this for all released tomcat bundles would prevent users like me to run into this hard-to-debug error.

What do you think?

Regards Oli

I thought tomcat loaded alphabetically? That's why in ROOT/WEB-INF/lib all of the jars from an EXT plugin are named ext-blah.jar so they always load before the portal-blah.jars...

Hi David,

It's true for the WEB-INF/lib, however the global classloader works differently based on our experiences. It's recommended to configure the classloader properly, so it won't be "luck".

The reason why it can change: some of the containers load the libraries by the operating system's file listing. It's usually abc order, however based on the OS and the filesystem it can be a different one (sometimes creation date).

I have not found any documentation about this when I was trying to find out the reason, if someone finds information about it, please feel free to share it

Zsolt

Hi Zsolt,

regarding my question from the following post from above:

I think the default configuration (of the tomcat bundle) should be "safe" to use so the user shouldn't be depended on the file system, the OS or the weather. Shall I create a ticket for this improvement idea or do you think it's not that useful?

Oli

Hi Oli,

You are right. Could you please open a ticket for it?

Thank you,
Zsolt

Hi Zsolt,

ok, no problem. Here is the jira ticket link: LPS-29847.
If you need additional info please let me know.

Greets Oli