Hi John,
Thanks for the prompt response.
The classnotfound exception was coming when I bundled only a few EJBs in
an EAR and set the Manifest.mf entry to use the base class
archive.
As I am tried to deploy only a few of EJBs I did not receive a Out Of
Memory.
To make my situation clear.
I will not be able to separate the Application Components from the
Business Components.
The reason being that we have ported an application from its proprietary
runtime to J2EE.
The ported has been carried out using an automated porting program that
reads an export of the application code.
Similarly the entity beans were also generated using a porting
program.
We do not know the functionality or the working of the
application.
The requirement of the customer was to port and not
re-develop.
Thus I couldn't apply the any intelligent patterns in the ported
application.
Thanks any way for your inputs.
Your help is appreciated.
Regards
Rohit
-----Original Message-----Patrik,
From: Johan Eltes [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 11:02 PM
To: Rohit Parik; [EMAIL PROTECTED]
Subject: Re: How to package utility classes and third party classes withthe EAR
I guess there is no silver bullet to solve your problem.
Initially, the discussion was about classnotfound exceptions. But you also have problems with out-of-memory errors. How do they relate? What was your set-up when you got the classnotfound exception but succeeded to avoid the out-of-memory error?
The EAR is the unit-of-deployment is in the J2EE world. But that doesn’t scale to infinity. For very large application, it is generally advisable to partition the application into multiple ears. I don’t know whether it is applicable to your application, but I have found the following principles helpful in many cases:
Partition the system into two types of “components” (ear files):
Application components and Business Components.
Each application component consists of one war and one ejb jar. The ejb-jar conatins use-case-driven SLSBs that are implemented by calls to various business components (but not each other).
Each Business component consists of two ejb-jars: One with a set of Ebs – max 50 (or pairs of SB/DAO) and one with composite entity facade SBs, callable from the “outside”, i.e. from application component EJBs. The draw-backs of splitting the entity schema into multiple components, are balanced by the advantages you gain from a less monolithic application. This is just one possible approach. I have found the book “The Business Component Factory” by Peter Herzum, to be very useful when I’m challanged with large-scale system design.
/Johan
Den 2003-01-27 18.01, skrev "Rohit Parik" <[EMAIL PROTECTED]>:
Hi Johan,
The dependency graph is as follows:
war
|-->servlets & jsps
| |-->dependent-jar
and the archive is as follows
ear
|--war
|--ejb-jar ( contains about 647 SB and 206 EB - CMP )
|--dependent-jar
The dependent jar contains classes that are used by both the SB and the controller servlet and JSPs. These classes ( I call them base classes ) are the heart of the application as we have simulated a runtime ( something as you get in a 4 GL client server sort of environment ) using these classes.
Now here is list of features we want in the deployment structure
1. Hot deployment of a single or multiple SBs or EBs.
2. Hot deployment of the base classes.
3. Ease of re-deployment ( so that we dont have to create the ear again and again )
4. Usage of Local interfaces instead of remote as we need to pass objects by reference.
Since the deployable archive turns out to be around 250 MB WLS runs out of memory while trying to deploy.
Moreover I noted that if you create an ear and deploy it and later undeploy a single SB that is contained in the EAR WLS undeploys the entire EAR - HIGHLY undesirable.
What we have done for time being --
1. Created a JAR of the base classes and set that in system classpath for WLS 7.
2. Created 647 separate jars for the SBs and deployed them individually.
3. Created 206 separate jars for the EBs and deployed them individually.
4. Deployed the WAR file separately.
But due to this we pay the penalty of using remote interface calls.
We have used the WLS specific feature of Call By Reference - but we want to get away from it.
Please indicate in case you require any further information.
Any help is welcome.
Cheers
Rohit
-----Original Message-----
From: Johan Eltes [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 24, 2003 11:24 PM
To: Rohit Parik; [EMAIL PROTECTED]
Subject: Re: How to package utility classes and third party classes withthe EAR
At runtime, WLS 7 makes all jars of the ear available to all J2EE module classloaders, regardles of whether there is a classpath entry in the module archive manifests. This is a defect of WLS. You problem occurs already at deploy time, but I would suspect that it is not related to the manifests of module archives. I’m not sure I have understood your dependency graph. Would the following description mirror your dependencies?
war
|-->ejb-jar
| |-->dependent-jar
|-->dependent-jar
with the following archive layout:
ear
|--war
|--ejb-jar
|--dependent-jar
/Johan
Den 2003-01-23 10.56, skrev "Rohit Parik" <[EMAIL PROTECTED]>:
How do i package utility classes / third party classes with my EAR that already contains about 648 session beans. These interfaces of these session beans use those utility classes.
When i try to deploy the EAR after including the utility classes as a simple jar in the EAR WLS 7 is unable to deploy and gives a NoClassDefFoundError.
I understand that one should package these sort of classes using the ejb-client-jar option. But some how even that is not working.
I do not want to keep these in the system class path as any pactch would mean restart of WLS which is highly undesirable.
Any solution is welcome.
Regards
Rohit
