DI/1 - same bean different configs best practice?

[Marcin Szczepanski]

Hey smart cookies!

I am trying to work out the best way of doing something - I've thought of a few options, but they don't feel right.

What I'm trying to achieve is this:

I have a service - "authService" which has properties like "authEndpoint" "authCallback" "authClientId".  These properties are injected via constants that are configured (currently) in app.cfc.

I want to re-use "authService" as aliased beans "authTestService" and "authProdService", but for those separate aliases there would be different endpoint/callback/clientId props.

How would I best do this with DI/1 so that I could, in my calling CFC just have a property for "authProdService" / "authTestService" and be able to do something like:

var authService = variables.authProdService;

if (mode == "test") authService = variables.authTestService;

authService.authenticate(username, password);

The current front-runner approach I've thought of would be to actually create the instances when setting up the bean factory, configure them, and use addBean. ie, something like this in setupApplication (FW/1):

var beanFactory = new ioc(..);

var authServiceProd = beanFactory.getBean("authService");

authServiceProd.setAuthEndPoint(...); 

.. other props ..

beanFactory.addBean("authServiceProd", authServiceProd);

.. repeat for authServiceTest.

.. or have the defaults point to prod, and just do the above for authServiceTest.

I think I've kind of answered my own question while writing this out.. thanks for listening and being my Rubber Ducks! (http://en.wikipedia.org/wiki/Rubber_duck_debugging) ;)

--
M.

[Sean Corfield]

My first thought is:

* If those constants are really what is different between tiers /
environments, then that's what should change (automatically) on each
tier.

In other words, in "test" mode, config would be the various test end
point, auth callback, and auth client ID, otherwise they would be the
production ones.

Having _configuration_ tied to environment control is generally the
better way to go, IMO.

Sean

> --
> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
>
> ---
> You received this message because you are subscribed to the Google Groups
> "framework-one" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to framework-on...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Marcin Szczepanski]

Unfortunately in this case the environment will be production, but some requests might need to use the test auth gateway and some could hit production.

More detail, just to explain WHY we're doing this in case it makes a difference - we're building an "Entitlements" service for Adobe Digital Publishing (mobile device based "magazine" apps).  Adobe will only setup one "Integrator ID" for us (which maps to the URL that Adobe's servers will call our service using), but we need to be able to use this Integrator ID for testing as well as for "live" publications.  We are calling the client's auth service to determine whether the user is entitled to the publication.  We will differentiate which auth service to use based on the appId we receive in the request (eg. requests from "com.mycompany.TestPublication" would use the test gateway, "com.clientcompany.RealPublication" would use the live gateway).

M.

[Marcin Szczepanski]

In any case - what I've currently done is pretty much what I said in my original email - except I defaulted my constants to the production settings so I just add an alias for that and override for Test - similar to:

beanFactory.addAlias("clientAuthProdService", "clientAuthService");

var clientAuthTestService = beanFactory.getBean("clientAuthService");

clientAuthTestService.setAuthEndPoint(constants.testAuthEndPoint);

// etc

beanFactory.addBean("clientAuthTestService", clientAuthTestService);

I'm happy enough with this approach for now!

--
M.

[Sean Corfield]

Well, obviously that sucks and big ol' "Boo!" to Adobe for making you
use a less than optimal workflow...

Is there anything that DI/1 could do to make your life easier? I
really like the idea of being able to create multiple versions of a
single object from different configurations... but I'm not quite sure
how to do it within the idiom of DI/1. In ColdSpring's XML you can
just declare two different names with different arguments - but that's
the "benefit" of configuration over convention.

Sean