cancel
Showing results for 
Search instead for 
Did you mean: 

NoClassDefFoundError When Accessing Class from EJB (from WD)

detlev_beutner
Active Contributor
0 Kudos

Hi there,

This one drives me crazy (but maybe, I'm overlooking some simple setting...):

We have a WD project, an EAR project, an EJB project. Within the EJB project, we have some EJB and some helper classes.

Problem: The WD calls the EJB, and when within the EJB a helper class should get into the game, a NoClassDefFoundError is thrown. This is really strange in my eyes, as the EJB itself could be resolved and we are talking of a class within the same JAR!

The WD project has a SharingReference to the EAR project. The EAR encapsulates the EJB JAR, and this definitely contains the class the server later is complaining about.

The stack trace is like this:

com.sap.engine.services.ejb.exceptions.BaseEJBException: Exception in method getList.
	at com.xxx.sessionfacade.ejb.ManagerSBLocalLocalObjectImpl0_0.getList(ManagerSBLocalLocalObjectImpl0_0.java:191)
	at com.xxx.client.bd.SomeBD.getTrackingList(TrackingBD.java:68)
	[...]
	at com.sap.tc.webdynpro.progmodel.context.Node.supplyElements(Node.java:403)
	at com.sap.tc.webdynpro.progmodel.context.Node.getElementList(Node.java:346)
	at com.sap.tc.webdynpro.progmodel.context.Node.getElements(Node.java:334)
	at com.sap.tc.webdynpro.progmodel.context.Node.size(Node.java:718)
	at com.xxx.wd.MainComp.filter(MainComp.java:298)
	[...]
	at com.sap.tc.webdynpro.progmodel.generation.DelegatingComponent.doInit(DelegatingComponent.java:95)
	[...]
Caused by: java.lang.NoClassDefFoundError: com.xxx.business.dao.SomeDAO
	at java.lang.Class.initialize(Class.java:307)
	at com.xxx.sessionfacade.ejb.ManagerSBBean.getList(ManagerSBBean.java:75)
	[...]
	at com.sap.tc.webdynpro.progmodel.context.Node.supplyElements(Node.java:403)
	at com.sap.tc.webdynpro.progmodel.context.Node.getElementList(Node.java:346)
	at com.sap.tc.webdynpro.progmodel.context.Node.getElements(Node.java:334)
	at com.sap.tc.webdynpro.progmodel.context.Node.size(Node.java:718)
	at com.xxx.wd.MainComp.filter(MainComp.java:298)
	[...]
	at com.sap.tc.webdynpro.progmodel.generation.DelegatingComponent.doInit(DelegatingComponent.java:95)
	[...]

com.xxx.wd.* comes from the WD project; com.xxx.sessionfacade.ejb.ManagerSBBean comes from the EJB project, as com.xxx.business.dao.SomeDAO does, too!

Already restartet the server --- and no, the classloaders don't seem to have had a simple hiccough

Thanks in advance & best regards

Detlev

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Detlev,

I guess it could be that somehow complete EAR project (with EJB reference) was not deployed properly on the server.

I would recommend you to try to follow the below steps:-

1) DC build your EAR project, create archive & deploy it on the server (can delete the older archive first).

2) DC build your WD project, Deploy new archive & run your application (you can also remove the project reference & add it again before the build operation).

Hope it works.

Kind Regards,

Nitin

Answers (1)

Answers (1)

Former Member
0 Kudos

hey ,

did u add the name of the EJB ear in libarary refernces under webdynpro refernces when u click properties which u get rt.clking ur dc / project name ??

If u dont add the EJB ear in library refernce, the wd dc / project wont be able to catch the refernce of the EJB ear on server.

detlev_beutner
Active Contributor
0 Kudos

Hi everybody.

@ parama laha: "did u add the name of the EJB ear in libarary refernces" No, and it's also wrong. The runtime reference to the EAR is set under Sharing References (it is a reference to the EAR - an application). And this I did, as written in the question. Otherwise resolving the EJB itself would not have worked!

@ Nitin Jain: I really undeployed the EAR this morning, but with no immediate success (in the end, it was also the only thing I could think of). BUT: After this, we had another exception, which took us on the right track. In the constructor of SomeDAO (the helper class I was speaking of), another class was referenced; that one was within a different EAR project, and the reference within the application-j2ee-enigne.xml was missing.

So, the "java.lang.NoClassDefFoundError: com.xxx.business.dao.SomeDAO" message was somehow "wrong", as - as I expected - SomeDAO could be resolved (but not initialized). The NoClassDefFoundError for the third party helper class then let us took the right action, et voilà, the original NoClassDefFoundError had gone.

So it was really a hard one: On the one hand the "NoClassDefFoundError: com.xxx.business.dao.SomeDAO" was "wrong", on the other hand the causing NoClassDefFoundError was missing.

Thanks anyhow,

best regards

Detlev