[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585690#action_12585690
]
Shiva Kumar H R commented on GERONIMODEVTOOLS-322:
--------------------------------------------------
References:
1) Revision: 475352
Author: sppatel
Date: 12:12:26 AM, Thursday, 16 November 2006
Message:
fix dup redeploy's if root module and child modules both have deltas
----
Modified :
/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/Activator.java
Modified :
/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/GeronimoServerBehaviourDelegate.java
Modified :
/geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/internal/Trace.java
2) Design flaw in Generic Server Framework
https://bugs.eclipse.org/bugs/show_bug.cgi?id=123676
What does the fix do?
Please see " ------- Comment #8 From Tim deBoer 2007-09-18 09:52:27 -0500
------- " on the bugzilla report (2) above. It says "The easiest
implementation for a server that only publishes full EARs is to override
publishModule() and ignore some of the calls, or it can just override the full
publishModules() method."
The problem with GEP is, it does both ->
a) override publishModule() and ignore some of the calls,
b) override the full publishModules() method."
a) is done using the below condition in
org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModule(int,
int, IModule[], IProgressMonitor)
if (module.length == 1 && (deltaKind == ADDED || deltaKind == REMOVED
|| deltaKind == NO_CHANGE)) {
b) is done using below condition in
org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModules(int,
List, List, MultiStatus, IProgressMonitor)
if(!rootModulesPublished.contains(module[0])) {
Although this works for "deploy" & "redeploy", it fails for "undeploy". With
"deploy" or "redeploy", order of modules is just right (root ear, web &
ejb-jar) and we won't face this problem. But with undeploy, order is reversed
(ejb-jar, web & ear) and we hit the problem.
This is fixed by changing the conditions in
org.apache.geronimo.st.core.GeronimoServerBehaviourDelegate.publishModule(int,
int, IModule[], IProgressMonitor) as below:
if (deltaKind == NO_CHANGE && module.length == 1) {
invokeCommand(deltaKind, module[0]);
} else if (deltaKind == ADDED || deltaKind == REMOVED || deltaKind ==
CHANGED) {
invokeCommand(deltaKind, module[0]);
}
> Undeploying an EAR doesn't actually remove it from server
> ---------------------------------------------------------
>
> Key: GERONIMODEVTOOLS-322
> URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-322
> Project: Geronimo-Devtools
> Issue Type: Bug
> Components: eclipse-plugin
> Affects Versions: 2.1.0
> Reporter: Shiva Kumar H R
> Assignee: Shiva Kumar H R
> Priority: Critical
> Fix For: 2.1.0
>
>
> Steps to recreate:
> 1) Create a Dynamic Web Project and an EJB project. Then create an Enterprise
> Application Project (EAR) with the web & ejb projects added as its modules.
> 2) Now deploy the EAR from within GEP. Observe from Admin Console that EAR is
> in fact deployed onto server.
> 3) Now undeploy the EAR from within GEP. Although GEP shows the EAR as
> removed from server, observing from Admin Console shows that EAR is not at
> all undeployed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
