| I think though that Mark is interested in separating out the reloading of CS from M2, so it is not completely managed by it. I think we could easily add a reload key to the plug in, allowing it to by default reload every time, but if you define a reload key (easily set it to the same as the M2 one, or a different one) each app would not always reload CS when it loads
C
BTW, if that doesn't make a lot of sense, I have been sick for over a week... Chris Scott
On Dec 18, 2006, at 3:38 PM, Kurt Wiersma wrote: I don't know if it helps but it should be pretty easy to make this change now. All you have to do is add a couple of lines of code to your application.cfc and then change the config on the M2 apps. No biggie just thought I would mention that you don't really need to re-write a bunch of stuff. That is the beauty of Coldspring. :)
--Kurt
On 12/17/06, Mark Mandel <[EMAIL PROTECTED]> wrote: Kurt -
You are probably correct in that statement, but unfortunatley we're
too far into what we are doing to rip it apart again and resort it by
parent / child relationships.
Pretty much everything is needed in each aspect of the application, so
this is actually the easiest solution for now.
But I totally see your point on this, and if I could go back and write
everything we had all over again, I may well have written it that way.
Mark
On 12/18/06, Kurt Wiersma <[EMAIL PROTECTED]> wrote:
> The other option we have it setting a parentBeanFactory in the
> application scope, in the application.cfc and setting it as the parent
> bean factory, and having each machii application point to an empty
> coldspring XML config file, which seems to be a bit of a workaround.
>
> I actually recommend that option if I am understanding your situation
> correctly. The problem you will probably run into is that each Mach II app
> in your application scope needs access to the services defined in your
> coldspring config file. Your CS config file right now is loaded the first
> time each application is hit for the first time. Since all your apps need to
> share the same bean factory the best option would be to initialize that bean
> factory in the applicationStart method of application.cfc and place it in
> the application scope. Then have each of your Mach II apps pick that bean
> factory up as the parent bean factory. As your apps grow they can then
> override or use parts of the application wide bean factory you setup as a
> parent.
>
> --Kurt
>
>
> On 12/17/06, Mark Mandel <[EMAIL PROTECTED]> wrote:
> >
> > Another question to you boys about the
> > 'placeFactoryInApplicationScope' attribute.
> >
> > We have multiple machii applications within our system, all sitting
> > under the same Application.cfc, and they all use the same ColdSpring
> > file.
> >
> > I had assumed that if we set
> placeFactoryInApplicationScope=true on
> > all our machii applications, they would check to see if ColdSpring was
> > already loaded in the application, and if it was, simply pick up the
> > beanfactory that was already stored in the application scope, and use
> > that.
> >
> > Instead it seems to load a new CS beanfactory, and overwrites the one
> > in the application scope.
> >
> > Is this the way it is meant to be?
> >
> > The other option we have it setting a parentBeanFactory in the
> > application scope, in the application.cfc and setting it as the parent
> > bean factory, and having each machii application point to an empty
> > coldspring XML config file, which seems to be a bit of a workaround.
> >
> > I can see that there are hooks in place in the BeanFactoryUtils.cfc to
> > check for the existence of named factories, and the functionality
> > simply becomes a check to see if placeFactoryInApplicationScope is
> > true, and if the bfUtils.namedFactoryExists (), then get the
> > namedFactory from the bfUtils and set it to the loca version.
> >
> > So.. is this something rediculous, or just something we just haven't
> > talked about before?
> >
> > Mark
> >
> >
> > --
> > E: [EMAIL PROTECTED]
> > W: www.compoundtheory.com
> >
> >
>
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
|
