MyEclipse: [Closed] Deploying and debugging on WebSphere
axparker_national.com.au - Apr 27, 2005 - 02:20 AM
Post subject: [Closed] Deploying and debugging on WebSphere
I'm using WebSphere 5.1 on windows, MyEclipse 3.8.4.
I have the TraderX example app deployed (use package deploy, install the app with websphere console), and started.
I can "buy" (i.e. use the app).

I make changes to the Stateless session bean, and a jsp, then do the exploded deploy from MyEclipse.
My change is simple (change the logging statement in the session bean, add a html link to the jsp page).
I get the warning about the hot code sync not working (but it's definitely using the IBM jdk1.4.1), I just hit "continue".
I can see it unload and reload the jsp, it takes a while to recompile the jsp, and my change to the html shows up fine.
My change to the stateless session bean never has any effect.

Then I leave the application for about 30 minutes.
I do a redeploy from within MyEclipse (no changes).

Try to "buy" again (i.e. invoke the jsp page), and I get a missing Servlet error:

Error 500: Failed to load target servlet [TraderServlet]

[27/04/05 11:11:47:839 EST] 4edbe81e WebGroup E SRVE0020E: [Servlet Error]-[TraderServlet]: Failed to load servlet: java.lang.ClassNotFoundException: com.genuitec.traderx.web.TraderServlet
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:351)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:261)
at java.lang.ClassLoader.loadClass(ClassLoader.java:494)
at java.beans.Beans.instantiate(Beans.java:201)
at java.beans.Beans.instantiate(Beans.java:62)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadServlet(WebAppServletManager.java:188)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.getServletReference(WebAppServletManager.java:455)
at com.ibm.ws.webcontainer.webapp.WebApp.getServletReference(WebApp.java:652)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcherInfo.calculateInfo(WebAppRequestDispatcherInfo.java:172)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcherInfo.<init>(WebAppRequestDispatcherInfo.java:59)
at com.ibm.ws.webcontainer.webapp.WebApp.getRequestDispatcher(WebApp.java:1462)
at com.ibm.ws.webcontainer.webapp.WebApp.getRequestDispatcher(WebApp.java:1421)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:268)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:439)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:593)


Not sure what is going on here (new to the whole J2EE thing).

So at the moment, I have to undeploy and redeploy the app for every change :(

Andrew.
axparker_national.com.au - Apr 27, 2005 - 05:31 AM
Post subject:
The problem is worse than I thought.

I have the TraderX app deployed (using package deploy from MyEclipse)
and installed via WAS admin console, and started.

Make no changes, do an exploded deploy in MyEclipse (choose the "backup" option rather than the "remove" option).
Stop the app in the WAS admin console.
Start the app in the WAS admin console.
I get the following errors in the log

Quote:

[27/04/05 12:06:06:499 EST] 4e84a81f ApplicationMg A WSVR0200I: Starting application: TraderX
[27/04/05 12:06:06:624 EST] 4e84a81f EJBContainerI I WSVR0207I: Preparing to start EJB jar: TraderXEJB.jar
[27/04/05 12:06:06:655 EST] 4e84a81f BeanMetaData E CNTR0075E: The user-provided class "com.genuitec.traderx.interfaces.EJSStatelessTraderHomeBean_a24cdc19" needed by the EnterpriseBean could not be found or loaded.
[27/04/05 12:06:06:733 EST] 4e84a81f EJBContainerI E WSVR0209E: Unable to prepare EJB jar TraderXEJB.jar [class com.ibm.ws.runtime.component.DeployedModuleImpl], enterprise bean com.ibm.etools.ejb.impl.SessionImpl(Trader) (transactionType: Container, sessionType: Stateless)
java.lang.ClassNotFoundException: com.genuitec.traderx.interfaces.EJSStatelessTraderHomeBean_a24cdc19
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:351)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:261)
at java.lang.ClassLoader.loadClass(ClassLoader.java:494)
at com.ibm.ejs.container.BeanMetaData.loadExistedClass(BeanMetaData.java:2573)
at com.ibm.ejs.container.BeanMetaData.<init>(BeanMetaData.java:888)
at com.ibm.ws.runtime.component.EJBContainerImpl.createBeanMetaData(EJBContainerImpl.java:980)
at com.ibm.ws.runtime.component.EJBContainerImpl.createModuleMetaData(EJBContainerImpl.java:796)
at com.ibm.ws.runtime.component.EJBContainerImpl.createMetaData(EJBContainerImpl.java:1517)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createFactoryMetaData(MetaDataMgrImpl.java:115)
at com.ibm.ws.runtime.component.MetaDataMgrImpl.createMetaData(MetaDataMgrImpl.java:159)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:350)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:575)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:271)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:488)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:41)
at java.lang.reflect.Method.invoke(Method.java:386)
at com.tivoli.jmx.modelmbean.MMBInvoker.invoke(MMBInvoker.java:46)
at com.tivoli.jmx.modelmbean.MMBInvoker.invokeOperation(MMBInvoker.java:115)
at com.tivoli.jmx.modelmbean.DynamicModelMBeanSupport.invoke(DynamicModelMBeanSupport.java:409)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:323)
at com.tivoli.jmx.GenericMBeanSupport.invoke(GenericMBeanSupport.java:178)
at com.tivoli.jmx.MBeanAccess.invoke(MBeanAccess.java:113)
at com.tivoli.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:290)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:659)
at com.ibm.ws.console.core.mbean.MBeanHelper.invoke(MBeanHelper.java:141)
at com.ibm.ws.console.appdeployment.ApplicationDeploymentCollectionAction.perform(ApplicationDeploymentCollectionAction.java:315)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1791)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:974)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:555)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invoke(CacheableInvocationContext.java:114)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:186)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:439)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:593)

[27/04/05 12:06:06:764 EST] 4e84a81f DeployedAppli W WSVR0206E: Module, TraderXEJB.jar, of application, TraderX.ear/deployments/TraderX, failed to start
[27/04/05 12:06:06:780 EST] 4e84a81f ApplicationMg W WSVR0101W: An error occurred starting, TraderX


From then on, the TraderX app is completely broken, I need to reinstall from the ear using the WAS admin console.
support-rkalla - Apr 27, 2005 - 12:46 PM
Post subject:
Try exactly what you are doing but do it in this order:
1) Remove all existing deployments from ME and WS Console
2) Redeploy your app as packaged
3) Deploy using console
4) Make sure it works
5) Go into ME< remove the packaged deployment, setup an exploded deployment instead
6) Start working
7) Make a chance to a JSP page, see if it changed on the server, do the same for a EJB. Did it work?

You don't need to hit Redeploy when using exploded, the files are synced out to your app server automagically on file save.
axparker_national.com.au - Apr 28, 2005 - 01:13 AM
Post subject:
Thanks,
I followed the steps as listed.
Changes to the jsp showed up fine (as before).
Changes to the EJB didn't (as before).
I wasn't sure if this is just because it's a stateless session bean, so the instance is kept around
(but shouldn't the class be reloaded anyway?).

I tried stopping the TraderX app via the console, and restarting it (without doing a redeploy via MyEclipse).
Same error as before...
Quote:

[28/04/05 09:43:13:344 EST] 6959cf14 BeanMetaData E CNTR0075E: The user-provided class "com.genuitec.traderx.interfaces.EJSStatelessTraderHomeBean_a24cdc19" needed by the EnterpriseBean could not be found or loaded.
...



I've had a look at the files that end up in "exploded" version of the deployment, compared to the packaged deployment.
In the packaged deployment, the EJB is in the TraderEJB.jar, which is a directory in the exploded version.
The packaged deployment contains a lot more, the exploded version basically only has the .class files from the EJB directly.
e.g.

> pwd
/cygdrive/c/Program Files/WebSphere/AppServer/installedApps/mbkw052092/TraderX.ear/TraderXEJB.jar/com/genuitec/traderx/interfaces
>ls
Trader.class
TraderHome.class
TraderUtil.class

The corresponding directory from the unzipped jar from the package deployment...
>pwd
/cygdrive/c/Program Files/WebSphere/AppServer/installedApps/mbkw052092/TraderX.ear.myeclipse.bak/TraderXEJB.jar.unzipped/com/genuitec/traderx/interfaces

> ls
EJSRemoteStatelessTraderHome_a24cdc19.class
EJSRemoteStatelessTrader_a24cdc19.class
EJSStatelessTraderHomeBean_a24cdc19.class
Trader.class
TraderHome.class
TraderUtil.class
_EJSRemoteStatelessTraderHome_a24cdc19_Tie.class
_EJSRemoteStatelessTrader_a24cdc19_Tie.class
_TraderHome_Stub.class
_Trader_Stub.class

There's lots of other stuff in the jar that's not in the exploded deployment
(including org\omg\stub\javax\ejb, com\ibm\ejs\container and com\ibm\websphere\csi).

Am I right in assuming that these extra classes are generated when the app is installed via the console?
And MyEclipse can't generated them, because they are WAS specific?
If so, I don't understand how this can ever work, since the exploded version will never have these classes.
Even if they were somehow left over from the packaged version (or I copied them back in), they wouldn't necessarily be correct.

Or have I missed a step in configuration that lets MyEclipse generate these files?

Andrew.
support-rkalla - Apr 28, 2005 - 02:11 PM
Post subject:
Quote:

I wasn't sure if this is just because it's a stateless session bean, so the instance is kept around
(but shouldn't the class be reloaded anyway?).

It *should* but this is completely controlled by the App Server. I know some app servers have "refresh" intervals that they will check for changed files for, you might want to double check Websphere's docs and see if it can be set somewhere.

I asked a dev about "hot sync" and aparently it's very closely tied to the VM you are running wether it is a) supported or not and b) works. The most MyEclipse can do is copy the new file out and the rest is up to the app server to reload it.

Quote:

Am I right in assuming that these extra classes are generated when the app is installed via the console?

Exactly right, this is why there is an additional "deploy" step with some J2EE servers, they need to general these interfaces.

Quote:

And MyEclipse can't generated them, because they are WAS specific?

Correct, Jonas has different ones, Web Logic has different ones, Sun App Server has different ones, etc. etc. etc.

Quote:

If so, I don't understand how this can ever work, since the exploded version will never have these classes.

This is exactly why you have to do the 2-step process:
1) ME: Deploy pacakged deployment
2) WebSphere: Deploy app (generated files)
3) ME: Remove packaged deployment (EAR deleted)
4) ME: Create new packaged deployment, now all your project files will *overlay* ontop of the ones already deployed into the app server.
axparker_national.com.au - Apr 29, 2005 - 06:09 AM
Post subject:
Hi Riyad,

Quote:

Quote:

If so, I don't understand how this can ever work, since the exploded version will never have these classes.

This is exactly why you have to do the 2-step process:
1) ME: Deploy pacakged deployment
2) WebSphere: Deploy app (generated files)
3) ME: Remove packaged deployment (EAR deleted)
4) ME: Create new packaged deployment, now all your project files will *overlay* ontop of the ones already deployed into the app server.


I'll run through what happens when I do these steps...

Quote:

1) ME: Deploy pacakged deployment


The ear is installed in C:\Program Files\WebSphere\AppServer\installableApps\TraderX.ear

Quote:

2) WebSphere: Deploy app (generated files)


The ear is deployed, the stubs are generated, etc. etc.
In WebSpere, this means the ear ends up "partially exploded" in
C:\Program Files\WebSphere\AppServer\installedApps\mbkw052092\TraderX.ear
This is actually a directory, containing:
"META-INF" directory,
"TraderXWeb.war" directory (exploded),
"TraderXEJB.jar" (the actual jar).
Note that the "TraderXEJB.jar" contains the generated stubs.

Quote:

3) ME: Remove packaged deployment (EAR deleted)


The ear in the "installableApps" dir is removed.
The "partially exploded" ear in "installedApps" is not removed.
The app continues to run fine.

All okay up till here.

Quote:

4) ME: Create new packaged deployment, now all your project files will *overlay* ontop of the ones already deployed into the app server.


I assume you mean exploded deployment here.
If I create a new packaged deployment, the new ear gets put in "installableApps", which has no effect (unless I reinstall it via the WebSphere console).

When I add an exploded deployment, there is a radio button with two choices:
Quote:

An existing deployed resource has been found at location C:\Program Files\WebSphere\AppServer\installedApps\mbkw052092\TraderX.ear. Deployment of project TraderX will replace this resource. Please specify the action you wish to take during deployment:
- Backup remote resource before deployment; restore upon undeployment
- Delete remote resource before deployment

note: there is no choice to leave the files and overlay the new ones.

I've tried both of these options for the radio button.
In both cases, the entire TraderX.ear directory is replaced with the "exploded" version (from MyEclipse) that does not contain the generated stubs.
Now the App cannot be used, and cannot be restarted (due to errors listed in previous posts).

So MyEclipse is not overlaying the new class files onto the old deployment, it is removing the old deployment, and replacing it with the new one - minus the stubs.

Is there are way to get MyEclipse to stop removing all the files before deploying???

Andrew.
support-scott - Apr 29, 2005 - 03:27 PM
Post subject:
Andrew,

Thank you for that cogent and detailed description. Websphere is a bit of an odd beast, as you know, but I think I understand the problem you're experiencing will propose a workaround. Can you *first* deploy your application in an *exploded* configuration using the <Custom Location> target into the installedApps directory, which is the same path the WebSphere connector will try to use if you asked it to do an exploded deployment. Once the custom, exploded deployment is done, deploy the application as a packaged EAR using the WebSphere connector, and then install it using the WebSphere console.

The idea is that since you did the packaged deployment last, all the stubs will be generated and in place. And, since you did the exploded deployment first, they will not be overwritten. The benefit of having the exploded deployment is that it will detect changes to code in the workspace and sync it, file by file, as it happens. This should give you the synchronization you're looking for.

If a full redeploy is needed, you'll have to do both the exploded one first, and then the packaged one second, as you initially did.
axparker_national.com.au - May 03, 2005 - 06:14 AM
Post subject: Successful hot deploy (howto)
Scott, using the deployment in that order got me a lot closer, but it still didn't work.

The good news is that I did work out a way :-)

The problem was that MyEclipse was deploying the TraderXEJB.jar as a directory, but WAS was replacing that
with the TraderXEJB.jar (file). The trick is to let WAS set up the app with the jar (file) but manually
"explode" that back into a directory between the time you deploy and when you start the app. WAS is happy to use
the exploded jar (just like it uses an exploded war). Not sure why it's not always exploded, would make things
a bit easier.

I also found I had to enable EJB reloading when I install in WAS (no, it wasn't as simple as enabling this ;-)


Here is a step-by-step guide to what I did.

Code:

 - start with no app deployed/installed
 - add a packaged deployment in MyEclipse
 - backup the ear (in the InstallableApps)
 - remove the packaged deploy in MyEclipse
      this will remove the ear which is why we need the backed up
 - restore the ear from the backup
 - add an exploded deployment in MyEclipse
 - install the app in WAS
      - enable EJB reloading (step 1)
      - make sure you "Save to Master Configuration"
      this replaces the "exploded" EJB jar directory from MyEclipse with a EJB jar file from WAS that has the stubs
 - go to the InstalledApps directory and manually "explode" the EJB jar
      - rename TraderXEJB.jar to TraderXEJB.orig.jar
      - unzip the TraderXEJB.orig.jar to a directory named TraderXEJB.jar


Now it should be set up correctly.
To verify...
Code:

 - start the app in WAS
 - use the app
 - make changes in MyEclipse
 - use the app again
 - the changes should show up :-)


Some caveats:
I've only verified that simple changes work (adding logging statements to the stateless session bean).
Any serious changes to the EJBs may require the process to be repeated (at least partially) to regenerate the stubs etc.

Overall, I'm not sure that it's going to be feasible to use this process.
If anyone knows of an easier way to do this I'd be happy to know about it.
Kinda tempting to install JBoss and see if that's easier ;-)

Then again, as long as we can minimise changes to the EJBs (which is a good thing to do anyway) it might be okay.

Thanks again for the helpfull suggestions, and I hope this can help someone else.

Andrew.
support-scott - May 03, 2005 - 04:26 PM
Post subject:
Andrew,

Thank you for posting all this great information! I'm going to make this thread "sticky" so it'll be easier to find for everyone else that's interested in WebSphere deployment.

>Kinda tempting to install JBoss and see if that's easier ;-)

It's a *ton* easier. WebSphere, in my experiences, is extremely difficult to be productive with and the fact that they don't support the JSR-045 spec for JSP debugging, choosing instead to "do their own thing", makes much harder to be productive. I think you'll find that it's more difficult to use than any other server we support. But, if that's what's mandated at your company, what can you do?

Thanks again.
jdsrinivas - Feb 23, 2006 - 08:59 PM
Post subject:
Quote:

"com.genuitec.traderx.interfaces.EJSStatelessTraderHomeBean_a24cdc19" needed by the EnterpriseBean could not be found or loaded.


Do you have the file named "EJSStatelessTraderHomeBean_a24cdc19"?? As per Websphere documentation..

http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1/index.jsp?toc=/com.ibm.websphere.wbifz.doc/was50wbifz_toc.xml&tab=search&searchWord=Unable+to+prepare+EJB+jar&maxHits=50

Here is the explaination for that problem..

Quote:

WSVR0209E: Unable to prepare EJB jar {0}, enterprise bean {1} {2}
Explanation: An EJB can fail preparation if the container required classes have not been generated for the EJB.
User Response: Verify the EJB jar that contains the failed EJB {1} has been deployed.


Some one please help even iam getting the same problem

JD
jdsrinivas - Feb 23, 2006 - 09:09 PM
Post subject:
Iam getting this problem

Quote:

[2/23/06 15:25:43:122 EST] f9d2b21 BeanMetaData E CNTR0075E: The user-provided class "**.ejbmodule.useraccount.interfaces.EJSStatelessUserAccountHomeBean_7a183e9a" needed by the EnterpriseBean could not be found or loaded.


But i dont see any file named EJSStatelessUserAccountHomeBean_7a183e9a in my .jar file.
jdsrinivas - Mar 01, 2006 - 02:50 PM
Post subject:
this problem got resolved when i cleaned and build all the projects again and deployed.
sirjerr291 - Aug 31, 2011 - 09:52 AM
Post subject:
online workout - workout routines - workout
All times are GMT - 6 Hours
Powered by PNphpBB2 © 2003-2004 The PNphpBB Group
Credits