Announcement Announcement Module
Collapse
No announcement yet.
Plan bundle redeployment Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Plan bundle redeployment

    I've created a plan and put the bundles in the repositories/usr directory. Everything works fine, but when I try to redeploy some bundle that is included in the plan nothing happens. Is it possible to redeploy bundles that are part of a plan?

  • #2
    The current support for refresh does not cover all artifact types in all scenarios.

    In fact we have a meeting today to discuss the design of refresh in the context of plans.

    In the scenario you describe, I wonder how you are attempting to "redeploy" a bundle of the plan. Did you replace the bundle in repository/usr? What next?

    You see simply changing the contents of a repository won't provoke dm Server to refresh anything.

    Comment


    • #3
      Yeah, I thought it would work like the pickup folder, because it is set as a 'watched' folder in the configuration. If this is not the case, then maybe I'll implement my own bundle that will be checking the usr directory for changes. I certainly need my bundles to be updated automatically.

      Comment


      • #4
        Fair enough.

        I'm sure other users may get the wrong impression too. We need to make it abundantly clear that, from dm Server's perspective, repositories are simply places from which to install artifacts. Repositories have differing semantics in terms of how they keep their content up to date, but repositories never "push" content into dm Server.

        The rationale behind this is that we don't want to overload dm Server. In general, we want to load just the artifacts that the user has requested to be deployed plus their dependencies so the runtime overhead is minimal.

        Comment


        • #5
          I too am very interested on this feature and looking forward for it.

          Feature hear i mean is updating a bundle inside plan.

          I don mind triggering this individual bundle update in the respective dm server admin.

          But my question is , why do you want to live it the developer , can a option be given in the propertyfile of individual dm servers to automatically update this bundle or not based on refresh interval.?

          This will be helpful in production environments when we have cluster of many DM servers.

          Comment


          • #6
            We don't have such a user story on our backlog, so feel free to add one.

            Of course, it would be possible for a user to to deploy a bundle which periodically did an update of other bundles using the JMX interface.

            Comment


            • #7
              I've just now discovered something interesting...

              I've created a bundle that is scanning a directory and starting bundles which it finds there (just like dm server does with pickup). I've noticed that it's not the same if I let the server load a bundle from pickup, or if I start it from my bundle. The bundle in question is importing Hibernate (by using Import-Library), and I use it in a bean that is created by spring (it's defined in META-INF/spring/context.xml). If I load the bundle from pickup it works, but if I load it with my loader bundle, then I get a ClassNotFoundException for org.hibernate.Session. I think this may be a bug, because it only happens in v1.0.2, when I tried it in v2.0M6 everything worked.

              What do you think? Have I run into a bug, or is this excpected behavior, that has been somehow improved in v2?

              Comment


              • #8
                It very much depends on how "I load it with my loader bundle" is implemented. Please could you elaborate.

                For instance, if you are installing the bundle via a BundleContext, then you wouldn't get Import-Library support in v1 or v2. On the other hand, if you are installing via JMX, then it *should* work in v1 as well as v2, but I'd like to know which MBean and which operation you are using in that case.

                Comment


                • #9
                  Originally posted by Glyn Normington View Post
                  We don't have such a user story on our backlog, so feel free to add one.

                  Of course, it would be possible for a user to to deploy a bundle which periodically did an update of other bundles using the JMX interface.


                  I have created ticket for updating DM servers based on update in the repository.

                  https://issuetracker.springsource.com/browse/DMS-1956


                  I assume there is already a story for updation of bundle inside a plan.

                  Comment


                  • #10
                    Originally posted by sudheerk84 View Post
                    I have created ticket for updating DM servers based on update in the repository.

                    https://issuetracker.springsource.com/browse/DMS-1956


                    I assume there is already a story for updation of bundle inside a plan.
                    Thanks for the new story. Yes, we already have a task to get bundle update within a plan working correctly.

                    Comment


                    • #11
                      This is interesting then, because I do it from BundleContext, and it works in v2

                      If it is just some random thing, that gets it working for me in v2, then maybe I stop using Import-Library or load them through JMX. It shouldn't be a problem. On the other hand I think that the same rules should apply to loading from BundleContext. It's not nice if I have to distinguish between different methods of loading, what I can use in Manifest and what I cannot.

                      Comment


                      • #12
                        Yes, you're right. I forgot that, in v2, Import-Library and Import-Bundle are expanded even when a bundle is installed using a bundle context. That should continue to work reliably in v2.

                        Comment

                        Working...
                        X