Announcement Announcement Module
Collapse
No announcement yet.
No SFSB support in Spring? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • No SFSB support in Spring?

    Hello again...

    I've noticed that, while SLSB support is available for EJB access via spring (via SimpleRemoteStatelessSessionProxyFactoryBean) that there appears to be no similar mechanism for SFSB, even tho the original "interface21" code from Rod's first book seemed to be including support for this. Is this accurate? As it stands it seems to be that I'll have to write my own service locator for SFSBs.

    Thanks.

  • #2
    There is a bit of support on the side of actually creating the bean (with the existence of AbstractStatelessSessionBean), but you are correct that there is no proxy convenience class.

    The stateless beans lend themselves to a singleton proxy (as per the existing client side support code), while stateful beans would require some sort of pooled or prototype proxy to be created.

    Regards,

    Comment


    • #3
      I see your point. But is there any chance of Spring being enhanced to provide this? While I see the point of view you're coming from, I'd rather have one API I'm working with for provisioning the objects rather than take a hybrid approach.

      Thanks for your help, Colin...

      Comment


      • #4
        There's been effectively no demand for this up to now. We would gladly take a contriibution of some code in this area, but in terms of one of the Spring guys adding in support, there is lower hanging fruit in terms of features that more people are asking for.

        Regards,

        Comment


        • #5
          Colin,

          As I get a better understanding of Spring, I'll see what I can come up with for your review... Thanks.

          Comment


          • #6
            A simple way to work with an SFSB is to use a JndiObjectFactoryBean to locate the SFSB home, and pass that home object to your client objects as bean reference. Your clients then have to use appropriate create methods to create a SFSB session, and remove it when they're done.

            Essentially, Spring just locates the SFSB home for you here, letting your client objects do whatever they want with it. To some degree, this is inavoidable when working with SFSBs and their inherent client session that needs to be created (in special ways) and removed again.

            For SLSBs, you could use a JndiObjectFactoryBean to locate the home object too. *StatelessSessionProxyFactoryBean just makes stuff easier through "creating" the actual SLSB reference for you, so that you do not have to worry about create calls - which is possible in the case of an SLSB (with its trivial no-arg create method), in contrast to an SFSB.

            Juergen

            Comment


            • #7
              The main reasons we haven't done this are that

              - SFSBs aren't guaranteed to have a no-arg create() method like SLSBs. This makes it harder to achieve the transparency we want of hiding the EJB API altogether on the client side. The Method Injection feature in Spring 1.1 could be an elegant solution to this.

              - SFSBs are of questionable value in most applications, and nowhere near as popular as SLSBs

              I you would like to contribute a proxy implementation I'd be happy to include it in Spring 1.2. I would suggest you base it on the SLSB proxy and use MethodInjection with a MethodReplacer that replaced one or more createBean(args...) methods.

              Comment


              • #8
                Is there anything in Spring that emulates the external offloading of a SFSB using CMP, but without having to write an actual EJB?

                On the web project I'm working on, we save JavaBean graphs generated from large db resultsets over multiple HTTP requests. These graphs can have typical user use lifetimes of say 20+ mins, but with perhaps only six short read-only accesses.

                1. These data in these graphs are session-sensitive by nature
                2. A session can have more than one of these graphs
                3. As the number of concurrent users grows, the memory overhead can be overwhelming

                So a coworker stores the graphs in SFSBs. He argues that the LRU graphs can be written to disk and restored again, as needed. No custom coding is required to temporarily store the data in a temp db table and get it back again.

                This makes sense, but I can't stand EJBs and their overhead. 99% of our app works just fine in a web container -- no need for an app container -- except for this blasted SFSB. I am desperate to find an alternative.

                Also, is ebjPassivate only called when the pool is exhausted? Or does the app container have hooks in the JVM to detect when memory is getting low and passivate then as well?

                Comment


                • #9
                  handles to stateful EJBs

                  Hiya,
                  I'm integrating with a somewhat legacy application that provides stateful EJBs.

                  My application is a struts/spring/hibernate application with a struts tier, service tier (facades) and integration / dao tier.

                  I would like the integration dao tier to be able to retrieve non singleton (business delegate like) wrappers which contain a handle to a stateful EJB across web requests.

                  Ideally I'd like to make a factory bean to create these wrappers if necessary, or return a pre-existing handle cached (in the case of a web font end) in the HttpSession.

                  Is there such a thing as a request context? What do you do when you must access other request related items? (such as remote ip address etc for auditting?).

                  Thanks in advance, I have been working through the spring source but haven't seen anything relevant yet.

                  -Hugh Madden

                  Comment

                  Working...
                  X