Announcement Announcement Module
Collapse

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
SpringDM question Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SpringDM question

    I have an existing application that I am converting to OSGI and have some questions about using SpringDM.

    Prior to OSGI I loaded the application context using ClassPathXmlApplicationContext and access necessary beans. A necessary bean is now in a different bundle as a service. I thought I could aquire the service by implementing the BundleContextAware interface to access it using the BundleContext. However, when I load the application context setBundleContext is never invoked. However, it is invoked when the application context is loaded by something else...the Extender Service...I think. Is there a way to get to the other instance of the application context to get to the bundle context...to acquire the service?

    That method did not seem like the best approach. Docs and sample code seem to point to using the osgi:reference tag to specify the service as a property for my bean in the existing application context file. I tried this approach but when I create the application context with this reference using ClassPathXmlApplicationContext I get an exception:

    org.springframework.beans.factory.parsing.BeanDefi nitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/osgi]

    So, I am looking for guidance for the best method to acquire a service and how to resolve the above exception?

  • #2
    If i understand correctly, you trying to access the service that is deployed as Spring Bean in the Application Context of another bundle.
    By default Application Context is exported as a service to the OSGi container, so you can look it up and access your beans. However such use is discouraged. The better approach would be to export your Spring Beans as OSGi services so you could look them up.

    Comment


    • #3
      Several questions:

      1) The bean I am looking for is exported as an OSGI service. It seems there are several options, what is the best way to "look it up"?

      2) As you say, "By default Application Context is exported as a service to the OSGi container", does this mean that rather than getting the Application Context by creating an instance of ClassPathXmlApplicationContext, I should look it up so that I can have a single instance of my context. I need the app context within my own bundle so I can lookup beans defined in my context. How is this done?

      3) Any insight into why I am getting the BeanDefinitionParsingException exception? Seems like something missing from the classpath?

      Sorry, maybe basic questions but being new to Spring and OSGI, things are a bit confusing. Thanks for any help.

      Comment


      • #4
        Hi Basil,

        I'm not sure if you still have this problem but first I would recommend reading the docs from 1.1 (currently at M1):
        http://static.springframework.org/os...eference/html/
        Inside an OSGI environment, there is no need for manual bootstrapping at least not when using Spring-DM. Using the extender model, Spring-DM automatically detects .xml configurations and will create a proper OSGi application context so you don't have to.
        As for questions:

        1) Using the OSGi service registry is the best way to go so exporting the beans as services is okay.

        2) see my answer above and the reference documentation. Spring-DM will create an application context for you and publish it as an OSGI service

        3) yes, you need the spring-dm namespace which is not wired - Spring-DM does this automatically when setting up the application context - go with 2) and your problem will go away.

        Comment

        Working...
        X