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

Forgot to mention, I get multiple warnings during deploy as follows:

23:42:19,140 WARN [HeavyweightTypeInfoBuilder] No soap array info for
schematype: T=ArrayOfQuoteDataBean@
http://daytrader.samples.geronimo.apache.org

I've been ignoring, but something that needs to be sorted out. I haven't
investigated. Assume it's something that Matt will be looking into...

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