Liferay 7 GA1 deployment issue with global library!

[8年前 に Vipin Bardia によって更新されました。]

Hi All,

We are using spring 4 for our porltets. In liferay 7 beta 7 and we were able to deploy them.

Now with Liferay 7 GA1, we can still deploy these portlets BUT we are not able to use global directory of tomcat lib/ext.
If we move all of the required libraries to portlet lib, it works, but we want to place common libraries to lib/ext.

It throws exceptions like noClasFound in case of global library!

Any suggestions?

Thanks in advance emoticon

[8年前 に David H Nebinger によって更新されました。]

So here's the thing w/ moving all your jars to the global lib/ext directory: you pretty much have to move all of their dependencies also.

You have to remember that there are actually different class loaders in play here. There's the global class loader which handles things out of lib and lib/ext, and then there's the web app class loader that can access classes from global or WEB-INF/lib.

The global class loader, however, cannot cross any other boundaries, all the classes needed must come from global. So the NoClassFound exception, well that points to the jar that you need to move to lib/ext. And likely after that you'll hit a lot more similar exceptions and you'll find more and more of your jars going into lib/ext.

The big problem with this scenario is that once a jar is a global dependency, you cannot use different versions in the web app class loader - the global one(s) will come first.

You also have deployment issues in that sometimes it can be difficult (or impossible on windows) to replace a jar while the app server is running, forcing some downtime on your operations just to update a dependency.

So for these reasons and more, it is generally considered a bad practice to put your jars in the global lib dirs.

[8年前 に Artem Khojoyan によって更新されました。]

David H Nebinger:

So here's the thing w/ moving all your jars to the global lib/ext directory: you pretty much have to move all of their dependencies also.

You have to remember that there are actually different class loaders in play here. There's the global class loader which handles things out of lib and lib/ext, and then there's the web app class loader that can access classes from global or WEB-INF/lib.

The global class loader, however, cannot cross any other boundaries, all the classes needed must come from global. So the NoClassFound exception, well that points to the jar that you need to move to lib/ext. And likely after that you'll hit a lot more similar exceptions and you'll find more and more of your jars going into lib/ext.

The big problem with this scenario is that once a jar is a global dependency, you cannot use different versions in the web app class loader - the global one(s) will come first.

You also have deployment issues in that sometimes it can be difficult (or impossible on windows) to replace a jar while the app server is running, forcing some downtime on your operations just to update a dependency.

So for these reasons and more, it is generally considered a bad practice to put your jars in the global lib dirs.

So what would be a solution in this case? Assuming there is already a running system pretty much based on the global /ext/lib/service.jar, which worked just fine up to the date when it was upgraded to 7.0. Is there any other way to make the services globally available for other portlets?

[8年前 に Olaf Kock によって更新されました。]

Artem Khojoyan:

So what would be a solution in this case?

I hope to have answered this in your other thread. The global classpath was always a bad idea. Liferay 7 forces you to introduce a better architecture for your dependencies.

[8年前 に Artem Khojoyan によって更新されました。]

Olaf Kock:

Artem Khojoyan:

So what would be a solution in this case?

I hope to have answered this in your other thread. The global classpath was always a bad idea. Liferay 7 forces you to introduce a better architecture for your dependencies.

Thank you, so far it seems to be working fine!