On Jan 4, 2008 5:54 AM, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 1:31 PM, Jan Arend Jansen <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi,
> >
> > There are many ways to deploy a project during development of an
> > application
> > on Servicemix, but non of them seem to work very well (or I am using them
> > incorectly)
> >
> > - jbi:servicemix fails often because of missing dependencies that are
> > located at SERVICEMIX_HOME/lb. This is the case with the ODE SE for
> > example.
>
>
> You should raise a JIRA on Ode so that any missing dependency is included in
> the component.
> In an ideal world, components would not rely on the container classpath for
> required dependencies.
> The workaround is what you suggest: put it in the lib directory.
>
>
> >
> > - jbi:projectDeploy on a clean stanalone servicemix server works. Once. A
> > redeploy will consistently fail, until I delete the 'data' directory. I
> > also
> > tried -DforceUpdate, but still errors. Mainly:
> > java.lang.IllegalStateException: Process store and JBI out of synch.
> >
>
> This is also a problem from the Ode component. I don't think ServiceMix had
> anything to do with that afaik.
>
>
> >
> > - Copy the SA into SERVICEMIX_HOME/hotdeploy works, but is failing on a
> > running server often (FileNotFound exception. The process cannot access
> > the
> > file because its being used by another process). I need to restart the
> > server, clean the data directory again to make it work....The problem is
> > caused by the time it takes to copy the SA archive. The polling of SMX
> > does
> > not handle 'copy-in-progress' well, or so it seems. And I always need to
> > clean the data directory, or errors occur
>
>
> This is something that may be enhanced in servicemix. As a workaround, you
> should be able to just "touch" the file once it has been copied. Or first
> copy it on another folder and then simply "move" it. Could you please raise
> a JIRA ? Also, you may want to provide a patch for that.
This last issue is definitely an issue with copy vs. move. On Linux
and Unix platforms the mv utility is atomic whereas the cp utility is
not. I've seen this with many other types of middleware that support
hot deployment because they try to grab the artifact and deploy it
before it's fully copied. The only solution I've ever found to this is
to do a move rather than a copy because of the atomicity of the move
command.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Blog: http://bruceblog.org/
