Using native Java threading in Lucee

[bennadel]

Very cool, I will check it out

[bennadel]

@bdw429s this is pretty interesting right here: RabbitSDK/Consumer.cfc at master · Ortus-Solutions/RabbitSDK · GitHub – I like that you found a way do associate the application context in both Lucee CFML and Adobe ColdFusion, hats off to you It seems significantly easier in Lucee, which is cool.

I’m not super familiar with RabbitMQ (I somewhat get the basic concepts). But, picking through the code, it looks like the RabbitMQ Channel is responsible for keeping the Consumer thread going indefinitely, right? Meaning, if the Consumer throws an error or whatever, it looks like the Channel is managing that and keeping things going.

As an aside, I know nothing about WireBox, but it looks like it allows for name-spacing of properties. I really really wish we had that in our app (which is use FW/1 + DI/1). I’m starting to have to create really massive Component names in order to make them globally unique. This is cool!

[bdw429s]

I like that you found a way do associate the application context in both Lucee CFML and Adobe ColdFusion, hats off to you It seems significantly easier in Lucee, which is cool.

Thanks. Lucee was easier since I had the benifit of being able to see the engine’s open source code. Lucee also tends to encapsulate better from what I’ve seen.

I’m not super familiar with RabbitMQ (I somewhat get the basic concepts ). But, picking through the code, it looks like the RabbitMQ Channel is responsible for keeping the Consumer thread going indefinitely, right? Meaning, if the Consumer throws an error or whatever, it looks like the Channel is managing that and keeping things going.

Um, more less. RabbitMQ is just a message queue for sending messages between applications. I only mentioned it because the java SDK for Rabbit uses a java thread pool to spin up the consumer threads. These threads suffer from the same issue as any native thread solution, which is they are not “attached” to their application nor page context so they forget who they are.

I know nothing about WireBox

It’s not that different than DI/1, just more robust and extensible.

but it looks like it allows for name-spacing of properties.

WireBox adds a layer of abstraction called “mappings” that work like recipes in your kitchen. When you go to a restaurant, you don’t order a slice of “flour, sugar, milk, oil, and eggs”. You order a slice of “cake”. Cake is the agreed name for the thing you want the chief to cook for you, and he has a a recipe card labeled “cake” on top that lists all the things going into it. The same with WireBox-- while the default name for a mapping is usually the name of the CFC you want, you can create a mapping in WireBox called “cake” and then tell WireBox exactly what that means. This is why/how WireBox can supply you with more than just CFC instances, but also static values, settings, java classes, and framework services. All it needs is the recipe to build it and the name you want to call it.

So as far as “namespaces”. Imagine, the chief now has the following recipe cards:

• Chocolate cake
• Angel food cake
• Devils Food cake
• Carrot cake

He ends all the cake recipes off with the same name to help sort and categorize them. This also helps prevent accidental duplicate names when he also has

• Chocolate cake
• Chocolate milk
• Chocolate candy bar
• Chocolate covered ants

WireBox does the same thing when it auto-registers CFCs from a module. The default name for a CFC is “nameOfCFC@nameOfModule”. Which is how you get a name like RabbitClient@rabbitsdk which is both self-describing plus avoids accidental overlap with another moudle having a CFC with the same name.

[bennadel]

It’s really interesting stuff. I spent like an hour trying to dig through the ioc.cfc from FW/1 yesterday. Really, what I would love to do is be able to set a property attribute that defines:

• The name of the injectable property (ie, what the object is called locally inside the target).
• The class-path for the injectable definition.

So, image that I have a bunch of CFCs all in a folder like libs/app/feature, I’d love to have a CFC that has properties like:

property name="service" type="/libs.app.feature.FeatureService";
property name="gateway" type="/libs.app.feature.FeatureGateway";
property name="helper" type="/libs.app.feature.Helper";

This way, the CFCs that are “local” to a feature don’t have to have globally unique names. For example, I might have several CFCs that have the name Helper.cfc, and they would live within their own corners of the app.

Anyway, we’ve gone totally off topic at this point But, this is something that is weighing on me lately because I’m starting to have CFC names that are absurdly long because they have to be unique.

[bdw429s]

@bennadel You chose the wrong Di engine then, because that is exactly how WireBox works. The name of the mapping you wish to inject doesn’t have to be the same as what variable you inject it into.

property name='yoYoMySweetInjectedInstance' inject='OfficialWireBoxMappingName';
property name='fileUtil' inject='InternalFileSystemUtilityService';
// Direct CFC path to file
property name='Helper' inject='libs.app.feature.Helper';

[bennadel]

Oh man!!! I want, I want! I need, I need!

Unfortunately, that ship has almost certainly sailed. We have a boat-load (pun intended) of code that would have to be changed at this point. But, good to know I’m not crazy for wanting such things.