injecting non-singletons

[Doug Boude]

Hi all.

In my app, when a user logs in I populate a user bean (defined in
coldspring.xml as a non-singleton) which contains various bits of info
about this person. I have a service layer object that is injected with
a worker object via bean definitions. The worker object needs to be
able to access the populated user bean.

Is there a way to define my worker object in coldspring.xml so that
the user bean injected will not be an empty, new instance of user, but
the populated one that already exists in this session? Just want to
see if this is possible before I pursue other avenues since it would
definitely be the most efficient way to do it.

Thanks.

Doug

[Tony Nelson]

Typically speaking ColdSpring isn't intended to create transient objects. Brian describes why pretty well in this post: http://groups.google.com/group/coldspring-users/browse_thread/thread/3fdee4a09c8599d7.

An example of how to create and use a factory can be found on the ColdSpring Quickstart Guide on the "Factory Beans" page, located at http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=factory.

-Tony

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To post to this group, send email to coldspri...@googlegroups.com.
To unsubscribe from this group, send email to coldspring-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.

[Brian Kotek]

What Tony said. ;-)

[Matt Quackenbush]

Doug,

Someone else may chime in and tell me that I am mistaken, but as far as I know, the answer to your question is "no, ColdSpring cannot and will not do that".

I would honestly recommend two things here:

1) Don't use ColdSpring to manage transients (non-singletons).  Use a transient factory instead (which itself can [and should?] be managed by ColdSpring).

2) I would have a service method along the lines of getCurrentUser(), which would ultimately return the User that is stored in your session.  Whether you choose to access the session directly or a session facade to grab it is up to you.

HTH

[Brian Kotek]

I also wrote up a section on this in the Quick Start: http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=singletons

On Fri, Mar 5, 2010 at 1:02 PM, Tony Nelson <tonyne...@gmail.com> wrote:

[Barney Boisvert]

The short answer is no. The long answer is that if your service
object is also non-singleton, you can make it work with a factory
bean, but that's not what you want to do. ;) I'd create a CFC whose
sole purpose is to get the current user from the session and inject
that into the worker. Then you can ask that bean for the user
whenever you need it. You're breaking encapsulation, but doing it in
an encapsulated way.

cheers,
barneyb

> --
> You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
> To post to this group, send email to coldspri...@googlegroups.com.
> To unsubscribe from this group, send email to coldspring-use...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/coldspring-users?hl=en.
>
>

--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/

[Doug Boude]

Thanks all for the input, its definitely helping to clear the fog for me.  I'm currently exploring the idea of adding the populated user object to my globalConfig bean after login, and defining my worker to have an instance of the globalconfig bean as a property. Since the worker will never be called upon outside of a successful login, i'm thinking this approach should satisfy my need without me having to create a factory or class specifically for retrieving my user from session.

[Hem Talreja]

Careful, you want to manage timeout and logouts. There is a way to access the session objects stored in cf if you need to

On Mar 5, 2010 12:15 PM, "Doug Boude" <doug...@gmail.com> wrote:

Thanks all for the input, its definitely helping to clear the fog for me.  I'm currently exploring the idea of adding the populated user object to my globalConfig bean after login, and defining my worker to have an instance of the globalconfig bean as a property. Since the worker will never be called upon outside of a successful login, i'm thinking this approach should satisfy my need without me having to create a factory or class specifically for retrieving my user from session.

On Fri, Mar 5, 2010 at 12:05 PM, Barney Boisvert <bboi...@gmail.com> wrote: > > The short answer...

--

You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group. ...

[Doug Boude]

Hem, can you elaborate on what you mean by "a way to access session objects"? I know you must be talking about something besides the obvious here. :)

[Hem Talreja]

http://jehiah.cz/archive/extended-operations-on-coldfusion-sessions

I believe you would like to access all live sessions in cf you can use cf internal components to do this, this might help

On Mar 5, 2010 12:22 PM, "Doug Boude" <doug...@gmail.com> wrote:

Hem, can you elaborate on what you mean by "a way to access session objects"? I know you must be talking about something besides the obvious here. :)

On Fri, Mar 5, 2010 at 12:20 PM, Hem Talreja <hemta...@gmail.com> wrote:

> > Careful, you want to manage timeout and logouts. There is a way to access the session objects st...

> You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group...

> To post to this group, send email to coldspri...@googlegroups.com. > To unsubscribe from this...

--

You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.

To post to this group, send email to coldspri...@googlegroups.com. To unsubscribe from this gro...

[Doug Boude]

Just to share the solution I went with...

Since I already had a globalconfig bean (ModelGlue.Bean.CommonBeans.SimpleConfig) that I was injecting into other defined beans, I simply added a "user" value to that bean within my authentication controller after login: a duplicate of my populated session.user bean. Globalconfig was already being injected into my worker, so I got the needed values out globalconfig's copy of user.

Now that i said that, i'm thinking maybe i shouldn't have added a duplicate of the session.user object but rather just a reference to session.user so that any alterations to session.user''s value will always be visible within the worker as well. Does that sound right?

[Barney Boisvert]

Without knowing how your app is built it's hard to say for sure, but
it seems like you're going to run into threading issues, since
GlobalConfig sounds like the name of a shared bean, no?

On Fri, Mar 5, 2010 at 11:49 AM, Doug Boude <doug...@gmail.com> wrote:
> Just to share the solution I went with...
> Since I already had a globalconfig bean
> (ModelGlue.Bean.CommonBeans.SimpleConfig) that I was injecting into other
> defined beans, I simply added a "user" value to that bean within my
> authentication controller after login: a duplicate of my populated
> session.user bean. Globalconfig was already being injected into my worker,
> so I got the needed values out globalconfig's copy of user.
> Now that i said that, i'm thinking maybe i shouldn't have added a duplicate
> of the session.user object but rather just a reference to session.user so
> that any alterations to session.user''s value will always be visible within
> the worker as well. Does that sound right?
>

--

[Doug Boude]

hmm. it IS the name of a singleton. But, if I add a reference to session.user to that singleton instead of a duplicate of session.user, would each individual session see its OWN copy of the user object when accessing it via the singleton's reference? OR, would each session, as it sets that singleton's reference, override the previous reference, so all sessions would be accessing the user bean set by the last initiated session?  Yeah, seems like the latter would occur. Darn me, painted myself into a corner. Time to repaint.

[Barney Boisvert]

Ultimately there is no way to solve this except via a runtime
reference to session.user. Trying to prevent that is impossible. But
you don't want to litter you code with session.user, you want to
encapsulate it into an object or method that ONLY does that. Then all
your other code will be isolated from the 'session.user' name.

cheers,
barneyb

[Matt Quackenbush]

In principle, I agree completely with Barney.  In practical use of CFML, I don't have an object that ONLY grabs the "current/session" user.  My SecurityService, however, is the ONLY object in my application that knows where/how to get that User.  **ALL** requests for it go through the SecurityService. So, something like so...

-- SecurityService.getCurrentUser()
<cffunction name="getCurrentUser">
    <cfif structKeyExists(session,getUserStorageKey())>
          <cfreturn session[getUserStorageKey()] />
    <cfelse>
          <cfreturn getUserService().getNewUser() />
    </cfif>
</cffunction>

-- anywhere else in application
<cfset currentUser = getSecurityService().getCurrentUser() />

HTH

[Doug Boude]

Guys, once again thank you for taking the time to gently shed light on this scenario for me. :) I feel like I have a MUCH better grasp on this aspect of the app's architecture now.

Doug

--

[Doug Boude]

I created a simple persistence facade I lovingly named "WormHole" that I injected into my model worker. Works like a charm now, thread safe. Thanks again all.