Believe it or not, part of HiveMind's goals is to be *simple*. Some systems, like OSGi and Jini, and even somewhat Spring, have the ability to re-deploy a service (or service implementation) and transition existing clients over to the new code.
HiveMind doesn't do this; it is designed to be J2EE friendly, with the intention that you redeploy your updated app and existing clients need to re-connect. Further, the way HiveMind works allows for some very involved relationships between services and modules. The overhead that would be necessary to track this properly (especially the contributions aspect) would be prohibitive, if it was even possible. In you sitution, would is be reasonable to deploy a new EAR (that incorporates a version number) and leverage J2EE for connecting clients to the new or old code? On Wed, 30 Mar 2005 16:22:24 +0200, Guy Hacham <[EMAIL PROTECTED]> wrote: > The services cannot be shutdown as they need to service clients from > previous versions, i.e. v4.0. yes, the services are called remotely by > a client application, but there are also other services that are > running locally on the server doing some background processing. > > The scenario for justifying this situation is when you have 2 versions > of the same system running on 1 server that needs to serve clients and > other background processes of these two versions. > > There are way to deal with it by changing package names or class names > to reflect the version they are developed for, i.e. > com.acme.40.SomeClass nad com.acme.41.SomeClass but I find this > technique cumbersome. > A nicer solution is to be able to develop com.acme.SomeClass and use > the SCM for maintaining versions. On the deployment descriptor, in > this case, hivemodule.xml you will be able to denote the version of > the service and in its dependencies you can either use a default > version, the same as the module, or a specific one. > > This way you can deploy 2 versions of the same service and use them > concurrently to serve clients from different versions. > > Guy. > > > On Wed, 30 Mar 2005 15:54:52 +0200, Achim Huegen <[EMAIL PROTECTED]> wrote: > > What dependencies keep you from shutting down the old version of Service > > A? Is Service C a user of Service A or > > are your services called remotely (rmi, webservices etc.) ? > > > > Achim > > > > > > Guy Hacham wrote: > > > Hi, > > > > > > I'm a newbie to hivemind and currently I'm reviewing the feature set > > > looking > > > for a way to load 2 different versions of the same service into hivemind. > > > > > > My requirement here is to be able to load 2 or more versions of a service > > > into > > > the JVM so they can live together with peace. > > > > > > A use case for this requirements is as follows: > > > Service A was deployed with v4.0 of the system. > > > The system is upgraded to v4.1 but the server should support both > > > versions in > > > parallel, i.e. both v4.0 and v4.1. > > > Service A was changed in v4.1, (and to make it more complicated) > > > including its > > > services (methods) and its dependencies. > > > Service B was also changed but Service C was left the same. > > > To support both version we need 2 versions of Service A, 2 versions of > > > Service > > > B and only one version of Service C. > > > > > > Is there a way to support this scenario in Hivemind? > > > > > > I saw that there is a version attribute on the service element but I don't > > > seem to find any other reference to it and how hivemind handles it. > > > > > > Your help is appreciated. > > > > > > Thanks, > > > Guy. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
