vertx filesystem watch

[Gadi Eichhorn]

Hi All,

is there a file system watch (async) option in vertx? looking for file changes (update / create / delete) so I can reload internal state.

anyone have code example how this may work.

Thanks,

G.

[Clement Escoffier]

Hi,

Now we don’t have an asynchronous FS watcher at the moment. The watch system we use for the redeploy is not asynchronous (it’s executed outside of vert.x to start / restart vert.x apps).

However, based on this code, it should be easy to implement one: https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/impl/launcher/commands/Watcher.java. 

Clement

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/de6e37c0-0fa3-48f3-a82c-df9c194bf6a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gadi Eichhorn]

Thanks Clement,

Is this reloading code and deploying verticles as they change?

How do I set it to work as part of development process?

Thanks,

G.

[Clement Escoffier]

On 17 Jun 2017, at 10:18, 'Gadi Eichhorn' via vert.x <ve...@googlegroups.com> wrote:

Thanks Clement,

Is this reloading code and deploying verticles as they change?

Yes

How do I set it to work as part of development process?

You have three ways:

* Using the vertx cli ou the launcher class - compilation managed somewhere else - http://vertx.io/docs/vertx-core/java/#_live_redeploy (the compilation process can be hooked to run when a change is detected)

* With gradle - https://github.com/vert-x3/vertx-examples/tree/master/gradle-redeploy

* Or directly included in the vertx-maven-plugin https://vmp.fabric8.io (and more precisely https://vmp.fabric8.io/#vertx:run)

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/474a28c6-a882-4d3f-80d4-7e4e5bfe9ab8%40googlegroups.com.

[Gadi Eichhorn]

Thanks,

Can a running Vertx discover changes to Artifacts and redeploy them?

Can the services module -> http://vertx.io/docs/#services be used in a similar way (factory)? I was thinking of another workflow were you have the launcher watching your artifacts and loading services as they are refreshed/built? 

Gradle can watch your src for test and build. this can be useful if all you need is to deploy a new verticle and not the full app.  gradle doc -> https://docs.gradle.org/current/userguide/continuous_build.html

Kind of similar to how EE works, reloading WAR as you deploy them to a folder.

so my idea is to watch a folder and discover any changes to jars, then un-deploy the matching jar and redeploy the new one.

if the manifest has the right verticle class listed you can use the vertx.deploy(verticle) call, sounds like a custom service factory.

any tips before I continue?

[Clement Escoffier]

On 17 Jun 2017, at 16:08, 'Gadi Eichhorn' via vert.x <ve...@googlegroups.com> wrote:

Thanks,

Can a running Vertx discover changes to Artifacts and redeploy them?

Can the services module -> http://vertx.io/docs/#services be used in a similar way (factory)? I was thinking of another workflow were you have the launcher watching your artifacts and loading services as they are refreshed/built? 

Gradle can watch your src for test and build. this can be useful if all you need is to deploy a new verticle and not the full app.  gradle doc -> https://docs.gradle.org/current/userguide/continuous_build.html

Kind of similar to how EE works, reloading WAR as you deploy them to a folder.

so my idea is to watch a folder and discover any changes to jars, then un-deploy the matching jar and redeploy the new one.

if the manifest has the right verticle class listed you can use the vertx.deploy(verticle) call, sounds like a custom service factory.

any tips before I continue?

Vert.x redeploy feature restarts the application (it stops it and restarts it). This choice has been made because it avoid leaks and Vert.x is very fast to start (and so restart). Gradle and Maven integrations just manage the compilation and let Vert.x detects the changes and restarts. In no way it’s a dynamic module layer. If it’s what you are looking for, most Vert.x modules have OSGi metadata and can be used in OSGi. We have examples there: https://github.com/vert-x3/vertx-examples/tree/master/osgi-examples.

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/d667fc17-0f03-44e9-94b5-ec8f027e077d%40googlegroups.com.

[Gadi Eichhorn]

Thanks, that's a good point, I don't want to go as far as OSGi for now.

the watch and reload code was useful, will explore from there.