Will do. BTW, I was able to stop the behaviour by modifying the AutoDeploymentService. It seems to start with lastMonitorTime set to epoch start (0L) and then check whether any zips are older than this. They always are hence it always redeploys on startup.
Now, I'm not sure what the intended behaviour is on startup w.r.t. installation dirs and zips but I figure this is not it. I'll put this in the Jira. -----Original Message----- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: Mon 11/28/2005 7:05 PM To: [email protected] Subject: Re: [servicemix-dev] Installing and Deploying & the Spring Client Toolkit This is a bug - something I'm looking into at the moment! do - you want to raise a jira issue - and can I checkily use your test case :) cheers, rob On 28 Nov 2005, at 18:44, Michael Studman wrote: > Guys, > > Using a simple test service (not using the Spring Client Toolkit) I've > been able to trace what seem like odd installation behaviour in > ServiceMix. > > Say the component in an installation package is called TestJBI and > TestJBI.zip is moved to the install directory, assuming the > wdir/defaultJBI/components directory is empty it installs correctly, a > directory in wdir/defaultJBI/tmp is created (but never deleted) and a > directory wdir/defaultJBI/components/TestJBI is created. Tracing my > bootstrap and lifecycle component classes I see: > > Bootstrap - init > Bootstrap - onInstall > ComponentLifecycle - init > ComponentLifecycle - install > Bootstrap - cleanUp > ComponentLifecycle - start > > All seems good! > > If I start up servicemix a second time where the there is already a > wdir/defaultJBI/components/TestJBI from the previous installation, > things don't go so smoothly: > > Bootstrap - init > Bootstrap - onInstall > ComponentLifecycle - init > ComponentLifecycle - install > Bootstrap - cleanup > ComponentLifecycle - start > ... > [WARN] Failed removing directory for component TestJBI > ... > Bootstrap - onUninstall > ComponentLifecycle - stop > ComponentLifecycle - shutdown > Bootstrap - cleanUp > Bootstrap - init > Bootstrap - onInstall > ComponentLifecycle - init > ComponentLifecycle - install > Bootstrap - cleanUp > ComponentLifecycle - start > > As you can see, the component is successfully installed again but then > ServiceMix shuts it down, only to restart it. From the WARN message I > see in the logs, it has something to do with being unable to remove > the > directory structure for the component. It seems to me that the > component > directory from the first ServiceMix run is used to launch my > service but > then ServiceMix is trying to install it again from the zip - > causing the > first instance to be shut down and then launching it again (possibly > after copying over the contents of the zip first). This is normally no > problem but when you throw service assemblies/service units into the > mix, they only seem to get launched for the first instance but not for > the second (meaning the component is installed but never deployed). > > I've attached my TestJBI installer I used. Is this a bug or am I doing > something really stupid? > > Michael. > > > > ________________________________________ > From: Michael Studman [mailto:[EMAIL PROTECTED] > Sent: 24 November 2005 19:06 > To: [email protected] > Subject: [servicemix-dev] Installing and Deploying & the Spring Client > Toolkit > > Hi, > > I'm using the Spring Client Toolkit to generate my service engine and > have a few issues/questions, some with the toolkit, and some with > ServiceMix (2.0.2) in general. > > 1) Firstly, It seems the toolkit wants to generates a jbi.xml file > which > doesn't comply with the schema. The problem is it creates a root > element > jbi with two children: component and services although the schema only > allows for there to be one child of either component | service- > assembly > | shared-library | services. Now, a deployed service with this invalid > jbi.xml seems to work OK so I suspect this is just handy shortcut > as an > alternative to creating a service-assembly zip + jbi.xml containing a > service-unit zip with a jbi.xml. Is this a correct view of what's > going > on here? > > 2) Secondly it would be nice to have the option for your component > to be > a MessageExchangeListener instead of requiring a thread per installed > component - I've been able to achieve this by making SpringComponent > implement MessageExchangeListener and then passing the MessageExchange > to SpringServiceRegistry.routeExchange() directly. There may be better > ways for this to be done but it seemed to work for me. Of course > you may > not always want this message-listening behaviour and I haven't thought > too much on how you would make it switchable. Also I'm not sure how > compatible this is with the desire to "generate standard JBI > components > and service units that can run in any JBI compliant container" > > 3) It seems like the setServiceContext() method on > ServiceImplementation > is never called... rather the context is supplied through init() on > ServiceLifecycleImplementation... > > 4) Is service.xsd really needed in the zip? I couldn't see a need for > it. > > 5) While playing around with point 1 above I indeed did create a > service-assembly zip + jbi.xml containing a service-unit.zip with a > jbi.xml. I transferred the services information out of the component's > jbi.xml and into the correct nested jbi.xml. My component seems to be > installed and my service unit seems to be deployed correctly and I end > up with an endpoint registered with the right service name, interface > name etc however I noticed that component installation happens from a > subdir of the wdir/defaultJBI/tmp directory. Later during the > servicemix > startup sequence I saw my Spring Toolkit component get uninstalled > (stop/shutdown) and then reinstalled in the correct directory location > (subdir of wdir/defaultJBI/components) however the same did not happen > to my service unit. This seems to happen because the autoinstaller > detects a directory change since its last scan - although what exactly > is happening is hard to say. Unfortunately my service-units don't get > redeployed and so I have an installed component but no service/ > endpoints > registered for it. Does any of this make sense? > > Michael. > <TestJBI.zip>
