On Thursday, November 8, 2012 9:19:56 AM UTC-8, Dan Wilson - 
[email protected] wrote:
>
> One way to look at this is the parent bean factory is not controlled by 
> ModelGlue. It's expected this will be instantiated and passed to Model 
> Glue. (Look in ModelGlue.cfm)
>
> Reloading the Parent Bean Factory is the responsibility of the parent bean 
> factory control mechanism. So, if you need to restrict access to this, you 
> need to do it in the location where you reload your parent bean factory.
> You may consider creating your new beanfactory in a separate application 
> variable, then switch it over when it is instantiated. But as it stands, I 
> don't see how MG can get involved with this process, because the parent 
> bean factory lives inside a different context.
>
>
I don't disagree per se, but since this is the general design paradigm of a 
parent bean factory and continuous deployment and/or code pushes without 
interrupting users is a significantly valuable goal, I think we should look 
at it.

I think the problem is that MG's setParent() for the parent_bean_factory is 
not thread-safe.

I'm trying alternative approaches today using onApplicationStop() but that 
results in even more weirdness.  Request scope variables set in a 
controller don't exist when I get to a view template... I'm going to try to 
start at the beginning, load testing each step, and see where I can get 
to.  Also might see if I can setup a basic MG app and demonstrate it there 
too.


Brian

-- 
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog

You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en

Reply via email to