Forums

Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Martin Olsen
JBoss7/Liferay6.2.0 failing to reload JSP. Is this a known problem?
December 6, 2013 5:51 AM
Answer

Martin Olsen

Rank: New Member

Posts: 15

Join Date: August 16, 2012

Recent Posts

Hi,

We're encountering this odd problem so wondering if anyone alse experienced anything similar.

We're using Liferay 6.2.0 bundled with JBoss7.1.1.Final. While developing, we're using Liferay development mode (-Dexternal-properties=portal-developer.properties). As far as I can tell this works fine; neither CSS nor Javascript is cached.

However, we have a problem with JSPs. When a JSP is changed on the server, it never reloads. This is the case both when we manually change a file within ROOT.war/html (which we have found to be very useful for experimenting) or when we replace the file indirectly by means of a hooks project (which is the more lasting way). The only way to get the server to reload the file is to flip the server. As you may imagine, this is a bit of a drag when working with hooks. Also, the ant deploy target in hooks doesn't work as expected in this case.

I guess I should note that the above was never an issue on Liferay 6.1.1.

Having investigated the issue a bit, it seems like JSP parsing is something that Liferay leaves the the surrounding application server and that the correct way to disable server side JSP caching is to add a statement to the standalone.xml file. Also it seems like JBoss7.1.1.Final has some serious issues in this regard. The JBoss forums have a thread on the issue:
https://community.jboss.org/message/723945

I'm not sure but by the description it looks very much like the problem that we are experiencing. Have any of you experienced anything similar? If so, it this a general JBoss7/LR6.2 issue?
Martin Olsen
RE: JBoss7/Liferay6.2.0 failing to reload JSP. Is this a known problem?
December 6, 2013 6:57 AM
Answer

Martin Olsen

Rank: New Member

Posts: 15

Join Date: August 16, 2012

Recent Posts

On a side note it seems like things do work if we use the JRebel java agent (we do so by placing jrebel.jar in the JBoss7 bin folder and running the server with -javaagent:jrebel.jar). We don't really have any explanation for this.

On the other hand, enabling JRebel will have the unfortunate side effect of making the server destroy any theme that we deploy to it using ant. Which is why we generally disable it on the server when we do Liferay development where as we enable it when we deploy our regular web application projects. It's a mighty fine productivity tool when developing "standard" server side Java code but we have never succeeded in making it anything but a nuisance when working with Liferay themes and customizations.

So we have a workaround for the JSP caching issus,at least to some extent. Would have been more convenient if it didn't include JRebel, though.
Victor Zorin
RE: JBoss7/Liferay6.2.0 failing to reload JSP. Is this a known problem?
December 8, 2013 8:36 PM
Answer

Victor Zorin

Rank: Liferay Legend

Posts: 1176

Join Date: April 14, 2008

Recent Posts

In the past we had similar problems when JSP timestamps were different on server and inside war archive,
i.e. we had server running on GMT and development (Eclipse) building file in GMT +10 (Australian time) or the other way.

JSPs were not recompiled because the newly arriving files were older than those compiled on server-side.

In your case, the timestamping may depend on the way your build your projects, this may explain a different behavior for different devel/build environments.
Martin Olsen
RE: JBoss7/Liferay6.2.0 failing to reload JSP. Is this a known problem?
December 9, 2013 12:53 AM
Answer

Martin Olsen

Rank: New Member

Posts: 15

Join Date: August 16, 2012

Recent Posts

Hi Victor,
Actually, that might be something to investigate for us. We're running GMT+1 and our server seems to be running GMT so over time we have grown accustomed to the server giving us odd warnings about timestamp mismatches (don't recall the exact wording). We just figured that they were harmless.
Cheers,
/Martin