geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject undeploy behavior
Date Tue, 22 Nov 2005 04:24:02 GMT
I've started taking a look at problems we have deleting config-store
directories during undeploy. As I've been looking at the problem, I've
encountered a few surprises. I'm wondering how we expect users to know what
modules they should be undeploying. Do we have a precise description of how
users should go about understanding what happens during a deploy and how the
effects of a deploy can be undone?

As an example, a deploy of DayTrader will create the following
modules/config-store directories:

1) Trade (configid of application defined in daytrader-plan.xml)
2) tradeStreamerAppClient (clientConfigId of an application-client defined
in daytrader-plan.xml)
3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web services?
it's not in the daytrader plan).

I was naively attempting to undeploy DayTrader with an 'java -jar
deployer.jar undeploy Trade'. However, it seems that this will only deal
with the 'Trade' module, not the other two modules. Is this as intended? Or
is there a basic bug?

It's a bit confusing because a subsequent redeploy of DayTrader will work.
New tradeStreamerAppclient and wsappclient modules/config store directories
will be created (however the old config-store directories will not be
deleted).

So, in order to properly undeploy "DayTrader", I must know the configids of
the application(s), application-client(s), and any dynamically generated
resource(s) which have been mapped to a module. Each module must be
specifically deleted (i.e. undeployed). Is all of this correct? Seems like a
non-intuitive task, to me... Is all of this described somewhere?

FYI, I rarely see the config-store directories being properly deleted after
undeploying the DayTrader modules. We're almost never able to delete the jar
files in the Trade config-store directory. I assume (as others have
surmised) that there is a Classloader hanging around with file descriptors
open to the jar files.. I'm working to get a handle on the problem...

--kevan

Mime
View raw message