Announcement Announcement Module
No announcement yet.
Watched Repository and Spring Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Watched Repository and Spring

    I've been trying out dm Server 2.0 M2 and some of the latest snapshots and am very excited about the new features in 2.0. But I keep running into a problem with Spring when Hibernate is installed after the server has started. I've setup a watched repository and started my server with the pickup and my watched directory empty. I then copy the 3rd party bundles (Hibernate included) into the watched repository. Then when I copy my web bundle or plan file into the pickup directory I get the following error:

    com.springsource.kernel.osgi.framework.ExtendedCla ssNotFoundException: org.hibernate.cfg.Configuration in KernelBundleClassLoader: [bundle=org.springframework.orm_3.0.0.CI-282]

    I'm guessing it's because my bundle is using a Spring bundle that was already installed without the optional Hibernate dependency. Is this a problem that requires cloning to solve?

    I should also note that if I then restart the server, everything starts fine.

  • #2
    Glad you're enjoying the new features! Hopefully it's not too much of a roller-coaster ride. ;-)

    The problem is a so-called "dropped optional". If any of a bundle's optional package imports cannot be satisfied when the bundle is resolved, the unsatisfiable imports are discarded and then the bundle is not wired to the corresponding packages.

    A (n optional) package import is unsatisfiable when either there is no export matching the import or when there are one or more exports that match the import, but wiring to any one of them would cause the importing bundle to fail to resolve because of a uses constraint violation.

    You are observing a dropped optional package import because there is no export matching the import when the importing bundle is resolved.

    The potential solutions to this are:
    1. ensure the exporting bundle is present in the repository before it is needed,
    2. refresh the bundle(s) with the dropped optional so the optional import becomes wired,
    3. automatic cloning.

    Automatic cloning should happen in this case and I'm not sure why it isn't. The most obvious cause is that one or more uses constraints are missing (or possibly wrong). Or maybe the uses constraint isn't being violated because distinct bundles of your application are importing spring and hibernate. In the latter case, there may be missing uses constraints in your application.

    If you could give a bit more detail, I can help you figure out what to try next.


    • #3
      Thank you for your quick reply. Here is the manifest file for the bundle I mentioned:

      Manifest-Version: 1.0
      Bundle-Name: DAO Module
      Import-Package: com.mysql.jdbc;version="[5.1.6,5.1.6]",
      org.springframework.orm.hibernate3;version="[3.0.0,4.0.0]",;version ="[3.0.0,4.0.0)"
      Bundle-ManifestVersion: 2
      Bundle-SymbolicName: com.spintop.dao.hibernate
      Bundle-Version: 1.2.0
      Import-Library: org.springframework.spring

      I hope this helps. I think it has something to do with the orm imports.


      • #4
        If this problem is reproducible with that one bundle, then some of the theories I was kicking around don't apply.

        Please could you post the console log so I can see what is being cloned and when?

        Have you reproduced this on a recent nightly build? Some issues in cloning have been fixed relatively recently and I haven't had a chance to do the achaeology and determine which fixes were present in M2.


        • #5
          Attached is the logs (minus the trickle log file because of its size) from the following steps:

          1. downloaded springsource-dm-server-2.0.0.CI-R337-B285 (latest as of June 25, 2009)
          2. deleted everything from its pickup directory
          3. setup the bundles/usr directory as a watched repository (replaced existing settings)
          4. started the server
          5. copied all the dependencies of dao.hibernate bundle to bundles/usr
          6. deployed dao.hibernate via Eclipse


          • #6
            I can't understand why cloning isn't kicking in and helping. It could be a bug in dm Server or a result of the Equinox resolver providing unhelpful (for cloning purposes, that is) diagnostics in this particular case.

            If you would like to raise a issue on JIRA and provide the testcase and steps to reproduce, it will be added to the backlog. The issue may not be solvable if Equinox is the cause. We are looking to improve the cloning algorithms in the longer term, but a piece of research needs to be done to prove that is possible.

            If you need a workaround, try manually cloning Spring using import-library or import bundle with the sharing:=clone directive.


            • #7
              Thank you.