MY Eclpise Blue 9.0
Websphere 9.0.23

Issue Description and steps to reproduce
- Export your project as EAR file without generating stubs.
- Deploy your ear file on websphere 6.1.0.23 server. The websphere console will throw class not found errors.

How to fix?
You can provide additional class path entries during the ear deployment then it will stop throwing that exception. I am getting the same errors during my eclipse deployment.

Internally my eclipse blue runs a jacl script located at “C:\Program Files\MyEclipse Blue Edition\Common\plugins\com.genuitec.eclipse.blue.websphere61_9.0.0.me201103012021\installEAR.jacl”

The current script does not add custom class path during the deployment on websphere. Do you have any idea how we can fix this issue?

Is there a way to add class path in plugin jacl script instead of Manifest file? Here is the websphere issue description

http://www-01.ibm.com/support/docview.wss?uid=swg21265051

sg0210 ,

Can you tell us why you want to add classpath to jacl script instead of Manifest file ? Any reason why you cannot use the Manifest file ?

The reason is that we do not want to change settings for all projects and developers machine. In addition while adding classpath in manifest file I didnot see a consistence behavior on all developer machine that is being taken care during ejbdeploy. There might be couple of more solution the classpath entries in the java build path must be added during ejbdeploy option in jacl script.

Now I am able to deploy by modifying the script classpath without starting the server but when I start the server I am still facing the same class not found error

Logs without starting the server

EJBDeploy complete.
0 Errors, 0 Warnings, 0 Informational Messages
Could not delete file: C:\was6.1\atpco_WAS4D6.1\wst

Logs after starting the server

11:25:145 EST] 00000041 DeployEJBTask I ADMA0158I: [EJBDeploy] Error generating RMI code: RMIC command failed on project: XXXEJB with message:
[12/20/11 8:11:25:145 EST] 00000041 DeployEJBTask I ADMA0158I: [EJBDeploy] error: Class org.apache.log4j.Logger not found.
[12/20/11 8:11:25:145 EST] 00000041 Depl

Thanks
Sharad

Is there any update on this?

Sharad,

Sorry for the delay. I've been trying to figure out how to replicate your problem but I'm not sure how to do that. Can you provide more details about the kind of project you're trying to deploy, how you're exporting the project and what you mean by "without generating stubs". Please provide as much information as you can, including the precise steps you are taking to export and deploy the project when you see this error.

Also, what other methods have you tried to deploy the project without getting the errors? I'm not clear on what you've tried and where you're seeing errors.

Hello Tony

I think you need to create a temp project which must be dependent upon some shared classpath libraries settings in order to reproduce the issue. What happend while invoking ejbdeploy command myeclpise did not add the shared class path settings and hence this is the error

EJB Deploy configuration directory: c:\Program Files\ibm\WebSphere\WAS4D6.1\deploytool\itp\configuration/

framework search path: c:\Program Files\ibm\WebSphere\WAS4D6.1\deploytool\itp\plugins

Generating deployment code
Invoking RMIC--------------
error: Class org.apache.log4j.Logger not found.
error: Class net.atpco.common.message.MessageGroup contains an invalid argument type in method getFirstMessage.
error: Class RBD999Response contains an invalid return type.
error: Class RBD999PersistenceService contains an invalid return type.
error: Class net.atpco.rules.rbd.persistence.ejb.RBD999PersistenceService contains an invalid argument type in method maintainWorkingCopy.

5 errors

Reference
http://www-01.ibm.com/support/docview.wss?uid=swg21265051

We have fixed class not path error when the server is stopped in jacl script, however we are not able to fix during runtime.

Define a new variable to hold the classpath
set rmic_cp "N:\Tools\Shared Java Lib\apache\common\commons-dbcp.jar;N:\Tools\Shared Java Lib\apache\common\commons-beanutils.jar;N:\Tools\Shared Java Lib\apache\common\commons-collections.jar;N:\Tools\Shared Java Lib\apache\common\commons-fileupload.jar"

Add the classpath at the end of the optionsString in jacl script.
set optionsString "-nopreCompileJSPs -distributeApp -useMetaDataFromBinary $deployEJBOption -appname \"$appName\" -createMBeansForResources -reloadEnabled -reloadInterval 1 -deployws -validateinstall off $processEmbedConfig -filepermission .*\.dll=755#.*\.so=755#.*\.a=755#.*\.sl=755 -buildVersion Unknown -noallowDispatchRemoteInclude -noallowServiceRemoteInclude $webModuleMappingOption -deployejb.classpath \"$rmic_cp\""



Somehow if we can inherit the shared classpath during ear with EJB deployment then we can fix this issue. I think we need to talk further in order to understand more better.

BTW I am attaching some screen shots which might be able to help you to reproduce the same issue on your local environment.

Specify shared classpath settings Reference sccreenshot

- Create EAR project which must include EJB specification 2.1
- Create Some dummy classes may be you can refer the following guidelines and deploy this on Websphere 6.1.0.23 server
- The project must be dependent on some shared classpath settings

Thanks
Sharad

Sharad,

I believe we have seen a variation of this problem before and are researching your particular case right now. We do not have a workaround available at this time but will look into putting a fix for this in the 10.0.1 milestone stream, once we have one ready.

If we need any more information from you, we will post additional questions to this thread- sorry for the inconvenience caused and thanks for asking.

No problem Brian
I have more question
Is it possible to put classpath settings somewhere in classpath plugin xml?
I can try to do that if you can guide me how I can do this?

C:\Program Files\ibm\WebSphere\WAS4D6.1\deploytool\itp\plugins\com.ibm.etools.ejbdeploy\plugin.xml

<extension id="EJBDeploy" name="EJB/RMIC Deployer" point="org.eclipse.jst.j2ee.DeployerExtension">
<deployer
deployer_class="com.ibm.etools.ejbdeploy.EJBDeployer">
<runtime runtime_server_id="com.ibm.ws.ast.st.runtime.v61"/>
<runtime runtime_server_id="com.ibm.ws.ast.st.runtime.v60"/>
<runtime runtime_server_id="com.ibm.ws.ast.st.runtime.v60.portal"/>
<runtime runtime_server_id="com.ibm.etools.websphere.runtime.v51.base"/>
<runtime runtime_server_id="com.ibm.etools.websphere.runtime.v51.portal.base"/>
<component component_type="jst.ear"/>
<component component_type="jst.ejb"/>

</deployer>
</extension>

Sharad,

I'm afraid not, we do not read this extension point (we have custom deployment code) and so any changes you make here will be ignored.

Sharad,

You might try one of the following ways to fix the runtime class resolving issue (while still keeping modified jacl script to resolve the issue at EJB deploy level):

At development server side:
Define the server-level class loader and add a reference to the shared library to that class loader.
1. Define the new shared library if needed by opening server administrative console and navigating: Environment->Shared Libraries->New->set library name and classpath entries->Ok.
2. Define server class loader and add a reference to the library: Servers->Websphere Application Servers->Your server->Java and Process management->Class loader->(new class loader if no class loaders are defined yet)->Click class loader link->Shared library references->Add->Add the library and press Ok.

Alternative: At EAR side:
1. Create a following directories structure inside META-INF folder of your EAR: ibmconfig\cells\defaultCell\nodes\defaultNode\servers\defaultServer
2. Create libraries.xml file inside defaultServer folder and put the following contents into a file:
<?xml version="1.0" encoding="UTF-8"?>
<libraries:Library xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:libraries="http://www.ibm.com/websphere/appserver/schemas/5.0/libraries.xmi" xmi:id="Library_1324659649143" name="YourSharedLibraryName">
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-dbcp.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-beanutils.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-collections.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-fileupload.jar</classPath>
</libraries:Library>
3. Save file and refresh your EAR project.

Please let me know if this helps.

Best regards,
Denis.

Denis

1. We already have shared class path but that is not being added during ejbdeploy. Please refer my screen shot
2. I tried it is not working

The other solution we tried to override ws.ext.dir during server configuration but it is not picking up the additional classpath entries basically it is not overriding our custom classpath.

ws.ext.dirs = C:\Program Files\ibm\WebSphere\WAS4D6.1\java\lib;C:\was6.1\atpco_WAS4D6.1\classes;C:\Program Files\ibm\WebSphere\WAS4D6.1\classes;C:\Program Files\ibm\WebSphere\WAS4D6.1\lib;C:\Program Files\ibm\WebSphere\WAS4D6.1\installedChannels;C:\Program Files\ibm\WebSphere\WAS4D6.1\lib\ext;C:\Program Files\ibm\WebSphere\WAS4D6.1\web\help;C:\Program Files\ibm\WebSphere\WAS4D6.1\deploytool\itp\plugins\com.ibm.etools.ejbdeploy\runtime


-Dws.ext.dir=N:\Tools\Shared Java Lib\apache\log4j;C:\Program Files\ibm\WebSphere\WAS4D6.1\java\lib;C:\was6.1\atpco_WAS4D6.1\classes;C:\Program Files\ibm\WebSphere\WAS4D6.1\classes;C:\Program Files\ibm\WebSphere\WAS4D6.1\lib;C:\Program Files\ibm\WebSphere\WAS4D6.1\installedChannels;C:\Program Files\ibm\WebSphere\WAS4D6.1\lib\ext;C:\Program Files\ibm\WebSphere\WAS4D6.1\web\help;C:\Program Files\ibm\WebSphere\WAS4D6.1\deploytool\itp\plugins\com.ibm.etools.ejbdeploy\runtime;

Thanks
Sharad

Sharad,

Please find more suggestions about why the solutions described above could fail (it is important to test it with your JACL modifications in place):

Setting server class loader to reference the shared library:
1. I have a slightly different screenshot when the server class loader is set. Please find it attached (server class loader vs ejb container class loader?).
2. Server requires restart for class loader settings to take effect.

Using libraries.xml in EAR to contribute shared libraries to the server:
1. Library references in deployment.xml are still required when going this way.
Both
<?xml version="1.0" encoding="UTF-8"?>
<libraries:Library xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:libraries="http://www.ibm.com/websphere/appserver/schemas/5.0/libraries.xmi" xmi:id="Library_1324659649143" name="YourSharedLibraryName">
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-dbcp.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-beanutils.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-collections.jar</classPath>
<classPath>N:\Tools\Shared Java Lib\apache\common\commons-fileupload.jar</classPath>
</libraries:Library>
in libraries.xml

and

<classloader xmi:id="Classloader_1325267424124" mode="PARENT_FIRST">
<libraries xmi:id="LibraryRef_1268044178641" libraryName="YourSharedLibraryName"/>
</classloader>
in deployment.xml are required.

2. Library name(s) defined in libraries.xml should be different from the ones that are already defined in server through the administration console.

If none of above help please consider sending me a simplified example of the project(s) that do not work or the real-life projects if possible. Files can be sent to support@genuitec.com with "ATTN Brian" tag in subject or directly to me via the forum private message.

Best regards,
Denis.

Hello Brian

The screenshot that you have provided that is our problem like it is not considering the shared classpath while invoking ejbdeploy. The screenshot that I have is a solution to this problem,. If we can define EJB custom classpath then we can eliminate this problem. We have solved the problem by using two ways but not by using inside the project classpath settings

Export and deploy EAR and try to reproduce the classnotfound error

Solution 1: Specify EJB classpath refer my screenshot
Solution 2: Fixed JACL script and add the additional classpath entries
Solution 3: If somehow we can implement solution 1 or 2 in the ear classpath settings that might work while doing the ear deployment.

I will try your libraries and deployment settings and let you know.