I have made a hook for the document-media portlet. Basically I just removed some options in the droplist. When I deploy the hook, everything works fine, however, everytime the server is restarted, it seems that the one being deployed is not the hook as the options that I have removed reappears.
Can anyone tell what is causing this issue?
It happens to me also. In my case there was a different hook project that was hooking the same JSP. So actually I was having 2 hooks for the same JSP.
May be you can check it out if by any case there is a duplicate hook for the same.
Related
I am using JRebel + Intellij JRebel IDE Plugin to hot deploy a gradle project.
I have a situation with JRebel where there are certain Java classes that JRebel refuses to allow me to hot-deploy.
Some classes reload fine.
Other classes do not reload at all. (often in the same gradle sub-project as classes that reload OK)
There is no rhyme or reason to why they do not want to reload. The classes are not really anything special. Not insanely long.
We use Guice... but some files that are managed by Guice reload fine while others do not.
It is making JRebel pretty much unusable because you can't trust whether it will hot deploy or not.
I created a custom JRebel plugin for our project hoping it would help but it did not. Because the class itself will not trigger a reload event, the plugin fails to help fix this.
Note the class in question that will not reload is often an implementation of an interface where if I change the implementation, no reload happens. But if I change the interface java class, that will reload fine!
There is something that JRebel in particular does not like about the Java class files.
When I build the files that it won't pick up, you can even see in the IDE and 100% of the time for these files I get:
Any have any ideas of a way to get this to stop happening?
The class was not in the classloader yet due to lazy loading. Thus the issue.
JRebel can't reload classes not yet in the classloader.
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
I wanted to know How the application server will take custom jsp If we deploy the hook and If we undeploy the hook again it will take the liferay existing jsp file. How application server will handles this.
The original JSP file will be renamed from (e.g.) view.jsp to view.portal.jsp and the hook's version will be copied as the new view.jsp. On undeployment this will be reversed. See the deployment code here.
As this is a single step process, it will break when two hooks override the same JSP, effectively loosing the original implementation. See this article for a solution to the problem
I have an XPages application that has been running quite happily for the last couple of years.
The application uses some Java classes as converters that are used to convert data entry on certain fields to upper case, proper case, etc. This functionality has been present and working since the app was first deployed.
Today I was asked to make a change to one of the pages, adding a new field. The change was made in a test copy of the database, the app rebuilt and tested and all was fine.
The same change was then promoted into the live database, but after being rebuilt the error
Can't instantiate class: 'Cannot find class uk.co.xxx.beans.UpperCase in NSF'.
is being returned.
I have tried rebuilding the app and cleaning the project numerous times without success. I have also tried amending the code in the Java class and rebuilding.
If I remove all references to the UpperCase class it then complains about the ProperCase class. It appears as if the app has lost its reference to the Java classes and rebuilding isn't fixing the problem.
As an interim solution I have removed all uses of these classes so that users can at least display the page - but this is obviously not a long term solution. As soon as I reinstate one instance and rebuild, the error returns.
The only change in the app has been the addition of the new field. Removing it makes no difference.
Can you suggest anything else I can try and what may be causing the problem?
Open production db in designer and using Navigator view open WebContent/WEB-INF and delete classes folder. Then rebuild the app or refresh it from template again.
Sometimes classes are not updated correctly. I've seen it few times.
I have seen this too (domino 8.5.3). I recompile until it eventually works. With a restart of the http task thrown in for good measure. How are you deploying the classes within the db or as jar files in lib/ext?
I ran into similar issues with 8.53 FP2 with the same "can't instantiate errors" if accessed by a designer client. I even put a PRD in at IBM for it.
In order to fix this problem we had to update to the server and clients to FP5. We had a work around before we could update the FP5. We had to modify how the application was rolled out. Once the database was updated from a template we had to do a clean then a build while use our Application ID used for signing applications.
http://www-01.ibm.com/support/docview.wss?uid=swg21639571
JDAE8ZV2CX
XPage With Java Design Element Breaks When Domino Designer opens after applying 8.5.3 Fix Pack 2 interim fix of any 853 Fix Pack 2/Fix Pack 3 hotfix
I'm building a new Liferay theme and being crushed by this problem.
When I make changes to the init_custom.vm, the only possible way for me to see the changes is to restart Tomcat. When I make other changes to my theme, such as editing my CSS or adding images, I can see the changes after deploying the theme via the Ant Deploy target. No such luck with the templates.
I checked the $CATALINA_HOME/webapps/my-theme/init_custom.vm after deploying, and that file does reflect my changes.
I cannot continue to develop if this is going to be the cycle. I must be able to make changes to the velocity template without requiring a restart. Any suggestions?
I'm using the Eclipse Liferay IDE and the Ant build to deploy my theme when I make changes. I'm using the Liferay 6.0.6 Tomcat bundle. I've also already added include-and-override=portal-developer.properties to my portal-ide.properties file.
Thanks!!!
(also asked this in the Liferay Forums, and I'll make sure to copy back any answers I get: http://www.liferay.com/community/forums/-/message_boards/message/11292911)
Liferay also caches everything Velocity related which sometimes can present itself in the way you describe: changes to templates don't seem to show unless you restart Liferay. You can turn off this behavior if you set the following property in your portal-ext.properties file:
velocity.engine.resource.manager.cache.enabled=false
I switched to the 6.1 Beta and do not have the problem on that release, so it was just with 6.0.6.
Also: I've seen How to edit a velocimacro without restarting velocity? and Testing JSON API in Rails 3.2 using rspec using exact PUT/POST bodies as Backbone would send and they did not work for me. Upgrading to 6.1 beta did, for some reason, work.