Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 18 21:17

    sneiland on v4.3.0

    (compare)

  • Apr 18 21:17

    sneiland on master

    (compare)

  • Jan 07 15:43
    lramirez925 commented #541
  • Jan 07 14:16
    matthewjones commented #541
  • Jan 07 01:31
    lramirez925 commented #541
  • Jan 06 21:01
    sneiland labeled #541
  • Jan 06 21:01
    sneiland assigned #541
  • Jan 06 21:01
    sneiland opened #541
  • Dec 16 2021 16:48
    sneiland labeled #540
  • Dec 16 2021 16:48
    sneiland labeled #540
  • Dec 16 2021 16:25
    tonyjunkes commented #540
  • Dec 16 2021 16:00
    lramirez925 commented #540
  • Dec 16 2021 15:48
    mjclemente opened #540
  • Oct 31 2021 20:52

    sneiland on fw1-538

    (compare)

  • Oct 29 2021 21:16

    sneiland on master

    Update to match FW1 implementat… (compare)

  • Oct 29 2021 20:58
    sneiland commented #518
  • Oct 29 2021 20:57
    sneiland closed #527
  • Oct 29 2021 20:56
    sneiland commented #538
  • Oct 29 2021 20:55
    sneiland closed #522
  • Oct 29 2021 19:44
    sneiland labeled #539
Sean Corfield
@seancorfield
[jcberquist, cfml] @seancorfield I thought that issue particularly related to the init() method returning something other than this? Was it a broader issue than that?
[Sean Corfield, cfml] I think there could be a better fix than just sledgehammer-locking that section but I haven’t figured it out yet :| No, this is a general issue that could explain what both of you are seeing.
[jtreher, cfml] I'm beginning to think that we might have been relying on it not being thread safe :face_vomiting:
[Sean Corfield, cfml] Oh?
[jtreher, cfml] I'm just trying to figure out how it was working in 3.0 without issue.
[jtreher, cfml] We've been running that for 3 years now? I was the one that originally jammed it in.
[John Whish, cfml] So there was an issue a while back of wiring a singleton into a transient. Is that the kind of thing you are doing?
[jtreher, cfml] Again, the only thing we had to modify was to switch the thinking around "unhandled" paths to bring in the concept of "handled" paths. Other than that, it works out of the box.
[jtreher, cfml] Nah, these are all singletons.
Sean Corfield
@seancorfield
[jtreher, cfml] The things we are having trouble with (and we can get it to error at different spots) are all .addBean one is a number, others are instances of cfcs. Stuff created outside of DI/1 but made availble by DI/1 for property injection.
[John Whish, cfml] Hmm, so if I follow, you do something like:
Sean Corfield
@seancorfield
[John Whish, cfml] Does FW/1 create DI/1 for you?
[jtreher, cfml] Yep
[jtreher, cfml] Our overrides amount to about 10 lines of code just around the handled request logic.
[jtreher, cfml] I don't wnat you guys to think that we rewrote the whole thing ;)
[John Whish, cfml] ha :) We have a legacy app and I've put FW/1 into it so had to jump through some hoops like you. In the end I create DI/1 explicitly and pass it in via setBeanFactory() for ... reasons!
Sean Corfield
@seancorfield
[John Whish, cfml] If I follow, FW/1 creates DI/1, scans and finds beans (all good). Some (say foo) of those beans need a bean which you add manually via addBean. So my current guess is that the 'foo' bean is being asked for (getbean('foo')) before the addBean code has run. Wild stab in the dark there...
[John Whish, cfml] So, I think you may be able to leverage onLoadEvent (which runs directly after discoverbeans) to do all the addBean stuff.
Sean Corfield
@seancorfield
[John Whish, cfml] So do you call addBean in your listener passed to onLoad?
[John Whish, cfml] Ah yeah, you say you are using loadListener. In that case - no idea. Sorry.
Sean Corfield
@seancorfield
[John Whish, cfml] mind you the lock in discoverBeans ends before it does the loadListener bit
Sean Corfield
@seancorfield
[jtreher, cfml] hmmmm, right, that could be the issue.
[jtreher, cfml] Maybe I'll try the aggressive locking to see how that goes.
Sean Corfield
@seancorfield
[jtreher, cfml] No dice, dang.
Sean Corfield
@seancorfield
[John Whish, cfml] Did you just extend the lock in discoverbeans?
[jtreher, cfml] I might have stumbled on to something here by using getDefaultBeanFactory() in setupRequest()
[jtreher, cfml] Instead of getBeanFactory()
[jtreher, cfml] And calling applicationStop()
Sean Corfield
@seancorfield
[jtreher, cfml] I cannot replicate the issue on local anymore using getDefaultBeanFactory() instead of getBeanFactory() everywhere in application.cfc that wants access to the "main beanfactory" unless I enable the reload on every request flag.
[jtreher, cfml] and, all of our addBean stuff now only happens on the main DI instance unlike when it used to happen for all of them in 3.0
[jtreher, cfml] Previously, each subsystem instance would have had the loadListener firing (something we maybe were taking advantage of?)
[Sean Corfield, cfml] That sounds related to subsystems still being initialized on demand when the first request for an action within it comes in.
[jtreher, cfml] I think so. And every request is in a subsystem now, right?
[Sean Corfield, cfml] No.
[jtreher, cfml] Dang
[Sean Corfield, cfml] You’re using “legacy subsystems” still?
[jtreher, cfml] Yes.
[jtreher, cfml] That only applies to the "new" then, eh?
Sean Corfield
@seancorfield
[Sean Corfield, cfml] The main app is not a subsystem in either case.
[Sean Corfield, cfml] The issue is just that subsystem initialization is on demand and thus could fall foul of thread safety issues if heavy load hits an uninitialized subsystem. The plan was to add an “eager initialization” option to the new subsystems stuff to get around that.
Sean Corfield
@seancorfield
[clockworkrebel, cfml] I'm using FW/1 with DI/1 and I'm trying to figure if the DI/1 methods mentioned in the "Overriding DI/1 Behavior" section of the documentation will be called for FW/1 controllers (particularly the construct method).
[clockworkrebel, cfml] The method doesn't seem to be called for me, but it's entirely possible I've just got something set up wrong.
[clockworkrebel, cfml] So I'm wondering if those methods are expected to be called (and therefore I should keep looking at what I screwed up) or if those methods wouldn't be called even if all my stuff was functioning at 100%
Sean Corfield
@seancorfield
[Sean Corfield, cfml] @clockworkrebel Do you have diLocations set in your FW/1 config?
[Sean Corfield, cfml] The default (if you omit it) is for FW/1 to let DI/1 manage both controllers and the model, but if you override that it and don't tell it to manage the controllers...
[Sean Corfield, cfml] Also, which version of FW/1 are you using?
Sean Corfield
@seancorfield
[clockworkrebel, cfml] I'm using the latest and greatest. I'll take a look at my Application.cfc tomorrow morning to see if I had it set. I think that's probably what I did
[clockworkrebel, cfml] Thank you for pointing me in the right direction on that
Sean Corfield
@seancorfield
[clockworkrebel, cfml] Well, turns out I did not have diLocations set, but for the time being I got it to work by explicitly setting diLocations. Perhaps it's because the controller classes in question are in a subsystem? I had to add the controller directory for the subsystem before it worked (which makes sense).
Sean Corfield
@seancorfield
[Sean Corfield, cfml] @clockworkrebel just to check: you have folders named controllers (plural) and model (singular) in both the top level and in each subsystem?