Accessing another .ear's POJOs

[mkoss]

We have multiple applications deployed in the same app server in different .ear files that need to talk to each other. The current solution is a .properties file in the parent classpath that defines the properties needed to look up an EJB in the other .ear. It would be much faster and less code if we could just grab a hold of a POJO.

What I would like to do is place a Spring context file in a parent classpath that one .ear could read and gain access to classes in the other .ear. I will admit I have not tried this because I am more in the theoretical thinking stage at the moment, but I do not see how app A could see the classes of app B.

We could, of course, define a bean in the parent classpath that is a LocalStatelessSessionProxyFactoryBean, or use Hessian. Is this really the only solution? Does anybody have any good ideas for this scenario?

Thanks,
Michael.

[wpoitras]

You could also put the POJOs outside the EAR and put it in the global classpath. Then each EAR's context could use that context as a parent.

[mkoss]

Yeah, I thought of that too, but management would not approve because they like the idea of a single deployment unit for each application. They have the phantom requirement (a phrase I love from Rod's book and have come to realize there are many, many phantom requirements) that a single application might need to be picked up and moved to another server center.

[wpoitras]

Yeah, I thought of that too, but management would not approve because they like the idea of a single deployment unit for each application. They have the phantom requirement (a phrase I love from Rod's book and have come to realize there are many, many phantom requirements) that a single application might need to be picked up and moved to another server center.

Then the only solution would be some remote call, because you never know when the application will move off to another server.

Since this code is only suppose to live in one application, its not truly shared, so trying to use the POJOs although sounds like a good idea, makes your application coupling tighter than management is comfortable with.