Ext Environment - class loader

[Rui Horta, modificado hace 11 años.]

Hello Guys,

I have an installation of Liferay 5.2 EE SP5 in a weblogic11g(10.3.6) server using Oracle database 11g Release2 as database. I'm using the extension environment for this version and I have some questions that was asked by my client.
We had to do some override to core classes in portal-impl, according to the post http://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/developing-an-ext-plug-4 where it says:
  Replacing core classes in portal-impl
If you really need to change the core portal-impl class and this class can not be Replaced in any configuration file, then the best way to avoid conflicts and merge easily with the new portal version is to:
-Rename original class (eg DeployUtil → MyDeployUtil)
-Create a new subclass with the old name (eg DeployUtil extends MyDeployUtil)
........
........

This was the procedure that we use, we have created a class with the same name and the existing package that extends the old class which has since been renamed.
So far so good, however we are left with two classes with the same name and package in the classpath.

Note:The JEE specification Webapp Does Not Specify in order Which jar files contained in the WEB-INF/lib directory are loaded.

With this in mind which class it is called and why? Is this the correct procedure to extend the Liferay core classes?

I discovered an issue created http://issues.liferay.com/browse/LPS-16082 talking about this but ok, assuming that this problem exists for the extension environment how works the fix packs given by Liferay in this same type of environment ? On a fix pack that is done an override in the same way of a class in portal-impl, how it was guaranteed that this fix pack is being called, or classes within this fix pack are being called?

OK, even assuming that the server loads the jar to the classpath by alphabetical order, it is guaranteed that the first class is found it will be used?

Thanks,

Regards

[Milen Dyankov, modificado hace 11 años.]

Hi Rui,
please note that both the documentation and the issue you are referring to are for Liferay 6.1.x while you are using 5.2.x
While EXT plugin introduced in 6.0 provides the same functionality, technically it is not the exact same thing as EXT environment available in 5.2
The EXT plugins are hot deployed while EXT environment effectively creates a customized Liferay version by merging your code with the portal's code.

Having that said, I don't think you should ever end up having two classes with the same name and package in the classpath! Can you elaborate a bit more on how this happens in your case?

[Vitor Silva, modificado hace 11 años.]

From my understanding on the question:
Extension Environment of 5.2 has this folder structure:
tools
sql
modules
lib
ext-web
ext-impl
ext-servicw
ext-lib
classes

I think Rui copied a class he wanted to override from the source code renamed it to My... and extended it with the original name inside the ext-impl
Both classes will be shipped in the ext-impl.jar.
portal-imp.jar will contain the original class hence the classloader problems and the question about alphabetic loading.
Was this the right procedure in 5.2?
I am actually not sure..

[Milen Dyankov, modificado hace 11 años.]

If I remember right (it's been a while since I used 5.2) if you copy a class to ext-impl and change it then it should overwrite the original class when the package is created. Unlike EXT plugins, EXT environment builds the whole Liferay again so the original portal-imp.jar should not be there (a new one will be build containing merged changes)! It could be however that WL is caching it somewhere or .... That's way my question about how come there are 2 classes with the same name and package in the classpath. If they are both in the WAR file - then something's wrong with the build. If the WAR is OK then it's WL.

[Vitor Silva, modificado hace 11 años.]

I have tested this a few moments ago in 5.2.4 ..
If you create a java class in ext-impl that has the same name as the one in portal-impl and execute the ant to build the environment, one class in ext-impl will exist and another in portal-impl will exist also..

[Milen Dyankov, modificado hace 11 años.]

Never been proven wrong so fast before ;)

Then I see two options. Modify the ant script to either

• rename the ext-impl to _ext-impl or _wls_ext-impl after it is build as Tomas suggested in http://issues.liferay.com/browse/LPS-16082
• scan the files in ext-impl and remove the ones with that same path and name in the original portal-impl before copying it.

[Daniel Reuther, modificado hace 11 años.]

Well, Ext environments and Ext plugins aren't that different in this case. They both place additional JAR files in the respective class loader directories.
If you want to overwrite classes then you usually do this by using the same package and class name, yes. Admittedly this isn't always unproblematic—different AS handle class loading differently.

Using Tomcat, you can be pretty sure that it works because it orders the JARs by alphabet (see org.apache.naming.resources.FileDirContext). I'm not completely sure about WL right now but worst-case you may have to put the JARs in a class loader directory that you *know* will be loaded first.

For Fix Packs the story is totally different though... because it is overwriting the files in portal-impl.jar/portal-service.jar directly.

Daniel

[Rui Horta, modificado hace 11 años.]

Hello Guys,

Thank you all for your responses.

Vitor - yes, is that what i am doing.

Milen - Vitor is right, when we build the war package in extension environment both jars are copied to WEB-INF/lib, ext-impl.jar only have the changed classes, portal-impl.jar have all originally classes.

Daniel - So if i understood if the JARs are loaded by alphabet order we don´t have any problem? because the first found class is the class that will be used, so ext-impl.jar appears first that portal-impl and the overrided class was found first that the original, right? About the fix packs, you say that they override the original files portal-impl.jar and portal-service.jar, so when we download for example /5.2.9/lpe7429-ee5209-patch-jdk5.zip and place this jar patch in the Liferay WAR, located here: C:\$WEBLOGIC_HOME\user_projects\domains\liferay\servers\$SERVER_NAME\stage\$LIFERAY_WAR and we Start Weblogic, what happens is that the original file was overriden?

One more time thank you all for you responses.

[Rui Horta, modificado hace 11 años.]

Hi again,

According with https://github.com/topolik/extlet/wiki/How-The-Extlet-Works

Explanation:
In the EXT there is ext-impl.jar file. This file is searched by the Tomcat’s WebappClassLoader before portal-impl.jar, because the jars are retrieved from the FileDirContext alphabetically (and the letter e is simply before the p For further info see the Tomcat’s WebappLoader.setResources(), FileDirContext.list(File file), WebappClassLoader.addJar(String jar, JarFile jarFile, File file) and WebappClassLoader.findResources(String name) methods.

If weblogic load the jars alphabetically everything works well? It is guaranteed that the first class to be found is the class loading?

Thanks

Rui Horta

[Daniel Reuther, modificado hace 11 años.]

Rui Horta:

So if i understood if the JARs are loaded by alphabet order we don´t have any problem? because the first found class is the class that will be used, so ext-impl.jar appears first that portal-impl and the overrided class was found first that the original, right?

Well, that's true for Tomcat. It's not necessarily true for all AS.

Rui Horta:

About the fix packs, you say that they override the original files portal-impl.jar and portal-service.jar, so when we download for example /5.2.9/lpe7429-ee5209-patch-jdk5.zip and place this jar patch in the Liferay WAR, located here: C:\$WEBLOGIC_HOME\user_projects\domains\liferay\servers\$SERVER_NAME\stage\$LIFERAY_WAR and we Start Weblogic, what happens is that the original file was overriden?

Oh, we seem to have a confusion about the terms
Fix Packs are the files you install using the patching tool—we're using that since 6.0 SP2 only. The patches you describe work the same way Ext does... that is, the behavior is not consistent across all AS and may require workarounds. But again, I'm not completely sure about WL just now. If it works for you, you shouldn't worry about it too much though ;)

Daniel

[Rui Horta, modificado hace 11 años.]

Daniel,

Ah ok, my terms were wrong, although for older versions of Liferay, they are available on the website in the same place (http://www.liferay.com/group/customer/downloads/patches) in the customer area for enterprise versions.
My problem is that the client is telling me that our environment extension is working by pure luck, because it is not guaranteed that the classes to be performed are the right ones.
I'm just trying to find reasons to explain that the way we are working is the proper, recommended by Liferay and that the environment is working because that is how it must work.

Regards,

Rui Horta

[Vitor Silva, modificado hace 11 años.]

There is nothing in the specification of a classloader that says it needs to load the classes alphabetically.
In fact it depends on how the classpath is assembled. Example if the manifest is filled with the classpath this should be the order.
Any upgrade on the server may end up this technique not working. I dont know for sure if the Weblogic version used is working like we hope. As far as being the correct Liferay way, I think it is, since the fixpacks are shipped in that way for 5.2 version (although probably we changed the logic for a reason)

[Vitor Silva, modificado hace 11 años.]

Also I think there is a classloader filter in the weblogic-application.xml that can be used
<prefer-application-packages>
<package-name>ext-impl*</package-name>
</prefer-application-packages>
From my understanding these will always be loaded first..
There is a war application (CAT) that can be installed in the weblogic server that analyses the classloading conflicts and I think it suggests some solutions (see http://docs.oracle.com/cd/E21764_01/web.1111/e13706/classloading.htm#BABHJGJJ)
Hope this helps,
Vitor

[Milen Dyankov, modificado hace 11 años.]

Rui Horta:

My problem is that the client is telling me that our environment extension is working by pure luck, because it is not guaranteed that the classes to be performed are the right ones

And this may be in fact the case for Weblogic. Moreover it may change with the next Weblogic version as Vitor has already pointed out. However while not guaranteeing the order and which class is actually loaded in case there is more than one, I expect the behavior to be at least consistent. Meaning, whatever it is, it is always the same and not random every time the server starts. So once you got it working it should work the same way until you change the server version.

If you want to play it safe however, you can try to modify the ant script for the EXT to make sure you don't have duplicate classes on classpath (see my previous post). If your subscription includes support, you will need to check with our support team whether they are actually going to support this but I personally don't see why not.

[Rui Horta, modificado hace 11 años.]

Vitor,

I have already installed that application before and i saw that the jars in classpath are loaded alphabetically, and to this day we have never had any problems, it was even a question asked by the client.
I think we can take one of the solutions suggested by the link you sent it to ensure that the order is always the same.
I have to see what is the best way to do this, if is prefer-application-packages related packages are classloader-structure or even the MANIFEST.
Thanks for the tips Vitor.

Milen,

So far we have never had problems loading order and I think it was always the same, now that I see that tool i saw that was always in alphabetical order.
Thank you for your help, however I will check with the client the kind of support that they have to see what is possible to do.

One more time thank you.

Regards,

Rui Horta