geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: undeploy behavior
Date Tue, 22 Nov 2005 09:00:18 GMT

On Nov 21, 2005, at 9:41 PM, Kevan Miller wrote:

>
> On 11/22/05, Kevan Miller <kevan.miller@gmail.com> wrote:
>> On 11/22/05, Aaron Mulder < ammulder@alumni.princeton.edu> wrote:
>>> 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...

This is just warning you that your jaxrpc type mapping is not portable, 
but we are guessing what you want.  To gauge the severity of the 
problem, AFAICT no one, including Sun, has ever succeeded in writing a 
portable jaxrpc type mapping for a non-trivial soap message.

thanks
david jencks

>
>>>
>>>  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