Thanks, Yeah that may do the job - I was just trying to get my head around where I needed to plug into Windsor. I think I will write a facility that allows me to notify Windsor when a user has logged out. The facility will then be responsible for locating the correct lifestyle and clearing the component cache. So I guess those are the two points where I need to enhance Castle, a facility and a lifestyle.
Then I can host the container within a Windows Service which capture the windows logon/logoff events, and passes them on to the custom facility - that decouples castle from any specific 'windows integration' code. Thanks Adam Langley From: castle-project-users@googlegroups.com [mailto:castle-project-users@googlegroups.com] On Behalf Of Krzysztof Kozmic Sent: Tuesday, 19 April 2011 9:39 a.m. To: castle-project-users@googlegroups.com Subject: Re: New WCF Facility Lifestyle I may still be missing the whole picture but OperationContext oc = OperationContext.Current; ServiceSecurityContext ssc = oc.ServiceSecurityContext; string client = ssc.PrimaryIdentity.Name; This will get you the name of the currently logged in user, which from what I'm reading is what you need. About detecting closing of the app, I'm not exactly sure how you'd want to detect it, but custom lifestyle with access to the user name and with trigger to release upon user exit sounds like a reasonable way to go. Krzysztof On 18/04/2011 8:34 AM, Adam Langley wrote: Thats not all I need though - I suppose its quite complicated to explain. My goal is to have a windows-service which exposes endpoints over net-pipe, which can be accessed by any process on the local machine to utilise centralized services. The service instance returned by the windows-service will depend on the user-account of the caller. A user who terminates their application process (which is a client of the windows-service) will NOT have his worker objects destroyed because they are keyed (lifestyle) against their user account, not the process-id. BUT if they log out of the computer, then castle will destroy all their component instances. I can see that this functionality has many tendrils that need to hook into various different areas of responsibility with the castle infrastructure. I would LIKE to be able to implement this using Castle paradigms so that it is not implementation specific, but could be re-used easily in other, unrelated projects. Does that better explain where I am, and the depth of my proposition? Thanks Krzysztof Adam Langley Please consider the environment before printing this email! -----Original Message----- From: castle-project-users@googlegroups.com [mailto:castle-project-users@googlegroups.com] On Behalf Of Krzysztof Kozmic Sent: Sunday, 17 April 2011 9:24 p.m. To: castle-project-users@googlegroups.com Subject: Re: New WCF Facility Lifestyle Sorry about the delay. If all you need is authentication information isn't this available from Thread.CurrentPrincipal or from OperationContext.Current ? Krzysztof On 14/04/2011 10:24 AM, Adam Langley wrote: Absolutely, that would be analogous to my goals - except that nothing in the WCF infrastructure will identify the windows session of the caller. I was thinking that to achieve 'session identification' I would need to extend windsor further - but perhaps I dont. I expect the minimum I require, is that if my 'handler selector' is applied, then the WCF endpoint must use Windows authentication. Then when a call comes in, I can identify the windows account of the caller and use that to locate the correct instance. Does this sound like the right approach? I still need some 'facility' running within castle to listen to log-off events so that I can dispose of all instances associated with that user-session. I just thought that because my 'extension' required so many different functional facets, I would need to implement them in several different ways (IHandlerSelector + Facility + Lifestyle, for example) Adam Langley Please consider the environment before printing this email! -----Original Message----- From: castle-project-users@googlegroups.com [mailto:castle-project-users@googlegroups.com] On Behalf Of Krzysztof Kozmic Sent: Thursday, 14 April 2011 9:38 a.m. To: castle-project-users@googlegroups.com Subject: Re: New WCF Facility Lifestyle Adam, the way I saw it done usually, in multitenant applications is to have the component registered for each tenant and use IHandlerSelector to manage returning the right one. Say you're using NHibernate and you have different databases for each tenant and each database has it's own Session component which you pick based on some information about what tenant is currently making the request. Would that be fair to say you're in a similar situation? On 13/04/2011 2:01 PM, Adam Langley wrote: Dear group, I have a requirement where-by I will have a Windows Service (running as System) that publishes a component on net.pipe (for use by the local machine only), but it must service multiple users logged on to the same machine simultaneously. It must create a 'singleton' instance per Windows User connected... so the WCF layer will use integrated windows authentication. When a user logs on to the machine, they will receive the same component instance no matter how many times they connect/disconnect from the WCF service - and no two users will ever share the same instance. I was thinking that the best way to approach this would be a custom lifestyle which creates a release policy per distinct windows user - the component could even capture the global 'user logoff' event and dispose that user's component at that time (I would really love this!). What do you think of the concept, and what Castle extensibility points would I rely on to implement this? Adam Langley -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to castle-project-users@googlegroups.com. To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to castle-project-users@googlegroups.com. To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
