Krzysztof Gołębiowski 5 Months Ago - Edited This you for this blog post, I haven't seen that feature yet. We've already migrated our scheduler tasks to 7.4 in the old-fashioned way, but this looks much better! Whenever I find some spare time, I'll try to migrate. Is it possible (I'm sure it is!) to automatically create an entry in the Job Scheduler panel? If there was a way to do it when the module is deployed (@Activate ?), it would really make the feature complete and the module fully self-contained. By the way, I noticed that the first link in your post (directing to the old blog post) links to the Chinese version of liferay.dev. Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited So actually the only thing that we've defined here is the DispatchTaskExecutor, it's not even a scheduled job at the point this gets created. There are services surrounding the new framework including the DispatchTriggerLocalService. If I were going to be automatically scheduling jobs, I would use an UpgradeProcess implementation that leveraged the DispatchTriggerLocalService's addDispatchTrigger() to create the new job and then the updateDispatchTrigger() to set the scheduling details (start/stop dates, cron expression, etc). Please sign in to reply. Reply as... Cancel Krzysztof Gołębiowski David H Nebinger 5 Months Ago - Edited Ok, thanks for the hint, I'll try the DispatchTriggerLocalService then. In terms of the first job creation, I actually prefer to trigger this code on every deployment. Then it will check if the job already exists (using external reference code if exists or another kind of key) and create it if not. This way, if anyone breaks it from the Control Panel or does any other modification, I can just ask him to remove the job and redeploy the module. The UpgradeProcess though (from what I remember) is run only once, and rerunning it requires deleting an entry from the database. Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You could use an @Activate to handle the check for the existing job, the challenge here though is what if the admin really wants that initial job registration not to be there? You'd keep recreating it on them. IMHO it's better that they just re-create the job if they deleted or changed it by accident. RE: The upgrade process, yes it only runs once, but you never want to tamper with the database. Instead you can add another upgrade step, so 1.0 -> 1.1 -> 1.2 that uses the same upgrade process to recreate the job if it doesn't exist. Solves your problem and avoids database manipulation. Please sign in to reply. Reply as... Cancel Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Be careful, the old way stops working at some point. Somewhere in the u70s, I think. (I found the commit, but forgot again) We only noticed after upgrading, suddenly the jobs weren't executed anymore. It took us quite a while to figure out that the code for calling the old listeners had been removed. As David said, addDispatchTrigger works just fine to automatically create the triggers. JFYI: There is another way to do that, you could implement SchedulerJobConfiguration. https://github.com/liferay/liferay-portal/blob/master/modules/apps/trash/trash-web/src/main/java/com/liferay/trash/web/internal/scheduler/CheckEntrySchedulerJobConfiguration.java This has several disadvantages though, the dispatcher is far better. Please sign in to reply. Reply as... Cancel Krzysztof Gołębiowski Christoph Rabel 5 Months Ago - Edited In my case, all the old jobs still work, and I'm currently on 2023.Q3.2 release. During the upgrade, I looked into Liferay code, checked how they currently do it, and rewrote my code in the same way. The job class still extends the BaseMessageListener and the destination name is a @Component annotation parameter called "destination.name". Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You do save time/money/resources by not refactoring the code while you don't need to. I do however feel like the benefits of the new way should not be overlooked as they provide clear value, especially for administrators. Please sign in to reply. Reply as... Cancel Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Ok, maybe it didn't work "in between" for some versions or we did something "unexpected". Doesn't matter, as long as it works for you. Please sign in to reply. Reply as... Cancel
David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited So actually the only thing that we've defined here is the DispatchTaskExecutor, it's not even a scheduled job at the point this gets created. There are services surrounding the new framework including the DispatchTriggerLocalService. If I were going to be automatically scheduling jobs, I would use an UpgradeProcess implementation that leveraged the DispatchTriggerLocalService's addDispatchTrigger() to create the new job and then the updateDispatchTrigger() to set the scheduling details (start/stop dates, cron expression, etc). Please sign in to reply. Reply as... Cancel Krzysztof Gołębiowski David H Nebinger 5 Months Ago - Edited Ok, thanks for the hint, I'll try the DispatchTriggerLocalService then. In terms of the first job creation, I actually prefer to trigger this code on every deployment. Then it will check if the job already exists (using external reference code if exists or another kind of key) and create it if not. This way, if anyone breaks it from the Control Panel or does any other modification, I can just ask him to remove the job and redeploy the module. The UpgradeProcess though (from what I remember) is run only once, and rerunning it requires deleting an entry from the database. Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You could use an @Activate to handle the check for the existing job, the challenge here though is what if the admin really wants that initial job registration not to be there? You'd keep recreating it on them. IMHO it's better that they just re-create the job if they deleted or changed it by accident. RE: The upgrade process, yes it only runs once, but you never want to tamper with the database. Instead you can add another upgrade step, so 1.0 -> 1.1 -> 1.2 that uses the same upgrade process to recreate the job if it doesn't exist. Solves your problem and avoids database manipulation. Please sign in to reply. Reply as... Cancel
Krzysztof Gołębiowski David H Nebinger 5 Months Ago - Edited Ok, thanks for the hint, I'll try the DispatchTriggerLocalService then. In terms of the first job creation, I actually prefer to trigger this code on every deployment. Then it will check if the job already exists (using external reference code if exists or another kind of key) and create it if not. This way, if anyone breaks it from the Control Panel or does any other modification, I can just ask him to remove the job and redeploy the module. The UpgradeProcess though (from what I remember) is run only once, and rerunning it requires deleting an entry from the database. Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You could use an @Activate to handle the check for the existing job, the challenge here though is what if the admin really wants that initial job registration not to be there? You'd keep recreating it on them. IMHO it's better that they just re-create the job if they deleted or changed it by accident. RE: The upgrade process, yes it only runs once, but you never want to tamper with the database. Instead you can add another upgrade step, so 1.0 -> 1.1 -> 1.2 that uses the same upgrade process to recreate the job if it doesn't exist. Solves your problem and avoids database manipulation. Please sign in to reply. Reply as... Cancel
David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You could use an @Activate to handle the check for the existing job, the challenge here though is what if the admin really wants that initial job registration not to be there? You'd keep recreating it on them. IMHO it's better that they just re-create the job if they deleted or changed it by accident. RE: The upgrade process, yes it only runs once, but you never want to tamper with the database. Instead you can add another upgrade step, so 1.0 -> 1.1 -> 1.2 that uses the same upgrade process to recreate the job if it doesn't exist. Solves your problem and avoids database manipulation. Please sign in to reply. Reply as... Cancel
Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Be careful, the old way stops working at some point. Somewhere in the u70s, I think. (I found the commit, but forgot again) We only noticed after upgrading, suddenly the jobs weren't executed anymore. It took us quite a while to figure out that the code for calling the old listeners had been removed. As David said, addDispatchTrigger works just fine to automatically create the triggers. JFYI: There is another way to do that, you could implement SchedulerJobConfiguration. https://github.com/liferay/liferay-portal/blob/master/modules/apps/trash/trash-web/src/main/java/com/liferay/trash/web/internal/scheduler/CheckEntrySchedulerJobConfiguration.java This has several disadvantages though, the dispatcher is far better. Please sign in to reply. Reply as... Cancel Krzysztof Gołębiowski Christoph Rabel 5 Months Ago - Edited In my case, all the old jobs still work, and I'm currently on 2023.Q3.2 release. During the upgrade, I looked into Liferay code, checked how they currently do it, and rewrote my code in the same way. The job class still extends the BaseMessageListener and the destination name is a @Component annotation parameter called "destination.name". Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You do save time/money/resources by not refactoring the code while you don't need to. I do however feel like the benefits of the new way should not be overlooked as they provide clear value, especially for administrators. Please sign in to reply. Reply as... Cancel Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Ok, maybe it didn't work "in between" for some versions or we did something "unexpected". Doesn't matter, as long as it works for you. Please sign in to reply. Reply as... Cancel
Krzysztof Gołębiowski Christoph Rabel 5 Months Ago - Edited In my case, all the old jobs still work, and I'm currently on 2023.Q3.2 release. During the upgrade, I looked into Liferay code, checked how they currently do it, and rewrote my code in the same way. The job class still extends the BaseMessageListener and the destination name is a @Component annotation parameter called "destination.name". Please sign in to reply. Reply as... Cancel David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You do save time/money/resources by not refactoring the code while you don't need to. I do however feel like the benefits of the new way should not be overlooked as they provide clear value, especially for administrators. Please sign in to reply. Reply as... Cancel Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Ok, maybe it didn't work "in between" for some versions or we did something "unexpected". Doesn't matter, as long as it works for you. Please sign in to reply. Reply as... Cancel
David H Nebinger Krzysztof Gołębiowski 5 Months Ago - Edited You do save time/money/resources by not refactoring the code while you don't need to. I do however feel like the benefits of the new way should not be overlooked as they provide clear value, especially for administrators. Please sign in to reply. Reply as... Cancel
Christoph Rabel Krzysztof Gołębiowski 5 Months Ago - Edited Ok, maybe it didn't work "in between" for some versions or we did something "unexpected". Doesn't matter, as long as it works for you. Please sign in to reply. Reply as... Cancel