- This topic has 6 replies, 2 voices, and was last updated 14 years ago by
.
-
Posts
-
Hi,
In the process of evaluating MyEclipse Blue as a replacement to RAD7, we noticed a few things for which we wanted to double-check that we were not missing something:(1) Deployment is done in the form of a “Packaged” EAR. An “Exploded” option is present in the deployment dialog (refer linked Image-1) – but isn’t enabled.
The side-effect of this is that “hot deployment” doesn’t seem to be supported (needs a full redeploy of EAR for any change to any source / resource file).
(2) Profiling of projects deployed to WAS is not possible using the integrated VisualVM tool.
(3) There is no code-review tool built-in – though the standard Eclipse plugins for PMD, Checkstyle, Findbugs et al can be integrated.
Can someone confirm that these features are not supported in the current release ?
Thanks and Regards.
Environment: WinXP | WAS7 | MyEclipseBlue on Sun/Oracle JDK 1.6 | Project JVM pointing to IBM JDK integrated with WAS7.
Linked Image-1:
(1) Deployment is done in the form of a “Packaged” EAR. An “Exploded” option is present in the deployment dialog (refer linked Image-1)
On the WebSphere 7 configuration page, if you edit your instance, you will see a Classic and Enhanced deployment mode. While the Enhanced mode is more robust (w.r.t. picking up changes made), it can be slower at times. If you enable the Classic mode, you will be allowed to select the Exploded option during deployment.
(2) Profiling of projects deployed to WAS is not possible using the integrated VisualVM tool.
It is supported, however, there may be some problems with WebSphere 7 in particular – can you tell me which server you are trying to profile against?
(3) There is no code-review tool built-in – though the standard Eclipse plugins for PMD, Checkstyle, Findbugs et al can be integrated.
Correct, no built-in tools but external tools can be easily installed.
Thank for asking, please let me know if there is anything else we can assist with.
Brian,
(1) Thanks for the “Classic” mode tip. “Hot deployment” sure seems to work better under this mode as changes are picked up on the fly as expected.
Going by this experiment – Classic mode seems to be better suited for development (turnaround time is less) – whereas in Enhanced mode – every change requires a redeploy – which stops/starts the enterprise-app (only the app – not the server – but still the turnaround time is significantly higher).
In that context – wanted to verify – what is the downside (if any) of the Classic mode and why the configuration dialog calls it more “robust” ? What does the robustness translate to in practice / what should we be careful of when using Classic mode ?
(2) We are profiling a typical EAR (no EJBs actually) – deployed on Websphere 7 only. Is there a guide to how to integrate VisualVM with WAS7 ?
VisualVM seems to work over JMX – and not via JVMPI/JVMTI as other profilers do – so is there any special setting required on WAS side ?
(3) Thanks for the confirmation.
TIA.
The text for “enhanced” mode in the configuration dialog called it more “robust” (as did you in the reply above). So what is the down-side (if any) of the Classic mode (or in other words – what does robust translate to in practice)?
Brian,
(1) Thanks for the “Classic” mode tip. “Hot deployment” sure seems to work better under this mode as changes are picked up on the fly as expected.
Going by this experiment – Classic mode seems to be better suited for development (turnaround time is less) – whereas in Enhanced mode – every change requires a redeploy – which stops/starts the enterprise-app (only the app – not the server – but still the turnaround time is significantly higher).
In that context – wanted to verify – what is the downside (if any) of the Classic mode and why the configuration dialog calls it more “robust” ? What does the robustness translate to in practice / what should we be careful of when using Classic mode ?
(2) We are profiling a typical EAR (no EJBs actually) – deployed on Websphere 7 only. Is there a guide to how to integrate VisualVM with WAS7 ?
VisualVM seems to work over JMX – and not via JVMPI/JVMTI as other profilers do – so is there any special setting required on WAS side ?
(3) Thanks for the confirmation.
TIA.
Apologies for the double post. Pls. refer to the 2nd / later one (has an extra question under (2)) and ignore/delete the previous.
Thanks.
s2dev,
1) It’s hard to pinpoint exactly what the benefits are, it depends to some extent on your app and the type of changes you regular make. For instance, if you change static methods or maybe some applciation metadata/XML resources, the standard classic mode will attempt to push them to the server, but would fail to produce the expected reaction. The enhanced mode though, will pick up these changes.
As far as a how it works technically works – in classic mode, changes are pushed to the deployment location and it is left (for most part) to WebSphere to pick these changes up. In the enhanced mode, a “diff unit” is created with only the changes since the previous deployment and deployed to WebSphere using a WebSphere standard technique.
If the classic mode is working well in your development experience, by all means, continue to use it.
2) I will provide more details on Visual VM shortly – my team is currently looking into it.
Brian,
1) Thanks – that explanation helps a lot. If I may prod a little bit more – for the “diff unit” deployment :(i) Will MyEclipse pick up the changes automatically (on save) or only when we click “redeploy” ?
(ii) Will WAS always restart the application?
(In our experience it always seems to restart the app (not the server) when we “redeploy” in Enhanced mode and this tends to take a significant time – esp. if there are startup processes involved).
If so – then there is no difference between the diff-unit and a full redeploy …. So hoping there is a shorter/”hot”ter mode – that we may have missed for some reason (or is it upto WAS to decide between full & partial) ?2) Will await the details on VisualVM-with-WAS7.
For now it looks like this will require additional investment on a standalone profiler if we want to migrate away from RAD 🙁Thanks again for the support.
