Make hotdeployer (DeploymentService) understand maven version numbers and undeploy old version when a new zip with a different version number is deployed

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: To be reviewed To be reviewed
  • Resolution: Unresolved
  • Affects Version/s: 3.2.1
  • Fix Version/s: None
  • Component/s: Core: Deployment
  • Labels:
    None
  • Environment:

    Standalone

  • User impact:
    Very Low
  • Similar Issues:
    None

Description

It would be great if the hot deployer would understand maven version numbers.

Example:

myapp-1.0.zip is deployed
myapp-1.1.zip is deployed

Result: Two apps in the apps folder

A better solution would be if the hot deployer would understand that myapp-1.1 is a new version of myapp-1.0 and thus undeploy v1.0 before deploying v.1.1

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dirk Olmes added a comment -

-1
If we make this behaviour default, what would people use that do want different versions of the same app (e.g. for supporting different message format versions)?

Show
Dirk Olmes added a comment - -1 If we make this behaviour default, what would people use that do want different versions of the same app (e.g. for supporting different message format versions)?
Hide
Permalink
Arne Seime added a comment -

I would add support for a new message format within the same app (ie by using a second mule config file).

If you listen on a socket endpoint you cannot run two versions of the same app without using a different port anyway (BindException).

Show
Arne Seime added a comment - I would add support for a new message format within the same app (ie by using a second mule config file). If you listen on a socket endpoint you cannot run two versions of the same app without using a different port anyway (BindException).
Hide
Permalink
Dirk Olmes added a comment -

Ok here's a slightly different scenario: you receive serialized Java objects through, say, TCP in your app. This app is deployed as my-app-1.0.zip. New requirements force you to modify the classes of those serialized Java objects.

Now you have a scenario where (even if only for a migration period) two kinds of payload can arrive. However, the same classes must be used for both payload types. How would your approach deal with this situation?

Show
Dirk Olmes added a comment - Ok here's a slightly different scenario: you receive serialized Java objects through, say, TCP in your app. This app is deployed as my-app-1.0.zip. New requirements force you to modify the classes of those serialized Java objects. Now you have a scenario where (even if only for a migration period) two kinds of payload can arrive. However, the same classes must be used for both payload types. How would your approach deal with this situation?
Hide
Permalink
Arne Seime added a comment -

I understand your point Dirk, you'll need two apps to deal with the two implementation of the same class.

Anyway, what about adding a property in mule-deploy.properties defining whether to keep or remove current version?

Show
Arne Seime added a comment - I understand your point Dirk, you'll need two apps to deal with the two implementation of the same class. Anyway, what about adding a property in mule-deploy.properties defining whether to keep or remove current version?
Hide
Permalink
Arne Seime added a comment -

Patch for 3.2.1.

To enable hotdeploy add this to conf/wrapper.conf

wrapper.java.additional.<n>=-Dmule.replace.version=TRUE

Show
Arne Seime added a comment - Patch for 3.2.1. To enable hotdeploy add this to conf/wrapper.conf wrapper.java.additional.<n>=-Dmule.replace.version=TRUE

People

  • Assignee:
    Unassigned
    Reporter:
    Arne Seime
Vote (3)
Watch (1)

Dates

  • Created:
    Updated: