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

[jim]

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

[Andreas Senft]

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

[jim]

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

[Andreas Senft]

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):

            <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>

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

[jim]

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

[Andreas Senft]

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.

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

[ameelin]

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

[Andreas Senft]

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.

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.

But can't I do transaction demarcation on the POJO service object? I can. Correct?

Yes.

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

[ameelin]

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)

[Andreas Senft]

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