Announcement Announcement Module
Collapse
No announcement yet.
where to put 'applicationContext.xml' for access from SLSB+DAO (using JBoss3) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • where to put 'applicationContext.xml' for access from SLSB+DAO (using JBoss3)

    In the manual, there is a section which talks about 'Using Spring convenience EJB implementation classes' i.e. section 17.2.

    I understand that the abstract class provides convenience methods but my question is where does my spring 'applicationContext.xml' file go? Is there a typical location on the filesystem where it will be loaded or should it be bundled in a particular jar or should it reside on the classpath?

    Jim

  • #2
    Usually you locate the applicationContext.xml within the EJB-jar containing the bean.
    The path you specify in the environment is relative to the ejb-jar's root.

    Normally I directly place my applicationContext.xml directly in the ejb-jar's root folder, but that is a matter of taste.

    Regards,
    Andreas

    Comment


    • #3
      Thanks Andreas.

      Do you perhaps have a reference to an example/description of how to load the applicationContext.xml?

      In the web tier the life-cycle of the spring context depends on the servletContext. What determines the life cycle in the business tier?

      Thanks.

      Jim

      Comment


      • #4
        Originally posted by jim
        Do you perhaps have a reference to an example/description of how to load the applicationContext.xml?
        There is an example in the reference manual.

        In your deplyoment-descriptor you will need an environment entry declaring your context file(s):

        Code:
                    <env-entry>
                        <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
                        <env-entry-type>java.lang.String</env-entry-type>
                        <env-entry-value>applicationContext.xml</env-entry-value>
                    </env-entry>

        Originally posted by jim
        In the web tier the life-cycle of the spring context depends on the servletContext. What determines the life cycle in the business tier?
        The context is being loaded from within ejbCreate(). So you will have one context per EJB instance.
        If you need to share common instances you should have a look at ContextSingletonBeanFactoryLocator.

        Hope that helps,
        Andreas

        Comment


        • #5
          Thanks for that!

          I am familiar with the example you point out but isn't this merely accessing a method which does the lookup of the bean given the 'ServicesConstants.CONTEXT_MYCOMP_ID' bean name?

          Do you see what I mean? Where do you specify the path to the spring ctx file that you were talking about?

          Jim

          Comment


          • #6
            Originally posted by jim
            I am familiar with the example you point out but isn't this merely accessing a method which does the lookup of the bean given the 'ServicesConstants.CONTEXT_MYCOMP_ID' bean name?
            Exactly. The point is not to make available the context itself to be used by the service methods.
            In ejbCreate (or rather onEjbCreate()) you access the context and retrieve the beans you need for operating your service. These beans you store in member variables so that they are available when a service method is being invoked. The service methods themselves are unaware of the origin of these beans.


            Originally posted by jim
            Do you see what I mean? Where do you specify the path to the spring ctx file that you were talking about?
            The superclass looks up your application-context file(s). For that purpose it looks up a location specified in the EJB environment (default entry name: ejb/BeanFactoryPath). In my prior posting I added a sample of the environment entry. It is part of a session-bean's deployment descriptor (from ejb-jar.xml).

            If you just specify "applicationContext.xml" a file with this name will be looked up in the root of a classpath entry (most likely the root folder of the ejb-jar it is located in). If you prefer a subpath like, say, "config", you can specify "context/applicationContext.xml". If you want to merge multiple xml files you can separate the filenames by whitespaces.

            Hope that helps,
            Andreas

            Comment


            • #7
              I have an existing app with entity ejbs accessed via a stateless sessionbean (SLSB) facade. We plan to re-arch it and throw the Entity EJBs out and use Hibernate in its place(meaning the SLSB stays, the CMP out)
              But using Hibernate without Spring is a pain (I would like to use HibernateTemplate to reduce the monotony of doing Hibernate otherwise)
              Also we have 2 diff groups doing the web part and the middleware part.
              The web people should not be aware of "applicationContext.xml". They would be accessing backend/middleware code via delegate calls(i.e., the session facade functions)

              This discussion above gives me a faint idea as to what to do with the problem at hand for me.
              a) I will need an applicationContext.xml file with references to the HibernateTransactionManager, datasource, Hibernate Session Factory, HibernateTemplate, the POJO services and the DAOs.(did I miss anything?) Correct?

              b) And this applicationContext.xml would be physically kept in the META-INF dir(same place as ejb-jar.xml). Correct?

              c)The thing said in the spring reference manual about transaction demarcation is this:-
              "Spring also provides convenience classes to help you implement EJBs. These are designed to encourage the good practice of putting business logic behind EJBs in POJOs, leaving EJBs responsible for transaction demarcation and (optionally) remoting".
              But can't I do transaction demarcation on the POJO service object? I can. Correct?

              d)Is there a better reference for doing what I have described in a place other than the reference manual?

              P.S:- I know it is a pain to use Spring like I have described, but the client is not convinced about Spring in a clustered, high availability enviroment and hence want to use an EJB container to trap Spring in

              Comment


              • #8
                Originally posted by ameelin
                a) I will need an applicationContext.xml file with references to the HibernateTransactionManager, datasource, Hibernate Session Factory, HibernateTemplate, the POJO services and the DAOs.(did I miss anything?) Correct?
                Sounds reasonable to me.

                Originally posted by ameelin
                b) And this applicationContext.xml would be physically kept in the META-INF dir(same place as ejb-jar.xml). Correct?
                You are not forced to put it there. As I stated earlier, you can place it anywhere in your ejb-jar.

                Originally posted by ameelin
                But can't I do transaction demarcation on the POJO service object? I can. Correct?
                Yes.

                Originally posted by ameelin
                d)Is there a better reference for doing what I have described in a place other than the reference manual?
                You might have a look in one of the books around Spring. There are quite some good ones around (besides the new one from Rod Johnson et. al. there are Pro Spring, Spring in Action, and I think some more).

                Regards,
                Andreas

                Comment


                • #9
                  Originally posted by Andreas Senft
                  You might have a look in one of the books around Spring. There are quite some good ones around (besides the new one from Rod Johnson et. al. there are Pro Spring, Spring in Action, and I think some more).
                  I see all reqd in pages 452-456 of "Pro Spring". Never knew I could have a seperate applicationContext.xml, seperate for the ejb-side of things (ahaMomentCount=ahaMomentCount++

                  Now a new(but connected question):-can I have a SLSB (old way of doing things, that is...not POJO impl of interface but EJB implementation of remote methods). Can I just stick an applicationContext.xml in META-INF and use Spring within the SLSB? (this could be asked in a diff way...can a pure SLSB be referred to in a Spring file? An example to look at would work as I don't have any setups to try this out easily)

                  Comment


                  • #10
                    Originally posted by ameelin
                    can I have a SLSB (old way of doing things, that is...not POJO impl of interface but EJB implementation of remote methods). Can I just stick an applicationContext.xml in META-INF and use Spring within the SLSB? (this could be asked in a diff way...can a pure SLSB be referred to in a Spring file? An example to look at would work as I don't have any setups to try this out easily)
                    These are two questions. First: to access a SLSB via Spring (that is to invoke methods on it) it does not matter if the SLSB's implementations does make use of Spring.
                    Second: Of course you can place an application-context file somewhere and add code to your "normal" SLSB to read it and use the beans within. However, why reinvent the wheel? If you want to see how it works, you might have a look into the EJB base classes provided by spring. It is clever, but no black magic .

                    Regards,
                    Andreas

                    Comment


                    • #11
                      Thanks.. I am going to extend the AbstractStatelessSessionBean class and see where things go.

                      Can I use hibernate with Spring with applicationContext.xml kept in META-INF?
                      I am gonna try to...but if you know something I don't know regards using hibernate from applicationContext.xml (within the ejb-side META-INF), please howl. Begs the question...can I pretty much do the same things(other than presentation-side manipulations) on ejb-side of things with applicationContext.xml in META-INF as I am able to do with WEB-INF/applicationContext.xml

                      Comment


                      • #12
                        I'm not sure I understand what your connection between hibernate and the application context is in this question. But surely you can use hibernate with spring and you can do your initialization of the SessionFactory in the application context.

                        From a conceptual point of view there is no difference between an application context used on the ejb layer and one used for web applications. It is realized by the same means anyway.

                        Regards,
                        Andreas

                        Comment


                        • #13
                          Trouble getting this to work

                          Hi

                          I am having a little difficulty getting the business/service pojo implementation to inject into the interface declared in the SLSB.

                          I have followed the advice in the manual and this thread but am getting a null pointer exception at runtime when I make a call to the SLSB business method which attempts to access the pojo instance.

                          Here is a snippet from my SLSB:
                          <slsb>
                          * @ejb.interface local-extends="javax.ejb.EJBLocalObject,uk.co.mycom.cbs. ejb.CBSJCTestBI" extends="javax.ejb.EJBObject"
                          * @ejb.home local-extends="javax.ejb.EJBLocalHome" extends="javax.ejb.EJBHome"
                          *
                          * @ejb:env-entry name="ejb/BeanFactoryPath" type="java.lang.String" value="applicationContextBE.xml"
                          * @ejb:bean name="CBSJCTest"
                          * display-name="CBS JCTest session Bean"
                          * type="Stateless"
                          * transaction-type="Container"
                          * view-type="both"
                          * jndi-name="ejb/cbs/Remote/CBSJCTest"
                          * local-jndi-name="ejb/cbs/CBSJCTest"
                          * @ejb.permission unchecked="True"
                          * @ejb:transaction type="Required"
                          *
                          */
                          public abstract class CBSJCTestEJB extends AbstractStatelessSessionBean implements
                          CBSJCTestBI{

                          CBSJCTestBI bizPojo;

                          protected void onEjbCreate() throws CreateException {
                          bizPojo = (CBSJCTestBI) getBeanFactory().getBean("testBizPojo");
                          }

                          /**
                          * @ejb:interface-method view-type="both"
                          */
                          public String testGetSomething() throws BasicException {
                          return bizPojo.testGetSomething(); //"test string returned from ejb!";
                          }
                          </slsb>

                          And my applicationContextBE.xml:

                          <quote>
                          <bean id="testBizPojo" class="uk.co.mycom.cbs.ejb.JCTestPojo" singleton="false"/>
                          </quote>

                          I have put my applicationContextBE.xml file in the cbs-ejb.jar root. The ejb jar file is deployed as part of an ear file (not sure if that would affect things).

                          The exception stack trace is as follows:
                          16:23:13,393 INFO [Server] JBoss (MX MicroKernel) [3.2.6 (build: CVSTag=JBoss_3_2_6 date=200410140106)] Started in 1m:8s:953
                          ms
                          16:23:24,518 WARN [SessionImpl] unclosed connection
                          16:23:33,299 INFO [TilesRequestProcessor] Tiles definition factory found for request processor ''.
                          16:23:33,424 INFO [PropertyMessageResources] Initializing, config='org.apache.struts.taglib.bean.LocalStrings ', returnNull=t
                          rue
                          16:23:33,471 INFO [PropertyMessageResources] Initializing, config='org.apache.struts.util.LocalStrings', returnNull=true
                          16:23:33,471 INFO [PropertyMessageResources] Initializing, config='org.apache.struts.taglib.html.LocalStrings ', returnNull=t
                          rue
                          16:23:33,471 INFO [PropertyMessageResources] Initializing, config='org.apache.struts.taglib.html.LocalStrings ', returnNull=t
                          rue
                          16:23:35,487 INFO [PropertyMessageResources] Initializing, config='org.apache.struts.actions.LocalStrings', returnNull=true
                          16:23:35,549 ERROR [LogInterceptor] RuntimeException in method: public abstract java.lang.String uk.co.mycom.cbs.ejb.CBSJC
                          TestLocal.testGetSomething() throws uk.co.mycom.cbs.common.BasicException
                          java.lang.NullPointerException
                          at uk.co.mycom.cbs.ejb.CBSJCTestEJB.testGetSomething( CBSJCTestEJB.java:52)
                          at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
                          at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
                          at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
                          at java.lang.reflect.Method.invoke(Method.java:324)
                          at org.jboss.ejb.StatelessSessionContainer$ContainerI nterceptor.invoke(StatelessSessionContainer.java:6 83)
                          at org.jboss.resource.connectionmanager.CachedConnect ionInterceptor.invoke(CachedConnectionInterceptor. java:186)
                          at org.jboss.ejb.plugins.StatelessSessionInstanceInte rceptor.invoke(StatelessSessionInstanceInterceptor .java:72)
                          at org.jboss.ejb.plugins.AbstractTxInterceptor.invoke Next(AbstractTxInterceptor.java:84)
                          at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTran sactions(TxInterceptorCMT.java:315)
                          at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxIn terceptorCMT.java:148)
                          at org.jboss.ejb.plugins.SecurityInterceptor.invoke(S ecurityInterceptor.java:111)
                          at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInt erceptor.java:191)
                          at org.jboss.ejb.plugins.ProxyFactoryFinderIntercepto r.invoke(ProxyFactoryFinderInterceptor.java:122)
                          at org.jboss.ejb.StatelessSessionContainer.internalIn voke(StatelessSessionContainer.java:331)
                          at org.jboss.ejb.Container.invoke(Container.java:709)
                          at org.jboss.ejb.plugins.local.BaseLocalProxyFactory. invoke(BaseLocalProxyFactory.java:419)
                          at org.jboss.ejb.plugins.local.StatelessSessionProxy. invoke(StatelessSessionProxy.java:83)
                          at $Proxy125.testGetSomething(Unknown Source)
                          at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
                          at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
                          at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
                          at java.lang.reflect.Method.invoke(Method.java:324)

                          Any help is much appreciated.

                          Jim

                          Comment


                          • #14
                            At first glance I see no problem here. However, I'm noticing that you use XDoclet. I remember a similar case where by using XDoclet somehow an empty ejbCreate()-Method has been created. This, in fact, overrides the method provided by Spring, which causes your onEjbCreateMethod() to never being invoked.

                            Maybe you can check this out?

                            Regards,
                            Andreas

                            Comment


                            • #15
                              A thousand 'thank-you's! That fixed my problem.

                              For anyone else experiencing the same problem here's the original post of the 'similar case' Andreas is referring to:

                              http://forum.springframework.org/sho...Create+XDoclet

                              (Not too sure, tho', where the ejbCreate method is being generated because it doesn't appear to be in either of my EJB implementation classes.

                              Jim

                              Comment

                              Working...
                              X