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
Related
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 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.
I'm developing a Liferay application, consisting on 2 different portlets, an both have to make certain operations in common, so I decided to put that operations in static methods in an external Utils class.
I have to externalize that class to avoid duplicating the same code in both portlets, and I want to have the portlets in different WAR files.
I know I can package the Utils class in a JAR file, but we are still developing and we don't want to regenerate the JAR and restart the Tomcat for every change.
Which is the best option and how can I perform it?
If you're using the Liferay SDK, you can use the clients (recently changed to shared) directory to put your common code.
A good example is how deploy-listener-shared is used in conjunction with deploy-listener-hook.
From what it looks like, all the configuration you need to do is to modify your build.xml files that will use the client\shared classes. If you look at build file of deploy-listener-hook you can see all you need to add is the.
For the new SDK:
<property name="import.shared" value="my-utils-shared" />
For the older SDK:
<property name="dependent.clients" value="my-utils-client" />
Hope this helps!
There is another method that involves building a JAR file but it doesn't require a server restart (on Tomcat at least).
Write a build script for your JAR file so it compiles, builds the JAR and finally copies it to the following location:
{tomcat}/webapps/ROOT/WEB-INF/lib
Then in your portlet open the "liferay-plugin-package.properties" (in Liferay Developer Studio / Liferay IDE this should open with a nice GUI).
Then add the name of your JAR to the "portal-dependency-jars" list in this file so in the source it would like (Or just hit the "Add" button in the GUI and select the JARs you want):
portal-dependency-jars=my-custom-lib.jar,my-other-custom-lib.jar
Save the file, and redeploy the portlet, and the JAR will be copied across when the portlet is deployed.
I've used this method for custom JARs, and 3rd party JARs that I've needed to use in my portlets.
For the development phase just package the jar file with both applications.
Unless one application depends on the other somehow it is completely ok.
Another solution is to use JRebel tool. It will allow you to redeploy jar in tomcat without restarting.
Also you may have several portlets in one .war. You may just define them both in portlet.xml.
Working on a SharePoint project I'm trying to use Unity as a dependency injection container.
My first idea to get this container running is using the global.asax as described in the best practices by P&P:
http://webclientguidance.codeplex.com/releases/view/17134#DownloadId=43305
In these best practices they tell you to manually edit the global.asax file to make it inherit SPUnityHttpApplication.
<%# Application Language="C#" Inherits="Unity.SharePoint.SPUnityHttpApplication" %>
Manually editing this file is not an option in enterprise environments since we have multiple environments (DTAP) and all of them have multiple frontend servers that would need manual steps.
I can't find any way to deploy a global.asax file by using a feature or wsp or anything because the global.asax is located in the web application root and sharepoint deploys other files to the /14 hive folder so you can't acces the web application root directory.
Alternatives i've looked into is the SharePointServiceLocator. this build in functionality does almost what i want. but it can only resolve classes that have a default constructor. this way i can't chain resolve all my implementations by using constructor injection. I found a post how to change the service locator to make use of unity but this doesn't seem to work properly if you read the comments.
My problem can be fixed by fixing 1 of these 2 main problems:
Don't arrange unity in the global.asax, but then where and how?
Deploy the global.asax in sharepoint? possible?
The global.asax doesn't seem to be the best solution to do this because of the deployment issues described in the question.
A viable solution is implementing this in a httpmodule
The init method can be used to wire everything up since this is called when the sharepoint application starts.
the httpmodule can be added in the web.config by a feature receiver
This way there is no need to do tricks with the global.asax that is located in a directory you can't deploy to with a feature and you have all the functionality and correct time to instantiate the DI container.
It may not be ideal, but you could look at using a feature receiver and write code to edit the existing files directly.
I have problems running JSF in an OSGi environment. I am using jetty web container and equinox to provide the OSGi functionality. The structure of my application is as follows:
The first bundle has all the JSF libs, web.xml and a config.xml. It looks as the following:
bundle1
----src/main/java
-------de/package
----------Activator.java
----------JSFResolver.java
----src/main/resource
------ WebContent
----------META-INF
-------------face-config.xml
-------------web.xhtml
----------start.xhtml
-----------include.xhtml
----libs (containing all JSF required Jars)
The structure of the second bundle is as follows:
bundle2
---src/main/java
------de/package
----------Bean.java
---src/main/resource
------META-INF
---------face-config.xml
------WebContent
---------index.xhtml
When running the application of equinox, the bundle1 is the main bundle where all the browser requests are sent to. In the second bundle, the index.xhtml file can be retrieved the by first bundle upon request. The index.xhtml in bundle 2 gets its values and properties from the 'Bean.java' in bundle 2. The problem comes when i request the 'index.xhtml', the Bean.java class is not found. I think this is because the class loader of bundle1 cannot find it, it has no knowledge of it. So i would like to ask if anyone knows how to solve this problem. If so please do assist me, i have tried all the possibilities i had..
Is it in fact possible to have JSF run on multiple bundles using the same FaceletsContex? Can i be able to have seperate faces-config.xml files in each bundle, which can all be connected other faces-config.xml in other bundles? Can anyone please provide me a solution. Sample code would help.
If any one is interested in the answer, in this case, the faces-config.xml is of no use. So i had to use the plug-in.xml file to register all my beans across all plug-in projects. I created an extension point in the main plug-in, which other plug-ins could register their Beans as extension. I had to override the managedBean class of JSF for it to be able to read the bean properties from extension point rather than from the faces-config.xml.
So during runtime, the application reads all extensions registered in the managedBeans extension point, and then creates all the required bean instances from all plug-ins. Therefore the error will no longer be there. If anyone wants to implement JSF in such a structure, you should know that almost all the functionality in the faces-config.xml will have to be moved to the plug-in.xml of the plug-ins, this includes the navigation rules aswell. One has to do alot of customizations but at the end, you get a nice modular JSF application running on equinox, without having to embed it in a .WAR file.. which seems to be very advantageoous.