execute only at first startup?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

execute only at first startup?

Max Spring
I've got a Karaf-based service.
Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
I'd like to automate this.

I'm thinking of using a marker file somewhere to indicate "first startup".
I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.

Or, is there something better for this scenario?

-Max
Reply | Threaded
Open this post in threaded view
|

RE: execute only at first startup?

Scott
You mean the logic should only execute if the service is "changed", but not in the case where the service is stopped and restarted?

-----Original Message-----
From: Max Spring [mailto:[hidden email]]
Sent: Thursday, June 07, 2018 7:40 PM
To: [hidden email]
Subject: execute only at first startup?

I've got a Karaf-based service.
Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
I'd like to automate this.

I'm thinking of using a marker file somewhere to indicate "first startup".
I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.

Or, is there something better for this scenario?

-Max

Reply | Threaded
Open this post in threaded view
|

Re: execute only at first startup?

Max Spring
Not sure I understand your notion of "service changed" :-)
I use the term "service" in a colloquial sense. I don't mean "OSGi service".

Let me try it that way:

My release build produces a self-contained tarball of the entire code of my service.
My "devops" automation (in Jenkins) deploys the tarball on a test VM together with the production data.

After this deployment, the very first time the Karaf container starts up, I want to run some initialization logic.
But only this very first time. Any subsequent Karaf container start up should not do this initialization any more.

-Max


On 06/07/2018 05:48 PM, Leschke, Scott wrote:

> You mean the logic should only execute if the service is "changed", but not in the case where the service is stopped and restarted?
>
> -----Original Message-----
> From: Max Spring [mailto:[hidden email]]
> Sent: Thursday, June 07, 2018 7:40 PM
> To: [hidden email]
> Subject: execute only at first startup?
>
> I've got a Karaf-based service.
> Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
> I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
> I'd like to automate this.
>
> I'm thinking of using a marker file somewhere to indicate "first startup".
> I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.
>
> Or, is there something better for this scenario?
>
> -Max
>
Reply | Threaded
Open this post in threaded view
|

Re: execute only at first startup?

David Jencks-2
In reply to this post by Scott
I don’t know if this is better...
I would use a configuration instead of a file. (Details assume karaf is using r7 ca, I don’t know if this is true yet)
Install the configuration from json in the bundle (this is the r7 bit). It needs 2 entries, current version and last updated version (initialized to 0).
Have a ds component requiring the configuration, and with a mandatory reference to config admin. In the activate method, where the configuration arrives as a parameter, compare the current and last updated versions and if they differ do your initialization, and then use ca to update the configuration so the versions match.

The current version could be hard coded in the class if that is easier than updating the json.

David Jencks
Sent from my iPhone

> On Jun 7, 2018, at 5:48 PM, Leschke, Scott <[hidden email]> wrote:
>
> You mean the logic should only execute if the service is "changed", but not in the case where the service is stopped and restarted?
>
> -----Original Message-----
> From: Max Spring [mailto:[hidden email]]
> Sent: Thursday, June 07, 2018 7:40 PM
> To: [hidden email]
> Subject: execute only at first startup?
>
> I've got a Karaf-based service.
> Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
> I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
> I'd like to automate this.
>
> I'm thinking of using a marker file somewhere to indicate "first startup".
> I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.
>
> Or, is there something better for this scenario?
>
> -Max
>
Reply | Threaded
Open this post in threaded view
|

Re: execute only at first startup?

cschneider
In reply to this post by Max Spring
How about storing the fact that the initialization is done in the data?

I have seen this with liquibase.
Liquibase is a tool that manages database updates. It stores the version of the installed data in a table. 
So when you install a new version it can do the necessary updates and then stores the new version.

Best
Christian

Am Fr., 8. Juni 2018 um 03:42 Uhr schrieb Max Spring <[hidden email]>:
Not sure I understand your notion of "service changed" :-)
I use the term "service" in a colloquial sense. I don't mean "OSGi service".

Let me try it that way:

My release build produces a self-contained tarball of the entire code of my service.
My "devops" automation (in Jenkins) deploys the tarball on a test VM together with the production data.

After this deployment, the very first time the Karaf container starts up, I want to run some initialization logic.
But only this very first time. Any subsequent Karaf container start up should not do this initialization any more.

-Max


On 06/07/2018 05:48 PM, Leschke, Scott wrote:
> You mean the logic should only execute if the service is "changed", but not in the case where the service is stopped and restarted?
>
> -----Original Message-----
> From: Max Spring [mailto:[hidden email]]
> Sent: Thursday, June 07, 2018 7:40 PM
> To: [hidden email]
> Subject: execute only at first startup?
>
> I've got a Karaf-based service.
> Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
> I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
> I'd like to automate this.
>
> I'm thinking of using a marker file somewhere to indicate "first startup".
> I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.
>
> Or, is there something better for this scenario?
>
> -Max
>


--
--
Christian Schneider

http://www.liquid-reality.de

Computer Scientist

Reply | Threaded
Open this post in threaded view
|

Re: execute only at first startup?

David Jencks-2
Well, you have to store the initialization state in some data somewhere :-)  Now we have 3 or 4 ideas:

I think the simplest solution is going to be with BundleContext.getDataFile:

you could put the logic in a bundle activator or possibly in a DS component activate method.

Create a file in the bundle private data area when the initialization completes and check for its existence before the initialization.

David Jencks

On Jun 7, 2018, at 10:56 PM, Christian Schneider <[hidden email]> wrote:

How about storing the fact that the initialization is done in the data?

I have seen this with liquibase.
Liquibase is a tool that manages database updates. It stores the version of the installed data in a table. 
So when you install a new version it can do the necessary updates and then stores the new version.

Best
Christian

Am Fr., 8. Juni 2018 um 03:42 Uhr schrieb Max Spring <[hidden email]>:
Not sure I understand your notion of "service changed" :-)
I use the term "service" in a colloquial sense. I don't mean "OSGi service".

Let me try it that way:

My release build produces a self-contained tarball of the entire code of my service.
My "devops" automation (in Jenkins) deploys the tarball on a test VM together with the production data.

After this deployment, the very first time the Karaf container starts up, I want to run some initialization logic.
But only this very first time. Any subsequent Karaf container start up should not do this initialization any more.

-Max


On 06/07/2018 05:48 PM, Leschke, Scott wrote:
> You mean the logic should only execute if the service is "changed", but not in the case where the service is stopped and restarted?
>
> -----Original Message-----
> From: Max Spring [mailto:[hidden email]]
> Sent: Thursday, June 07, 2018 7:40 PM
> To: [hidden email]
> Subject: execute only at first startup?
>
> I've got a Karaf-based service.
> Whenever I deploy a new revision of my service, I need to execute some code only at the very first startup.
> I have this first-time functionality available as a Karaf command which I currently run manually each time right after startup after a new deployment.
> I'd like to automate this.
>
> I'm thinking of using a marker file somewhere to indicate "first startup".
> I'd have a new bundle checking for this file when it starts up. When it detect the file, the bundle executes my business logic initialization and then deletes the marker file.
>
> Or, is there something better for this scenario?
>
> -Max
>


--
--
Christian Schneider

http://www.liquid-reality.de

Computer Scientist