6.2.1-ce-ga2-security-3.0.zip - Installation problem

[George Oakley, modifié il y a 9 années.]

Hi,

I downloaded /6.2.1 GA2/6.2.1-ce-ga2-security-3.0.zip and installed it on my portal LF 6.2.1 + Glassfish. I did everything according to the instructions README.txt .

I get an error. Logs in attachment. Any ideas?

[Denis Signoretto, modifié il y a 9 années.]

Hi George,

errors in attached log are related with missing of class com.liferay.portal.model.AttachedModel in classpath.
This class it's contained in portal-service.jar. Can you check you still have portal-service.jar in your shared libraries directory and that it contains AttachedModel class (e.g. /glassfish-3.1-web/glassfish3/glassfish/domains/domain1/lib)?

[George Oakley, modifié il y a 9 années.]

Hi Denis,

Thanks for reply. Yes, i checked it. It is still in: ..\glassfish\domains\domain1\lib\portal-service.jar .
I copied ext-portal-service.jar to ..\glassfish\domains\domain1\lib\ext .

I checked another version 6.2.1-ce-ga2-security-2.0.zip in same environment and it looks fine - no errors appear in logs file.

Is it possible that 6.2.1-ce-ga2-security-3.0.zip in http://sourceforge.net/projects/liferay-patches/files/6.2.1%20GA2/ is corrupted?

[Denis Signoretto, modifié il y a 9 années.]

I'm not a really expert of Glassfish. I suppose the right place where to put ext-portal-service.jar for Glassfish it's glassfish\domains\domain1\lib and not ..\glassfish\domains\domain1\lib\ext (that it's reserver for JDK extensions).

[David H Nebinger, modifié il y a 9 années.]

Denis Signoretto:

not ..\glassfish\domains\domain1\lib\ext (that it's reserver for JDK extensions).

No, Liferay uses lib/ext on many app containers to isolate Liferay-provided jars from the app server's jars.

[James Falkner, modifié il y a 9 années.]

David H Nebinger:

Denis Signoretto:

not ..\glassfish\domains\domain1\lib\ext (that it's reserver for JDK extensions).

No, Liferay uses lib/ext on many app containers to isolate Liferay-provided jars from the app server's jars.

Hey guys, I get the same thing on GF.. investigating.. I'm sure it'll come down to classloading magical differences between app servers.

[Denis Signoretto, modifié il y a 9 années.]

James Falkner:

Hey guys, I get the same thing on GF.. investigating.. I'm sure it'll come down to classloading magical differences between app servers.

Hi James,

after some investigation[1] I've seen glassfish has multiple classloaders organized as described in Glassfish Class Loader Hierarchy[2]. As you can see, "domain-dir/lib/ext" directory it's managed by Extension class loader while "domain-dir/lib" it's managed by Common class loader that it's at lower level compared to Extension class loader). As reported in [1] domain-dir/lib it's the preferred place for a library to be made available to the whole domain.
I guess the issue probably arises when some classes loaded by Extension classloader (if you have ext-portal-service.jar in domain/lib/ext) try to reference/load a class not already loaded and present in portal-service.jar that it's in domain-dir/lib and managed by Common class loader - hierarchically at lower level and not visible by Extension class loader).

Moving ext-portal-service.jar in domain-dir/lib (where it should be already present portal-service.jar) should solve.

I've done some trial with liferay 6.2.1 bundled for glassfish and I was able to reproduce the problem (putting ext-portal-service.jar in domain/lib/ext) and solve (putting ext-portal-service.jar in domain/lib).

In effect it seems a peculiar settings for glassfish where system properties liferay.lib.global.dir=domains/domain1/lib, liferay.lib.global.shared.dir=" it's empty and java.ext.dirs=domains/domain1/lib/ext

HTH !!!

Best Regards,
Denis.

[1] - https://blogs.oracle.com/sivakumart/entry/classloaders_in_glassfish_an_attempt
[2] - http://docs.oracle.com/cd/E18930_01/html/821-2418/beadf.html

[Samuel Kong, modifié il y a 9 années.]

Hi George,

As James said, this is probably a class loading issue. Can you try merging the portal-service.jar and ext-portal-service.jar. (The files in ext-portal-service.jar should replace the files in portal-service.jar). Locate the original portal-service.jar and replace this file with the merged jar.

We'll look into making this easier in the future.

[Denis Signoretto, modifié il y a 9 années.]

Hi Samuel,

what about other jars (ext-portal-impl.jar and ext-util-taglib.jar) ? Do you suggest to do the same merge operation ?
Why not build and distribute already merged artifacts (jar/war) ? (it should simplify deployment on various app server)

[James Falkner, modifié il y a 9 années.]

Denis Signoretto:

James Falkner:

Hey guys, I get the same thing on GF.. investigating.. I'm sure it'll come down to classloading magical differences between app servers.

Hi James,

after some investigation[1] I've seen glassfish has multiple classloaders organized as described in Glassfish Class Loader Hierarchy[2]. As you can see, "domain-dir/lib/ext" directory it's managed by Extension class loader while "domain-dir/lib" it's managed by Common class loader that it's at lower level compared to Extension class loader). As reported in [1] domain-dir/lib it's the preferred place for a library to be made available to the whole domain.

Yep, this is exactly what is happening: GlassFish's domain-dir/lib/ext is *not* an ancestor of the common classloader, so references from lib/ext -> lib/ will fail to resolve (like in this case).

For now, see Sam's suggested workaround to manually merge the two JARs (overwriting classes found in portal-service.jar with those in ext-portal-service.jar). Yeah, it's an ugly workaround. We're looking into how best to distribute going forward - doing the merge ourselves will make the download gigantic, so hopefully there is an alternative.

[George Oakley, modifié il y a 9 années.]

Denis Signoretto:

Moving ext-portal-service.jar in domain-dir/lib (where it should be already present portal-service.jar) should solve.

I've done some trial with liferay 6.2.1 bundled for glassfish and I was able to reproduce the problem (putting ext-portal-service.jar in domain/lib/ext) and solve (putting ext-portal-service.jar in domain/lib).

Hey guys,
Thanks for support! I tested Denis way (thanks for good GF specification research). No errors have been reported in logs. Is this method also a good workaround to?

[Denis Signoretto, modifié il y a 9 années.]

Hi George,

unfortunately my workaround it's probably not 100% safe. Putting both ext-portal-service.jar and portl-service.jar
in the same directory solve the problem of classloading but doesn't guarantee that ext version of classes takes
precedence over overwritten classes. From my empirical trials (I wrote a simple JSP that print out the jar
where GroupServiceUtil it's loaded from) it seems that glassfish load jars alphabetically (but it's not specified anywhere)
and ext-* jar shold take precedence. If want to be 100% sure I suggeste to follow the Samuel's merge solution.

Regards,
Denis.

[David H Nebinger, modifié il y a 8 années.]

Tomcat loads the same way, @Dennis, as does JBoss. I think the others do also.