geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: undeploy behavior
Date Tue, 22 Nov 2005 05:06:49 GMT
I haven't seen a case where we create more than one module during a
deployment... but I never work with app clients much either.  I don't
like the sound of the behavior you're describing as it means that
redeploy can't really work as intended (where you give it a configId
and it replaces it).  Are there instructions for building the trade
application somewhere, so I can try this out for myself?

In any case, we should be giving the user a list of configIds at the
end of the deploy operation.  If we don't list all the modules we
created, that's a bug.

As for the file locking, I think that's a pretty well-established side
effect of Sun's URLClassLoader on Windows.  I wonder, if we mark those
files to be deleted on exit, would it work?

Thanks,
  Aaron

On 11/21/05, Kevan Miller <kevan.miller@gmail.com> wrote:
> 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