The order of deployment

RE: RE: The order of deployment

2023-03-08T15:54:19Z

You don't have to worry about the indexers, those are triggered by code, not by data. If your modules are undeployed, so is the reindexing code, so reindexing will not be triggered.

RE: RE: The order of deployment

2023-03-06T16:58:47Z

Basically there is no support for a complete removal.

Everything else you are talking about is fully supported via your ServiceBuilder usage. I'd leverage an UpgradeProcess implementation to handle the initial data population myself.

But there is no support for an "uninstall" process along with a table/data cleanup. The table will be left as an orphan until a DBA finds a reason to go in and take it out, but because we recommend that DBAs (well, everyone, not just DBAs) stay out of the database, the table will linger as an orphan forever.

RE: RE: The order of deployment

2023-03-06T16:58:12Z

Thank you for your answer, it helped me to be less confused.

I would like to describe more about my expectations. My application should have a table to manage data, and I hope that when users install my application to run (which consists of 4 jar modules), this new table will be created once in the database, initialized with data from another table, and I want this new table will not be deleted after each restart or redeploy. I only want this table to be deleted when the user completely removes the application from the system, removes the jar file from the osgi folder.

So my question is, how can I accomplish this? Do users have to manually remove that table when they don't want to use my app? Or is there a way to automatically remove the table after uninstalling the application? As far as I know, uninstalling the application just moves the application to blacklist which undeploy the module.

I also feel that using @Activate and @Deactivate is not a good choice because the table is deleted and recreated after each restart or redeploy, but I really have no other way, especially the data indexing process is unstable (indexer.delete and indexer.reindex).

Thank you very much.

RE: The order of deployment

2023-03-03T17:11:57Z

Forgot the 3rd question - no, there is no way to delete the table on undeployment. Liferay doesn't see an "undeployment", it is just a deactivate without a later activate again, so there's no way to distinguish it because there is not enough context for it.

RE: The order of deployment

2023-03-08T21:49:59Z

You really shouldn't need to worry about this. Any @Reference must be satisfied before anything will happen.

The API module has no dependencies, so it will start on its own.

The service jar has a dependency on the api, so it will not be processed until the api is available.

The startup jar should have @Reference dependencies on the services, so it should not start until the services are available.

The web jar should also have @Reference dependencies on the services, so it should wait also. As far as the data is concerned, no one would be using your portlet at the instant deployment is happening, so it shouldn't care whether the startup jar has completed its work or not.

So basically, to answer your question, OSGi will handle the ordering correctly, you don't need to worry about it yoursefl.

For your second question, no there really isn't a way to clean up on undeploy. Your current process will fail because, as you deploy updates or even restart the instance, that will trigger the @Deactivate and then an @Activate code thus destroying any changes you have made.

And if your data is okay to destroy and recreate, I would suggest that maybe it shouldn't be persisted anyway. Persistence is for retaining data across restarts, etc. If your data doesn't need to persist, it should perhaps be constants or read from an xml or json file and just held in memory, no reason to pollute the database with stuff it doesn't need.

The order of deployment

2023-03-03T16:22:20Z

Hi,

I have questions related to publishing an app to the marketplace, installing and uninstalling the app, please help.

First of all, I would like to briefly talk about the app I am building. App includes 4 modules api.jar, service.jar, startup.jar, web.jar. The startup module has the purpose of initializing data for a table in the DB, and indexing this table every time it is deployed. In order for the app to work properly, it is required that the modules run in the order: api.jar -> service.jar -> startup.jar -> web.jar, if run out of order, the indexing process will not work properly .

I plan to publish this app to the marketplace. As far as I know, this app includes 4 jar files that can be packaged into a war or lpkg file.

My first question is: can I specify the order of deploying jar files when publishing the app? so that when the user installs the app, the packages are deployed in the correct order, as well as when the app is removed, the packages will be removed in the reverse order (web.jar -> startup.jar -> service.jar -> api.jar)

My second question is, is there any action for installing app and uninstalling app? Currently, my startup module uses @Activate and @Deactivate to initialize the table's data when deploying the module and delete the table's data when undeploying the module.

The third question is, is there a way to completely delete a table from the database when uninstalling the app to avoid junk data?

Thank you.