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>
