geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: undeploy behavior
Date Tue, 22 Nov 2005 05:29:45 GMT
On 11/22/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>
> 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?


DayTrader is in sandbox/daytrader. There's a README which is accurate.
Should be something like:

cd sandbox/daytrader
maven
<start the server>
set GERONIMO_HOME env variable
derby/createDB.sh
deploy modules/ear/target/daytrader-ear-1.0-SNAPSHOT.ear daytrader-plan.xml

I think I had a problem with ActiveMQ dependencies, but that may have been
because I've been running with a private ActiveMQ build to pick up a fix...

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?


The files are marked to be deleted on exit. However, in the past, the files
weren't deleted. I haven't checked this recently.

--kevan

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