J2EE Libraries & EJB

[Former Member]

I am packaging the remote & home interfaces of ejb in a J2ee library for class reference. When i lookup it is returning ObjectReferenceImpl. How can i lookup and call a ejb from J2ee lib? My issue is that app reference is not allowed in library. Then how would i refer to home and remote without packaging them?

"Vladimir Pavlov" from SAP server team wrote an article explaining how to look up ejbs from diff clients. He said lookup from J2ee libraries is possile but didnt explain it clearly. I am hoping he would shed some light on this.

[Former Member]

Appreciate the response.

1. I am not using EJB 3.0 and i don't think its an EJB 2/3 issue.

2. It is definitely possible to look up ejb from j2ee lib by packaging the home,remote and stubs. But i am not sure how to get around the class loader issue.

I am not sure what you mean by J2ee lib is deprecated. As far as i know it is implemented differently in 7.1 which solves all these issues i have. But i have to work on 7.

[siarhei_pisarenka3]

Hi KC

Try to package EJB remote interface into your Lib. Then classcast object returned by JNDI lookup to the remote interface packaged in the lib:

java.lang.Object javax.rmi.PortableRemoteObject.narrow (java.lang.Object narrowFrom, java.lang.Class narrowTo)

BR, Sergei

[Former Member]

Well, that's exactly what i am doing. But the look up still fails because the class loader wont recognize 2 copies of the same class.

[siarhei_pisarenka3]

But why do you have 2 copies of the same class? Remove all the references from the Lib to the App. The Lib must contain just the remote interface package without references to the EAR. Then you'll exactly one copy of the class.

BR, Sergei

[Former Member]

1. I don't have any reference to app from library. It wont allow it. Deployment will be refused.

2. What i mean by 2 copies is one copy in the J2EE app and one in the library.

3. Class loader will treat it as 2 diff classes even though it is same because it is present in 2 diff locations. That's how class loader works. Issue here is the client and app both are in same JVM. If they are not its not an issue.

[siarhei_pisarenka3]

Hi KC

I see the following problems here:

1. You do not want to implement client App, but trying J2EE Lib. This does not allow you to reference EJB local interface from the EJB App.

2. You cannot package EJB local interface in the Lib, because there will be two copies of the same class.

3. You cannot package EJB remote interface in the Lib too, because there is only one JVM and this prevents you from using the remote interface at all. Operation narrow does not help too.

What can I suggest you then is some extremal technics:

a) Use Java Reflection API in order to access/invoke methods of the looked up object.

b) Somehow you can try to use java.lang.reflect.Proxy class to establish a mapping between two EJB interface instances that you have on run-time.

BR, Sergei

[Former Member]

Tried that approach too.

Issue with that is

J2EE server always returns a local reference instead of remote when the lookup is happening within the same J2EE Engine. Doesnt matter whether you lookup remote or local home. This is done to improve the performance. I read it in an offical SAP document and can;t find that doc again now. So the issue is my lib has to have a reference/access to the remote and home in order to lookup. without that the lookup also fails to load the object for narrowing.

There is a property force_remote in the initial context properties which will force the engine to provide remote but it need URL,user name and password which makes the application much more difficult to maintain to have user ids and support urls in a cluster. I tried that approach also with some hard coded passwords and it didn't work. Looks like again its an optimization implemented to ignore the flag if the look up is within the engine.

So i guess the only alternative is to create a web service for the ejb and generate proxies and use them in my lib. Which i don't like.

I never wanted to implement EJB for this purpose as i really didnt see much value but then i did it anyway to satisfy the "good design" theories that i don't agree with. But funny thing is ejbs are implemented to return local references to improve performance and i am right for not ready to use them in first place.

[siarhei_pisarenka3]

>I am not sure what you mean by J2ee lib is deprecated. As far as i know it is implemented differently in 7.1 which solves all these issues i have. But i have to work on 7.

It's deprecated because

- SAP J2EE Libraries does not support all powerful features that J2EE Applications provide. Start & Stop, for example.

- If you need to include some JAR in your application you may use External Library DC concept. So J2EE App + Ext Lib can replace J2EE Lib in all the cases.

- SAP J2EE Libraries is not a standard J2EE feature.

BR, Sergei

[siarhei_pisarenka3]

Still I do not understand why you cannot use EJB local interface + Java Reflection API. I know that this is the bad solution, but using the remote interface on the same JVM does not seem much better.

BR, Sergei

[Former Member]

I don't agree with this.

- SAP J2EE Libraries does not support all powerful features that J2EE Applications provide. Start & Stop, for example.

These are libraries. There is nothing to start and stop. I don't have to

- If you need to include some JAR in your application you may use External Library DC concept. So J2EE App + Ext Lib can replace J2EE Lib in all the cases.

Doesn't work. If you follow the external library approach then you are packing the jar into every app that you build. Where as with J2ee libs its only in one place and and shared by all the apps. Advantage is if i change the implementation of a class in the lib i don't have to build and redeploy all the apps. If i use external lib then i have to build and deploy all the apps each time i change something in the my external jar.

- SAP J2EE Libraries is not a standard J2EE feature.

I don;t really care if this useful feature is not included in java. Its Java's loss. BTW everybody supports this shared library concept now a days ....ex: SAP,Weblogic.....

What i learned in my experience is you can not port applications from one server to another without making some modifications even though all of these are "J2ee" complaint.

Secondly i never saw anyone trying to port apps across app servers.

[Former Member]

There is a little long explanation why it wont work.

Read this.

http://help.sap.com/erp2005_ehp_04/helpdata/DE/be/2e2c4142aef623e10000000a155106/frameset.htm

Secondly i am not using remote interfaces within the same engine. I am using local interfaces instead, not that its any better than using a straight java class. I have to do it to satisfy some section of people.

This particular problem i have is in one scenario where i have a EJB facade which calls a diff ejb for underlying operation. This facade will be used by any non -j2ee apps like libraries without knowing the underlying implementation or signature. Thats the only reason why i need a remote only in this case to separate 2 apps.

This is just like a CAF app where operation can be discovered using service browser. In my case my facade is scaled down service browser.

[HimanshuB]

Hi KC,

Did you find solution for your problem?

I am in similar situation where I want to lookup an EJB contained in different ear app and I do not want to keep the application reference to the other ejb/ear app.

Regards,

HB

[siarhei_pisarenka3]

Hi KC

I'm afraid, you cannot do this, because references from J2EE Lib to J2EE Apps are forbidden. J2EE standard does not have such term as J2EE Lib. This is native SAP invention.

By the way, J2EE Lib is deprecated in NW. Try to create J2EE App (EAR) and you will avoid such problems.

If you want you may explain your scenario in details.

BR, Sergei

[ekaterinamitova]

Hi,

If you use EJB 3.0, you have to use the EJB Lookup Scheme to access your beans:

http://help.sap.com/saphelp_nwce711/helpdata/en/45/e692b2cfaa5591e10000000a1553f7/frameset.htm

If not, tell me, I will look for another solution.

Best regards,

Ekaterina