Announcement Announcement Module
No announcement yet.
Web Apps: application context creation Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Web Apps: application context creation


    I would like to straighten out my understanding of the different application contexts that can be created for web apps in dm server.

    1. Will dm extender create context for /META-INF/spring/*.xml entries in case of a war deployment?
    1.1 If yes, what its relationship to the app context created from web.xml configuration? Both root and servlet, i.e. does it become a parent of root webapp context if it is defined or servlet context if root is not defined?

    2. Is it approved practice to publish osgi services from root web app context given context-class of ServerOsgiBundleXmlWebApplicationContext?

    3. This is more of a Slices related: what is relationship of host application context to the Slice-child? Can Slice child create it's own root webapp context?

    The issue I am seeing is that services published from web apps or slices are never registered in services registry or somehow missed by <osgi:list/> processing.

    1. dmServer M4 (can't move to M5 because of Slices)
    2. deployment is done with scoped+atomic plan.

    I tried the following in the Host Slice bundle.
    <!-- locally created bean from spring-security-config.xml -->
    <osgi:service ref="hostFilterInvocationSecurityMetadataSource"          
                <entry key="app" value="host"/>
       <osgi:list id="securityMetadataSources"
                   cardinality="1..N" comparator-ref="securityMetadataSourceComparator" greedy-proxying="true"/>
        <bean id="securityMetadataSourceComparator" class="org.springframework.core.OrderComparator"/>
         <!-- service is published by another bundle -->
        <osgi:list id="userDetailsServices" interface=""
    This configuration always fails because <osgi:list id="securityMetadataSources"/> never finds any services. It is actually strange, because userDetailsServices publishing bundle also publishes FilterInvocationSecurityMetadataSource bean plus I am explicitly publishing a service in the same config file.

    From looking at the log files (trace on org.springframework.osgi) - I see that all beans are created properly and "hostFilterInvocationSecurityMetadataSource" is published as a service.

    Are the issues I am seeing related to the Slices or to the implementation of the deployers.
    This issue has been impeding me for a few days now and driving me nuts.

  • #2

    Not entirely sure what you are getting at, however I suspect it may be similar to:

    To try and answer question 3:

    As far as I'm aware, the relationship between the host application context and those of the Slice-child/ren, is that each host Servlet context contains a host web application context and n number of Slice-child web application contexts, all as attributes of this context. I.e. the servlet context created by the host contains web application contexts for both itself and its child slices. Can Slice child create it's own root webapp context? No - I don't think so. The host context has to be present for the slice to bind to it. To test this, try starting a slice without it's host. Nothing happens.

    The key to getting a handle to the host's web applications context is:

    WebApplicationContext.class.getName() + ".ROOT";
    The key to the slices is:

    "org.springframework.web.servlet.FrameworkServlet.CONTEXT." + <>

    Hope that clarifies as opposed to convolutes things.

    How come you are trying to publish services from the host / slices?

    Edit: See you saw the other thread, feel free to delete this.
    Last edited by wendigo; Oct 14th, 2009, 10:32 PM.


    • #3

      Thanks for response. You are right, it had something to do with spring security thread that you referenced. But I just wanted to get a clear idea what is allowed and what is not.

      Why did I want to publish a service from a web-app? To me it was the most logical solution and location to do it. Use case was very ui specific and did not require a new bundle with just a spring-context.xml in it.

      Confusing part was seeing all of the services getting published, i.e. spring dm would not bark at that usage.
      Last edited by dsklyut; Oct 14th, 2009, 11:27 PM.