Announcement Announcement Module
Collapse
No announcement yet.
How to deploy the same app twice with different context routes and datasources Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to deploy the same app twice with different context routes and datasources

    A very common use case for us is to deploy a WAR file twice to the same app server, changing two things on it.

    i) the context route
    ii) the JNDI ref of dataSource that the WAR uses, so you can point each app at a different datasource

    This scenario is used for something like a UAT and TRAINING environment on the same box.

    How would you do it in S2AP ?

    If dataSources are injected in from bundles as opposed to JNDI, how do you change which dataSource bundle the WAR uses, without changing the manifest within the WAR ?

    How do you deploy the same app twice, being that within the PAR (I guess, I have not looked at PARs in great detail yet, but assuming that has a verson number and unique name like any other bundle) is a unique entity ?

  • #2
    How to deploy the same app twice with different context routes and datasources

    Hi Paul,

    i) Regarding the context path, there is already a JIRA issue opened to track this here:

    https://issuetracker.springsource.com/browse/PLATFORM-70

    ii) Assuming you have total control over which artifacts are deployed to the Platform for both the UAT and Training environments, you could simply deploy a different DataSource bundle which publishes the same service via the OSGi Service Registry but contains the appropriate connection settings for the current environment. However, if you are deploying the DataSource bundle alongside the WAR within a PAR (which you don't want to modify between UAT and Training), you will then need a solution which externalizes the configuration. Possible solutions here include:

    a) ConfigAdmin: we are currently considering packaging ConfigAdmin with the Platform and possibly providing support for using it if necessary
    b) A colleague of mine actually references an externalized configuration service (i.e., "service" in the sense of the OSGi Service Registry) which he manages via JMX. Thus if you were to go that route, you could retrieve your DataSource connection settings from the configuration service, which you could then configure for the appropriate environment.

    Regards,

    Sam

    Comment

    Working...
    X