Lao Long 1 Month Ago - Edited I think to use "@Reference " you will need to make "UpgradeProcess" a component. "activate()" of the component won't be called until the "@Reference" is resolved. However, if UpgradeProcess is part of a hook, using "upgrade.processes" property configuration, it will be called differently -- its doUpgrade() is called regardless if the "component" is ready or not, no waiting. When the hook's upgrade process is triggered, a different intance of the "UpgradeProcess" will be created and its doUpgrade() is called. It would be great if your approach works for a UpgradeProcess in a hook. Do you have any waiting sample implementation? Please sign in to reply. Reply as... Cancel David H Nebinger Lao Long 1 Month Ago - Edited I think there may be some confusion stemming from how I interspersed the code into the blog, but yes this is one @Component component, the implementation of the ModelListener interface. It's not at all part of an UpgradeProcess implementation. This code runs at every node so it can either a) create the missing role or b) find the existing role and then signal to all other modules that might need this role to be successful, that the role is ready to go. With respect to your request about UpgradeProcesses as hooks, we have long abandoned using hooks in Liferay 7, and you should too. Even if they might be working from a legacy perspective, I would consider them as deprecated and likely to go away at any time, and likely aren't tested well at all. Stick with building UpgradeProcesses built the OSGi way and avoid the hook approach. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited Thank you David for your reply. There were two reasons I am still using a Hook: 1. I needed to override portal's term_of_use.jsp. Not sure what would be the new way to do that in Liferay 7. Appreciate if you could advise. 2. I wanted to "update" a lot of things after Liferay is initiated, for example, create a bunch of new roles, new users and articles. What roles, users and articles to create are based on a configuration file (xml). The code to create these artifacts are in a separate library/OSGI bundle (so it can be reused for different Portal instance/installation). So the configuration will have to be provided by a different bundle or bundle fragment. There are some challenges: 1) I tried to use the "upgrade.processes" property with the hook. It works only if I deploy the plugin/hook after the portal is up and running, otherwise, some services might not be available. Your blog explained that problem. Depends on when liferay runs the UpgradeProcess, I would run into different problems. One happens often than others is that the articles I added won't show in the portal because various reasons. One is it's not indexed. I tried to index them in the UpgradeProcess, but many times the indexer for Articles aren't initialized -- even though I have included the "JournalArticleLocalService" in "required-capability" and its package in "import-package"; 2) then I explored the idea to use a service/component of UpgradeStepRegistrator. This approach has many of its own challengs: 2.1) when I start from a brand new Portal installation, there isn't a record in Release_ table for the bundle, so the UpgradeProcess won't run at all during the portal start up except if I manipulate the "Bundle-Version" and from/to schemaVersion in the register() method. But I haven't found what logic Liferay uses to determine trigger/ or-not-trigger the registered UpgradeProcesses. Although Liferay does not trigger those registered UpgradeProcess, often time I can manually execute them from Gogo shell. 2.2) it's difficult for the registered UpgradeProcess to find the configuration xml during the time doUpgrade() is called. I have to pass the configuration to the UpgradeProcess during the time of regster(). However, the configuration refers to other dynamic configuration that can only be resolved during the time doUpgrade() is called. The UpgradeProcess class is loaded by a different classloader in another OSGI bundle, so there are many classloader issues. Sorry it's a long writing. I would stop here for now. If you have some insights, that would be greatly appreciated. Please sign in to reply. Reply as... Cancel David H Nebinger Lao Long 29 Days Ago - Edited 1. A TOU override hasn't been necessary for years. You can use a web content in lieu of the TOU to avoid the JSP override. And even if you did want to go that route, it's just a JSP bag implementation to provide the alternative. Either way, no hook. 2. What you are describing is easily solved using a Site Initializer, an Upgrade Process, and even a Batch process. All of the challenges that you've listed stem from maybe not asking for help how to build these things. Had you started by asking what the best approach was (either by posting on Ask or in the community slack), somebody would have pointed you at the right way to do these things that would have avoided the challenges altogether. Unfortunately it sounds like you decided on a bad implementation path (a hook), dug a hole and continued to dig it deeper and deeper, finding ways to justify continuing with the hook when it was just one bad decision after another. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited 1. The project started several years back, when a lot things I wanted to do were not provided by Liferay, or not known to me. Over the years Liferay had added many features, but my development has not kept up with liferay's evolution. And each liferay upgrade meant more changes/development. I also was trying to salvage some work done already. For example, for TOU, (years back) , I wanted to support multiple languages dynamically; and for each non-English language, I wanted to display content for that language and English version together. The content itself is now in Web Content. it's a long story. It's probably the time to drop the hook altogether. 2. A dedicated OSGI module for UpgradeProcess that bundles code and configuration in one single OSGI bundle would work fine. But as I mentioned previously, I was trying to put the (generic) code (UpgradeProcess) in one bundle (so it can be reused for different portal instances), and configuration and UpgradeProcessRegistrator code in another bundle/hook. That caused many troubles. I thought even if I replaced Hook with a plain OSGI bundle, if the UpgradeProcess code is in one bundle and the configuration is in another bundle, some of the challenges would remain, right? For example, the UpgradeProcess would still have problem to load the configuration file (which is in another bundle) unless I find away to solve the classloader issue. Bundle fragment might solve this classloader issue (I tried for a short time though). Any advice on this? I have never used Site Initializer or Batch Process, but certainly would like to explore. Thanks again for your reply, much appreciated. Please sign in to reply. Reply as... Cancel
David H Nebinger Lao Long 1 Month Ago - Edited I think there may be some confusion stemming from how I interspersed the code into the blog, but yes this is one @Component component, the implementation of the ModelListener interface. It's not at all part of an UpgradeProcess implementation. This code runs at every node so it can either a) create the missing role or b) find the existing role and then signal to all other modules that might need this role to be successful, that the role is ready to go. With respect to your request about UpgradeProcesses as hooks, we have long abandoned using hooks in Liferay 7, and you should too. Even if they might be working from a legacy perspective, I would consider them as deprecated and likely to go away at any time, and likely aren't tested well at all. Stick with building UpgradeProcesses built the OSGi way and avoid the hook approach. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited Thank you David for your reply. There were two reasons I am still using a Hook: 1. I needed to override portal's term_of_use.jsp. Not sure what would be the new way to do that in Liferay 7. Appreciate if you could advise. 2. I wanted to "update" a lot of things after Liferay is initiated, for example, create a bunch of new roles, new users and articles. What roles, users and articles to create are based on a configuration file (xml). The code to create these artifacts are in a separate library/OSGI bundle (so it can be reused for different Portal instance/installation). So the configuration will have to be provided by a different bundle or bundle fragment. There are some challenges: 1) I tried to use the "upgrade.processes" property with the hook. It works only if I deploy the plugin/hook after the portal is up and running, otherwise, some services might not be available. Your blog explained that problem. Depends on when liferay runs the UpgradeProcess, I would run into different problems. One happens often than others is that the articles I added won't show in the portal because various reasons. One is it's not indexed. I tried to index them in the UpgradeProcess, but many times the indexer for Articles aren't initialized -- even though I have included the "JournalArticleLocalService" in "required-capability" and its package in "import-package"; 2) then I explored the idea to use a service/component of UpgradeStepRegistrator. This approach has many of its own challengs: 2.1) when I start from a brand new Portal installation, there isn't a record in Release_ table for the bundle, so the UpgradeProcess won't run at all during the portal start up except if I manipulate the "Bundle-Version" and from/to schemaVersion in the register() method. But I haven't found what logic Liferay uses to determine trigger/ or-not-trigger the registered UpgradeProcesses. Although Liferay does not trigger those registered UpgradeProcess, often time I can manually execute them from Gogo shell. 2.2) it's difficult for the registered UpgradeProcess to find the configuration xml during the time doUpgrade() is called. I have to pass the configuration to the UpgradeProcess during the time of regster(). However, the configuration refers to other dynamic configuration that can only be resolved during the time doUpgrade() is called. The UpgradeProcess class is loaded by a different classloader in another OSGI bundle, so there are many classloader issues. Sorry it's a long writing. I would stop here for now. If you have some insights, that would be greatly appreciated. Please sign in to reply. Reply as... Cancel David H Nebinger Lao Long 29 Days Ago - Edited 1. A TOU override hasn't been necessary for years. You can use a web content in lieu of the TOU to avoid the JSP override. And even if you did want to go that route, it's just a JSP bag implementation to provide the alternative. Either way, no hook. 2. What you are describing is easily solved using a Site Initializer, an Upgrade Process, and even a Batch process. All of the challenges that you've listed stem from maybe not asking for help how to build these things. Had you started by asking what the best approach was (either by posting on Ask or in the community slack), somebody would have pointed you at the right way to do these things that would have avoided the challenges altogether. Unfortunately it sounds like you decided on a bad implementation path (a hook), dug a hole and continued to dig it deeper and deeper, finding ways to justify continuing with the hook when it was just one bad decision after another. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited 1. The project started several years back, when a lot things I wanted to do were not provided by Liferay, or not known to me. Over the years Liferay had added many features, but my development has not kept up with liferay's evolution. And each liferay upgrade meant more changes/development. I also was trying to salvage some work done already. For example, for TOU, (years back) , I wanted to support multiple languages dynamically; and for each non-English language, I wanted to display content for that language and English version together. The content itself is now in Web Content. it's a long story. It's probably the time to drop the hook altogether. 2. A dedicated OSGI module for UpgradeProcess that bundles code and configuration in one single OSGI bundle would work fine. But as I mentioned previously, I was trying to put the (generic) code (UpgradeProcess) in one bundle (so it can be reused for different portal instances), and configuration and UpgradeProcessRegistrator code in another bundle/hook. That caused many troubles. I thought even if I replaced Hook with a plain OSGI bundle, if the UpgradeProcess code is in one bundle and the configuration is in another bundle, some of the challenges would remain, right? For example, the UpgradeProcess would still have problem to load the configuration file (which is in another bundle) unless I find away to solve the classloader issue. Bundle fragment might solve this classloader issue (I tried for a short time though). Any advice on this? I have never used Site Initializer or Batch Process, but certainly would like to explore. Thanks again for your reply, much appreciated. Please sign in to reply. Reply as... Cancel
Lao Long David H Nebinger 29 Days Ago - Edited Thank you David for your reply. There were two reasons I am still using a Hook: 1. I needed to override portal's term_of_use.jsp. Not sure what would be the new way to do that in Liferay 7. Appreciate if you could advise. 2. I wanted to "update" a lot of things after Liferay is initiated, for example, create a bunch of new roles, new users and articles. What roles, users and articles to create are based on a configuration file (xml). The code to create these artifacts are in a separate library/OSGI bundle (so it can be reused for different Portal instance/installation). So the configuration will have to be provided by a different bundle or bundle fragment. There are some challenges: 1) I tried to use the "upgrade.processes" property with the hook. It works only if I deploy the plugin/hook after the portal is up and running, otherwise, some services might not be available. Your blog explained that problem. Depends on when liferay runs the UpgradeProcess, I would run into different problems. One happens often than others is that the articles I added won't show in the portal because various reasons. One is it's not indexed. I tried to index them in the UpgradeProcess, but many times the indexer for Articles aren't initialized -- even though I have included the "JournalArticleLocalService" in "required-capability" and its package in "import-package"; 2) then I explored the idea to use a service/component of UpgradeStepRegistrator. This approach has many of its own challengs: 2.1) when I start from a brand new Portal installation, there isn't a record in Release_ table for the bundle, so the UpgradeProcess won't run at all during the portal start up except if I manipulate the "Bundle-Version" and from/to schemaVersion in the register() method. But I haven't found what logic Liferay uses to determine trigger/ or-not-trigger the registered UpgradeProcesses. Although Liferay does not trigger those registered UpgradeProcess, often time I can manually execute them from Gogo shell. 2.2) it's difficult for the registered UpgradeProcess to find the configuration xml during the time doUpgrade() is called. I have to pass the configuration to the UpgradeProcess during the time of regster(). However, the configuration refers to other dynamic configuration that can only be resolved during the time doUpgrade() is called. The UpgradeProcess class is loaded by a different classloader in another OSGI bundle, so there are many classloader issues. Sorry it's a long writing. I would stop here for now. If you have some insights, that would be greatly appreciated. Please sign in to reply. Reply as... Cancel David H Nebinger Lao Long 29 Days Ago - Edited 1. A TOU override hasn't been necessary for years. You can use a web content in lieu of the TOU to avoid the JSP override. And even if you did want to go that route, it's just a JSP bag implementation to provide the alternative. Either way, no hook. 2. What you are describing is easily solved using a Site Initializer, an Upgrade Process, and even a Batch process. All of the challenges that you've listed stem from maybe not asking for help how to build these things. Had you started by asking what the best approach was (either by posting on Ask or in the community slack), somebody would have pointed you at the right way to do these things that would have avoided the challenges altogether. Unfortunately it sounds like you decided on a bad implementation path (a hook), dug a hole and continued to dig it deeper and deeper, finding ways to justify continuing with the hook when it was just one bad decision after another. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited 1. The project started several years back, when a lot things I wanted to do were not provided by Liferay, or not known to me. Over the years Liferay had added many features, but my development has not kept up with liferay's evolution. And each liferay upgrade meant more changes/development. I also was trying to salvage some work done already. For example, for TOU, (years back) , I wanted to support multiple languages dynamically; and for each non-English language, I wanted to display content for that language and English version together. The content itself is now in Web Content. it's a long story. It's probably the time to drop the hook altogether. 2. A dedicated OSGI module for UpgradeProcess that bundles code and configuration in one single OSGI bundle would work fine. But as I mentioned previously, I was trying to put the (generic) code (UpgradeProcess) in one bundle (so it can be reused for different portal instances), and configuration and UpgradeProcessRegistrator code in another bundle/hook. That caused many troubles. I thought even if I replaced Hook with a plain OSGI bundle, if the UpgradeProcess code is in one bundle and the configuration is in another bundle, some of the challenges would remain, right? For example, the UpgradeProcess would still have problem to load the configuration file (which is in another bundle) unless I find away to solve the classloader issue. Bundle fragment might solve this classloader issue (I tried for a short time though). Any advice on this? I have never used Site Initializer or Batch Process, but certainly would like to explore. Thanks again for your reply, much appreciated. Please sign in to reply. Reply as... Cancel
David H Nebinger Lao Long 29 Days Ago - Edited 1. A TOU override hasn't been necessary for years. You can use a web content in lieu of the TOU to avoid the JSP override. And even if you did want to go that route, it's just a JSP bag implementation to provide the alternative. Either way, no hook. 2. What you are describing is easily solved using a Site Initializer, an Upgrade Process, and even a Batch process. All of the challenges that you've listed stem from maybe not asking for help how to build these things. Had you started by asking what the best approach was (either by posting on Ask or in the community slack), somebody would have pointed you at the right way to do these things that would have avoided the challenges altogether. Unfortunately it sounds like you decided on a bad implementation path (a hook), dug a hole and continued to dig it deeper and deeper, finding ways to justify continuing with the hook when it was just one bad decision after another. Please sign in to reply. Reply as... Cancel Lao Long David H Nebinger 29 Days Ago - Edited 1. The project started several years back, when a lot things I wanted to do were not provided by Liferay, or not known to me. Over the years Liferay had added many features, but my development has not kept up with liferay's evolution. And each liferay upgrade meant more changes/development. I also was trying to salvage some work done already. For example, for TOU, (years back) , I wanted to support multiple languages dynamically; and for each non-English language, I wanted to display content for that language and English version together. The content itself is now in Web Content. it's a long story. It's probably the time to drop the hook altogether. 2. A dedicated OSGI module for UpgradeProcess that bundles code and configuration in one single OSGI bundle would work fine. But as I mentioned previously, I was trying to put the (generic) code (UpgradeProcess) in one bundle (so it can be reused for different portal instances), and configuration and UpgradeProcessRegistrator code in another bundle/hook. That caused many troubles. I thought even if I replaced Hook with a plain OSGI bundle, if the UpgradeProcess code is in one bundle and the configuration is in another bundle, some of the challenges would remain, right? For example, the UpgradeProcess would still have problem to load the configuration file (which is in another bundle) unless I find away to solve the classloader issue. Bundle fragment might solve this classloader issue (I tried for a short time though). Any advice on this? I have never used Site Initializer or Batch Process, but certainly would like to explore. Thanks again for your reply, much appreciated. Please sign in to reply. Reply as... Cancel
Lao Long David H Nebinger 29 Days Ago - Edited 1. The project started several years back, when a lot things I wanted to do were not provided by Liferay, or not known to me. Over the years Liferay had added many features, but my development has not kept up with liferay's evolution. And each liferay upgrade meant more changes/development. I also was trying to salvage some work done already. For example, for TOU, (years back) , I wanted to support multiple languages dynamically; and for each non-English language, I wanted to display content for that language and English version together. The content itself is now in Web Content. it's a long story. It's probably the time to drop the hook altogether. 2. A dedicated OSGI module for UpgradeProcess that bundles code and configuration in one single OSGI bundle would work fine. But as I mentioned previously, I was trying to put the (generic) code (UpgradeProcess) in one bundle (so it can be reused for different portal instances), and configuration and UpgradeProcessRegistrator code in another bundle/hook. That caused many troubles. I thought even if I replaced Hook with a plain OSGI bundle, if the UpgradeProcess code is in one bundle and the configuration is in another bundle, some of the challenges would remain, right? For example, the UpgradeProcess would still have problem to load the configuration file (which is in another bundle) unless I find away to solve the classloader issue. Bundle fragment might solve this classloader issue (I tried for a short time though). Any advice on this? I have never used Site Initializer or Batch Process, but certainly would like to explore. Thanks again for your reply, much appreciated. Please sign in to reply. Reply as... Cancel