Tapestry
  1. Tapestry
  2. TAPESTRY-717

Easier accessing the hivemind registry

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.2
    • Component/s: Framework
    • Labels:
      None

      Description

      Currently, the servlet stores the hivemind registry in the content, but provides no easy way of obtaining access to it. Both the prefix and the _registry members are private, so one must hack in order to access it ( by hack I also mean just copying the registry prefix to another visible static member).

      This is also a J2EE compatibility issue.
      If one wishes to integrate Tapestry with other features, the hivemind registry is essential.
      Currently I stumble on a SessionListener, which needs to do some cleanu, and depends on ASOs and Hivemind (custom) services to do so.

      wouldn't it be possible to "publish" the registry using JNDI ?

        Activity

        Hide
        Ron Piterman added a comment -

        On second thought, JNDI would expose the whole application outside of the context, which is naturally out of question. So another solution would be great...

        Show
        Ron Piterman added a comment - On second thought, JNDI would expose the whole application outside of the context, which is naturally out of question. So another solution would be great...
        Hide
        Jesse Kuhnert added a comment -

        I think I'd first like to know what problems are being solved by making the registry easier to get access to.

        I believe this is currently actually done on purpose, ie "by design". I really doubt there is anything you need to do that couldn't/shouldn't be done using built-in hivemind service capabilities but I'm open to suggestion.

        Closing this out for now but will happily re-open if anyone cares enough to throw in some more thoughts.

        Show
        Jesse Kuhnert added a comment - I think I'd first like to know what problems are being solved by making the registry easier to get access to. I believe this is currently actually done on purpose, ie "by design". I really doubt there is anything you need to do that couldn't/shouldn't be done using built-in hivemind service capabilities but I'm open to suggestion. Closing this out for now but will happily re-open if anyone cares enough to throw in some more thoughts.
        Hide
        B.S.Navin added a comment -

        I think that this is more of a question of "ease of doing" rather than "not able to do".

        One case where I preferred having direct access to the hivemind registry, is in Enhancement Workers - I had one enhancement worker, where the code generates needed to use a hivemind service (Ognl service). I had 2 alternatives -

        1. Add an inject specification into the component that injects the required hivemind service. Make sure that my EW gets called before other related EWs and then generate code to call to the get method to get the service

        2. Get hold of hivemind registry from some static method and call a getService() on it.

        I would say, that the second approach is much simpler to implement, provided that the hivemind registry was directly accessible.

        Show
        B.S.Navin added a comment - I think that this is more of a question of "ease of doing" rather than "not able to do". One case where I preferred having direct access to the hivemind registry, is in Enhancement Workers - I had one enhancement worker, where the code generates needed to use a hivemind service (Ognl service). I had 2 alternatives - 1. Add an inject specification into the component that injects the required hivemind service. Make sure that my EW gets called before other related EWs and then generate code to call to the get method to get the service 2. Get hold of hivemind registry from some static method and call a getService() on it. I would say, that the second approach is much simpler to implement, provided that the hivemind registry was directly accessible.
        Hide
        Norbert Sándor added a comment -

        I agree with Navin.
        Besides in more complex applications I often find it necessary to access hivemind services from POJOs.

        There is a related hivemind issue as well: http://issues.apache.org/jira/browse/HIVEMIND-179

        Show
        Norbert Sándor added a comment - I agree with Navin. Besides in more complex applications I often find it necessary to access hivemind services from POJOs. There is a related hivemind issue as well: http://issues.apache.org/jira/browse/HIVEMIND-179
        Hide
        Jesse Kuhnert added a comment -

        In response to Navin,

        The way that most of the enhancement workers do this is by simply injecting the reference to the service in question into the enhancement worker where it is further injected into the component/page/etc in question.

        Because of the way that hivemind dynamically creates proxies that hide the relationship between the object you are injected and which actual hivemind service is used at the time of invocation it should really just be "magic" to people using the service.

        So, I still don't see why in this particular instance direct access to the registry is needed. I'm still being open minded about it, but so far in my experience about 99% of the time people want this it means that they just aren't understanding/using hivemind to its fullest potential.

        Show
        Jesse Kuhnert added a comment - In response to Navin, The way that most of the enhancement workers do this is by simply injecting the reference to the service in question into the enhancement worker where it is further injected into the component/page/etc in question. Because of the way that hivemind dynamically creates proxies that hide the relationship between the object you are injected and which actual hivemind service is used at the time of invocation it should really just be "magic" to people using the service. So, I still don't see why in this particular instance direct access to the registry is needed. I'm still being open minded about it, but so far in my experience about 99% of the time people want this it means that they just aren't understanding/using hivemind to its fullest potential.
        Hide
        Ron Piterman added a comment -

        There are some usecases in which one needs such an access, for me the most important one is sharing information across the context.

        For example, if one decides to use the same hivemind registry tapestry uses (and not spring or another IoC container) for some front-end services, and want's to share those services in the context.

        I would like to enhance this feature request and ask to externalize all state obejct access to static methods:

        e.g, in the session state manager, add:

        public static Object getStateObject( HttpSession session , String tapestryServletName, String stateName );

        or in the context state manager, add:

        public static Object getStateObject( ServletContext ctx, String tapestryServletName , String stateName );

        or in case of registry:

        public static Registry getHivemindRegistry( ServletContext ctx, String tapestryServletName );

        BTW, I don't think static-storing of the registry is possible due to clustering issues, we must always use the ServletContext.
        Currently, it is alsa possible to access the registry: copy the key tapestry uses to store the registry in the context, add the servlet name, and peek it - but this is not very "nice"...

        Show
        Ron Piterman added a comment - There are some usecases in which one needs such an access, for me the most important one is sharing information across the context. For example, if one decides to use the same hivemind registry tapestry uses (and not spring or another IoC container) for some front-end services, and want's to share those services in the context. I would like to enhance this feature request and ask to externalize all state obejct access to static methods: e.g, in the session state manager, add: public static Object getStateObject( HttpSession session , String tapestryServletName, String stateName ); or in the context state manager, add: public static Object getStateObject( ServletContext ctx, String tapestryServletName , String stateName ); or in case of registry: public static Registry getHivemindRegistry( ServletContext ctx, String tapestryServletName ); BTW, I don't think static-storing of the registry is possible due to clustering issues, we must always use the ServletContext. Currently, it is alsa possible to access the registry: copy the key tapestry uses to store the registry in the context, add the servlet name, and peek it - but this is not very "nice"...

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Ron Piterman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development