WireBox: Map the result of a method of a Java class

Is there a simple way to just map the result of createObject(“java”, “com.intergral.fusionreactor.api.FRAPI”).getInstance() to a WireBox alias?

Mapping a regular class is easy, but in this case I’d like to keep things clean and just map a singleton of the returned instance in one step instead of having to use a boilerplate provider as a go-between.

I obviously know about the regular toJava() and toDSL(“javaloader:…”) basics, but it’s the point about getting straight to the result of the getInstance() method of the class that has me wondering.

I’m sure there’s an easier way to do this, but right now I just can’t see the woods for all the trees.

Environment details: ColdBox Platform Bundle 3.8.1, Railo 4.2

Thanks in advance for your replies!

what is the result of getInstance()?

Here’s a 3 options.

1)
If the object is a singleton, meaning that you can use that single object over and over and it is thread safe, you can just create it in the config and map it as a value.

map( “FRAPI” ).toValue( createObject(“java”, “com.intergral.fusionreactor.api.FRAPI”).getInstance() );

2)
This is also for if your Java class is a singleton. Autowire the reference using the model:{name}:{method} namespace to automatically call a method on the object. The results of the method call will be what is injected.

First create the mapping like you normally would.

component {
property name=‘FRAPI’ inject=‘model:FRAPI:getInstance’;
}

Warning, I’ve never tried this on a Java object, but I assume it will work :slight_smile:

3)
If the Java class is a transient and a new one needs to be created every time, create a simple provider CFC that implements coldbox.system.ioc.IProvider and has a “get()” method that generates the class and returns it. Then map your provider like so:

map( “FRAPIProvider” ).toProvider( “path.to.my.provider” );

Then when you autowire the provider or get it from wirebox, call its get() method to generate a new instance of your Java class.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thanks, Brad!

The provider approach in the third example is the one I wanted to avoid unless all else fails (just feels too inefficient to create a new component simply to call a single method), but I had completely forgotten about the toValue() approach to just do this manually.
I’ll give it a try.

Thanks again!

Michael

The provider approach really comes in handy if you have specific, special steps that need to occur in order for an object to be created and/or persisted, or want to avoid direct memory references.

I’m glad the toValue() option looks like it will work for you.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I wrote a plugin (attached) to abstract the FRAPI stuff. The plugin is a singleton and loads the FRAPI java class in the init() method. It’s pretty simple and only currently implements a setMarker() method for adding markers to FusionReactor.

But you can feel free to use it / add to it.

map(“YourAlias”).toDSL(“coldbox:myplugins:fusionreactor”)

fusionreactor.cfc (1.32 KB)

This is cool. Throw it on ForgeBox so others can use it:
http://www.coldbox.org/forgeBox

Also, if you put the code on GitHub, others can contribute easily.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thanks!
A plugin sounds like an even better approach, In my case it’s about providing custom metrics to an FR instance (API example).

Brad is right. Would you mind adding it to GitHub so others can contribute?

Rock on \m/

Thanks!
I’ll submit additional useful methods once I’m back in my office.

Just curious, what version of FusionReactor are you using? I’m currently stuck on 3.x, so I think the API is pretty limited. Perhaps we should add some version checking to test for support of certain features.

In my case it’s 5.0, but since most methods in the API are backward compatible it’s basically just a matter of extracting the method names from the class into a string array during init() and the actual feature methods will then first do an isMethodSupported() check using that similar to how you already check whether or not the class could be instantiated.