Announcement Announcement Module
Collapse
No announcement yet.
advice on moving to production server Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • advice on moving to production server

    Using Spring DM 1.2.0 and Spring DM Server (very recent snapshot). Seeking some advice on production deployment options for my situation:

    1. I have a legacy WAR that's been *mostly* converted to a "shared services" WAR. This WAR serves up the web side of my app, and has a lot of code that is seriously OSGi unfriendly (it has Grails in it). It's not feasible to break up this WAR any further - I'm going to have to live with it until I can slowly replace it entirely with bundles.

    2. Alongside this I have a few dozen Spring DM bundles that provide the bulk of the services and domain layer.

    Running the app on my development machine is easy with Eclipse and the Spring DM Server tools. I can boot up my bundles in a defined order, and when they're done I can drop the WAR file into the pickup directory. The app boots fine and everyone is happy.

    Here's my dilemma. I'd like to move everything to a production server running Spring DM Server. I need to be able to swap in and out bundles at runtime without tearing down the WAR on every bundle event. I'd also like to have a way for the server to survive a reboot. Below are the options I've considered and the reasons I can't fully implement any of them. I'm *hoping* that my facts are wrong on one or more of these options, or that someone has an idea that I haven't thought of.

    1. Use a .plan file to dictate the bundles to start, in order, with the WAR as the last bundle. This won't work because .plan files don't support WAR files.

    2. Use a .plan file to start *just* my bundles, in order, and then drop the WAR in the pickup directory. I could live with this, but given that I need to "hot swap" bundles, I want the atomicity of the .plan file to be false. And since I need the WAR to "see inside" to the bundles' services, I need to declare the scope of the .plan file to "global". When I tried to do this, I get an error from the server that I can't choose atomic=false and scope=global at the same time. I'm aware that services can "punch out" of their scope with

    Code:
     <osgi:service-properties>
            <entry key="com.springsource.service.scope" value="global" />
        </osgi:service-properties>
    but I need my packages to be visible to the WAR file as well, not just the services.

    3. Drop all my bundles into the pickup directory one by one, in the order I want, then drop the WAR in. This won't survive a reboot and obviously isn't very elegant.

    Hope this all makes sense. Any ideas would be greatly appreciated.

  • #2
    We definitely intend to support unscoped and non-atomic plans in 2.0. Plans will also be able to contain WAR files. So options 1 and 2 are simply not available right now.

    Option 3 should work however. The kernel maintains a recovery log of the items deployed in the hot deploy directory and will redeploy them in the same order on restart. Clearly option 3 needs a bit of careful handling because if you drop files into the pickup directory in very quick successision, the kernel may "spot" them in the "wrong" order.

    The robust way to solve this problem is to use Spring DM and then the service damping will cope with bundles being started in the "wrong" order.

    You then have to consider bundle resolution because of package dependencies. One way to approach this is to put the service bundles upon which there are package dependencies from the WAR or other service bundles in a repository, e.g. in the repository/bundles/usr directory. Then when the WAR file is deployed, the bundles it needs to be wired to will automatically be installed and started.

    With a bit of luck, you may be able to get to the point where all the service bundles go in a repository and deploying the WAR file is sufficient to drag them all in. I guess this would only not be the case if you had separated interface from implementation and had service bundles upon which there was no package dependency. You'd have to deploy these also.

    I hope that helps. It doesn't sound like you're very far from a solution that will work with M2.

    Comment


    • #3
      Originally posted by Glyn Normington View Post
      We definitely intend to support unscoped and non-atomic plans in 2.0. Plans will also be able to contain WAR files. So options 1 and 2 are simply not available right now.
      That's great to hear. Looking forward to this feature.

      Option 3 should work however. The kernel maintains a recovery log of the items deployed in the hot deploy directory and will redeploy them in the same order on restart.
      This is exactly the tidbit of information that I was hoping for. I had no idea the server kept a recovery log. I'm going to experiment with it today - hopefully this will be enough to meet my short term needs.

      The robust way to solve this problem is to use Spring DM and then the service damping will cope with bundles being started in the "wrong" order.

      You then have to consider bundle resolution because of package dependencies. One way to approach this is to put the service bundles upon which there are package dependencies from the WAR or other service bundles in a repository, e.g. in the repository/bundles/usr directory. Then when the WAR file is deployed, the bundles it needs to be wired to will automatically be installed and started.

      With a bit of luck, you may be able to get to the point where all the service bundles go in a repository and deploying the WAR file is sufficient to drag them all in. I guess this would only not be the case if you had separated interface from implementation and had service bundles upon which there was no package dependency. You'd have to deploy these also.
      That would be very slick. I have about 100 bundles now, so I doubt it will work on my first attempt. But definitely another direction to work towards.

      I hope that helps. It doesn't sound like you're very far from a solution that will work with M2.
      Thanks very much for these pointers. Keep up the good work!

      Comment

      Working...
      X