Announcement Announcement Module
Collapse
No announcement yet.
Implications of app close from within managed bean Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • bennini
    started a topic Implications of app close from within managed bean

    Implications of app close from within managed bean

    I have a standalone application with a configuration setup wizard that is run the first time the application is launched. the beans needed by this setup wizard are defined within their own XML bean definition file which is only loaded if the wizard needs to be run.

    all beans in the wizard context are singletons, including the main ConfigurationSetupWizard object which is injected with the various setup panels (also beans).

    so i instantiate the wizard's application context, then fetch the ConfigurationSetupWizard from the context using getBean()

    once the user completes the setup wizard, i load a new app context with beans that are needed by the actual application itself.

    i am wondering if it is safe for the ConfigurationSetupWizard (a managed bean) to close the application context that created it. of course in order for it to do this, the ConfigurationSetupWizard needs to be context aware but that is ok.

    my main goal is to save resources.

  • bennini
    replied
    Im not sure if a RefreshableApplicationContext really solves anything in this case.

    As far as i can tell, a refreshable application context allows one to tear down the bean factory that it is wrapping and reload/initialize it. it doesn't allow one to tear down the internal bean factory (and managed beans), then refresh it using a new, different bean definition xml file, for example.

    nor does that answer the question of whether it is safe for a managed bean to close the application context that created it.

    I have the following application context hierarchy:

    applicationContext-config.xml
    applicationContext-base.xml (requires [config] as parent)
    applicationContext-setupwizard.xml (requires [config] as parent)
    applicationContext-gui.xml (requires [base] as parent)

    at the moment, the first time the application is run, i instantiate:
    [config] and [setupwizard]. then, once the setupwizard has completed and without shutting down the JVM, i want to tear down [setupwizard] and instantiate [base] and [gui].

    subsequent application launches will simply load:
    [config] and [base] when running in headless mode
    or
    [config], [base] and [gui] when running with a user interface

    i never reload a given context more than once within a JVM instance, therfore i dont see how a refreshable application context could help.

    my main question is whether a bean that belongs to the [setupwizard] context can close the application context that created it?

    additionally, if i create the [config] context then the [setupwizard] context with [config] as the parent, and then close the [setupwizard] context, does that destroy all beans in the [config] context as well?

    Leave a comment:


  • Jabberz
    replied
    You probably want to look at the Refreshable Application Contexts, which should give you what you're looking for in changing out bean factories in a resource efficient way.

    I think it's possible you could do what you say - load up a context, do the work, then close it out and create a new one, but at the very least that's going to have a fair amount of object creation and destruction in it.

    You could probably try that out, and compare say the ConfigurableApplicationContext in JMeter and see which one is more efficient on the resources.

    Leave a comment:

Working...
X