Component Resolution Occurs before Session is Acquired
------------------------------------------------------

                 Key: MR-445
                 URL: http://support.castleproject.org//browse/MR-445
             Project: MonoRail
          Issue Type: Improvement
          Components: Core
    Affects Versions:  Release Candidate 3
            Reporter: João Bragança

In http://forum.castleproject.org/viewtopic.php?p=9850, herny says 'Probably due the cache implementation, the controller is now instanced before the session acquire step.'

I understand this is performance reasons. However I would like to implement a PerSessionLifestyleManager similar to the PerWebRequest.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://support.castleproject.org//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

    [ http://support.castleproject.org//browse/MR-445?page=comments#action_... ]

Andre Loker commented on MR-445:
--------------------------------

I, too, had implemented a PerSessionLifestyleManager that worked in WebForms apps, but not in monorail, so +1 for this issue. As of now, I cannot inject components into my controllers that have session scope.

At the moment, my work-around is, instead of injecting the session scoped objects, to inject a transient or request scoped components that acts like a simple service provider and factory that caches the objects in session scope. However, it is by far not as nice as it could be compared to directly injected dependencies.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://support.castleproject.org//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

    [ http://support.castleproject.org//browse/MR-445?page=comments#action_... ]

hamilton verissimo commented on MR-445:
---------------------------------------

I guess you're referring to the fact that the controller is created by the MRHttpHandlerFactory and as a consequence all its dependencies are resolved before a session is made available. Unfortunately that's unlikely to change. That factory needs to return different handlers based on request information.

What you could do is to proxy the per session components, and resolve them (from the session) lazily.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://support.castleproject.org//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

     [ http://support.castleproject.org//browse/MR-445?page=all ]

hamilton verissimo resolved MR-445.
-----------------------------------

      Assignee: hamilton verissimo
    Resolution: Won't Fix

This is a consequence of the MR design, and it's unlikely to change

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://support.castleproject.org//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira