Iacopo Colonnelli 6 Years Ago Great post David, really useful. Unfortunately, the not fully OSGi Portlet registration method (that involves the D makes it quite hard to override an existing portlet component with standard methods (with service ranking for example). But fortunately, the migration of portlet properties from xml files to OSGi properties, together with the MVCCommand class system, make almost all aspects of Portlets customizable in a really easy and flexible way Please sign in to reply. Reply as... Cancel David H Nebinger Iacopo Colonnelli 6 Years Ago I'm not sure I'm following. Do you have an example of something that is hard to override in an existing portlet? Please sign in to reply. Reply as... Cancel Iacopo Colonnelli David H Nebinger 6 Years Ago Sorry, I will try to explain better the concept, but it's not strictly related to your article. The part related to your post was the importance of being able to correctly override portlet properties, that is a really useful feature of the new OSGi-based portlets in Liferay 7.0 ^_^.The thing that is hard to override in an existing portlet is...the portlet itself. Portlets are OSGi components, so one might expect that it's possible to override an existing Portlet class by specifying another portlet class with the same javax.portlet.name and an higher service rank. Well, since portlet service registration inside Liferay involves the DB, Portlet service registration is not fully OSGi. There are two main reasons for that:- I cannot have two portlet components with the same javax.portlet.name contemporary loaded inside the system (while normally I can have multiple implementations of the same OSGi service, and each reference will resolve it's implementation according to service ranking or more sophisticated OSGi filters)- If I have two portlets with the same javax.portlet.name property, one of the two will throw an error, the related PortletModel will not be loaded inside the DB and the service will be discarded by the PortletTracker. But which portlet will be actually loaded will not depend on OSGi filters or service rankings: the first module processed by the sistem will win. It's only a matter of time.According to that, overriding a Portlet module this way is DEFINITELY a wrong way to proceed. And this is what I meant with "it's hard to override an existing portlet component with standard methods". But fortunately, we have MVCCommands and Component properties, so we can easily override the 99% of a portlet behaviour ^^ Please sign in to reply. Reply as... Cancel David H Nebinger Iacopo Colonnelli 6 Years Ago Yep, that is true. I think the idea is that with the other extension points, you shouldn't have to override the portlet itself. I'm not sure I agree, that sometimes it may be the only way to affect a particular change. Which is why I wrote the blog about extending OSGi modules: https://web.liferay.com/web/user.26526/blog/-/blogs/extending-liferay-osgi-modules Please sign in to reply. Reply as... Cancel
David H Nebinger Iacopo Colonnelli 6 Years Ago I'm not sure I'm following. Do you have an example of something that is hard to override in an existing portlet? Please sign in to reply. Reply as... Cancel Iacopo Colonnelli David H Nebinger 6 Years Ago Sorry, I will try to explain better the concept, but it's not strictly related to your article. The part related to your post was the importance of being able to correctly override portlet properties, that is a really useful feature of the new OSGi-based portlets in Liferay 7.0 ^_^.The thing that is hard to override in an existing portlet is...the portlet itself. Portlets are OSGi components, so one might expect that it's possible to override an existing Portlet class by specifying another portlet class with the same javax.portlet.name and an higher service rank. Well, since portlet service registration inside Liferay involves the DB, Portlet service registration is not fully OSGi. There are two main reasons for that:- I cannot have two portlet components with the same javax.portlet.name contemporary loaded inside the system (while normally I can have multiple implementations of the same OSGi service, and each reference will resolve it's implementation according to service ranking or more sophisticated OSGi filters)- If I have two portlets with the same javax.portlet.name property, one of the two will throw an error, the related PortletModel will not be loaded inside the DB and the service will be discarded by the PortletTracker. But which portlet will be actually loaded will not depend on OSGi filters or service rankings: the first module processed by the sistem will win. It's only a matter of time.According to that, overriding a Portlet module this way is DEFINITELY a wrong way to proceed. And this is what I meant with "it's hard to override an existing portlet component with standard methods". But fortunately, we have MVCCommands and Component properties, so we can easily override the 99% of a portlet behaviour ^^ Please sign in to reply. Reply as... Cancel David H Nebinger Iacopo Colonnelli 6 Years Ago Yep, that is true. I think the idea is that with the other extension points, you shouldn't have to override the portlet itself. I'm not sure I agree, that sometimes it may be the only way to affect a particular change. Which is why I wrote the blog about extending OSGi modules: https://web.liferay.com/web/user.26526/blog/-/blogs/extending-liferay-osgi-modules Please sign in to reply. Reply as... Cancel
Iacopo Colonnelli David H Nebinger 6 Years Ago Sorry, I will try to explain better the concept, but it's not strictly related to your article. The part related to your post was the importance of being able to correctly override portlet properties, that is a really useful feature of the new OSGi-based portlets in Liferay 7.0 ^_^.The thing that is hard to override in an existing portlet is...the portlet itself. Portlets are OSGi components, so one might expect that it's possible to override an existing Portlet class by specifying another portlet class with the same javax.portlet.name and an higher service rank. Well, since portlet service registration inside Liferay involves the DB, Portlet service registration is not fully OSGi. There are two main reasons for that:- I cannot have two portlet components with the same javax.portlet.name contemporary loaded inside the system (while normally I can have multiple implementations of the same OSGi service, and each reference will resolve it's implementation according to service ranking or more sophisticated OSGi filters)- If I have two portlets with the same javax.portlet.name property, one of the two will throw an error, the related PortletModel will not be loaded inside the DB and the service will be discarded by the PortletTracker. But which portlet will be actually loaded will not depend on OSGi filters or service rankings: the first module processed by the sistem will win. It's only a matter of time.According to that, overriding a Portlet module this way is DEFINITELY a wrong way to proceed. And this is what I meant with "it's hard to override an existing portlet component with standard methods". But fortunately, we have MVCCommands and Component properties, so we can easily override the 99% of a portlet behaviour ^^ Please sign in to reply. Reply as... Cancel David H Nebinger Iacopo Colonnelli 6 Years Ago Yep, that is true. I think the idea is that with the other extension points, you shouldn't have to override the portlet itself. I'm not sure I agree, that sometimes it may be the only way to affect a particular change. Which is why I wrote the blog about extending OSGi modules: https://web.liferay.com/web/user.26526/blog/-/blogs/extending-liferay-osgi-modules Please sign in to reply. Reply as... Cancel
David H Nebinger Iacopo Colonnelli 6 Years Ago Yep, that is true. I think the idea is that with the other extension points, you shouldn't have to override the portlet itself. I'm not sure I agree, that sometimes it may be the only way to affect a particular change. Which is why I wrote the blog about extending OSGi modules: https://web.liferay.com/web/user.26526/blog/-/blogs/extending-liferay-osgi-modules Please sign in to reply. Reply as... Cancel
Dominik Marks 5 Years Ago Thank you for the interesting blog post, David. However in most of our environments we do not have direct access to the filesystem, so it is not possible to put any files directly into osgi/configs. So I wondered if it is possible to write a deployable plugin which overrides component properties. I played around a litte with the com.liferay.portal.configuration.extender.internal.ConfiguratorExtender (as described in one of your other posts at https://community.liferay.com/en/blogs/-/blogs/meet-the-extenders). By using such a ConfigurationExtender it seems to be possible to deploy a bundle which overrides the configuration of a component. A small caveat is that the configuration is only overriden once. That means if a configration already exists, the configuration is not overridden. Please sign in to reply. Reply as... Cancel
Michael Wall 5 Years Ago Thanks, I just used this to 'fragment enable' an OOTB Liferay Widget with the com.liferay.fragment.entry.processor.portlet.alias property. Please sign in to reply. Reply as... Cancel
David Weitzel 5 Years Ago Once again you have the answer... I had a ticket open for this and it has stood still for a week with them saying 'not sure how are you trying to do it?' instead of saying this is how you do it - I referred them to your blog. we now have per layout portlet preferences for the calendar portlet. (which we are extending the UI to show / hide a number of elements. we were trying to override the MVCPortlet class though and that never was able to compile and deploy. com.liferay.portlet.calendar.web.portlet.CalendarPortlet.java should we be able to overwrite/extend that some how - we may need to add more serveResource methods and our own routes.xml to handle ics subscriptions and ical downloads to outlook. But the old liferay portlet properties can now be overwritten - I even moved the category for Add portlet. Thanks Please sign in to reply. Reply as... Cancel
Nitin khandelwal 4 Years Ago Hi David, Thanks for great post. We have similar requirements as we need to place 'My Workflow Tasks' portlet under sample category so admin can place this portlet on any pages. I followed this blog and I: 1) Placed a config file named as 'com.liferay.portal.workflow.task.web.internal.portlet.MyWorkflowTaskPortlet.cfg' inside osgi/configs folder, 2) Placed following property in the cfg file mentioned above: com.liferay.portlet.display-category=category.sample 3) Cleaned/Restarted server. Unfortunately, 'My Workflow Tasks' portlet is still not available under 'sample' category. Seems I am missing something. Can you please let me know how can we achieve this in Liferay 7.0 ? Please sign in to reply. Reply as... Cancel Mohammad Azharuddin Nitin khandelwal 8 Months Ago - Edited Because you must provide the value in double quotes as shown com.liferay.portlet.display-category="category.sample" Please sign in to reply. Reply as... Cancel
Mohammad Azharuddin Nitin khandelwal 8 Months Ago - Edited Because you must provide the value in double quotes as shown com.liferay.portlet.display-category="category.sample" Please sign in to reply. Reply as... Cancel