Makes sense.  Thanks for everyones responses.

I do have one further question.

If I have an exploded WAR format with a META-INF directory will the system pick out the hivemodule.xml file from that directory even though it's not JARed up?

Regards,

Glen

James Carman wrote:
So, put all of the common stuff into one jar file.  Then, put all the
customer-specific stuff into the customer-specific jar files.  Also, nothing
says you have to have any classes in the separate jars!  If both
applications use the same classes, configured differently (such as different
database connections, etc.), you can just the customer-specific
hivemodule.xml files in the jar files!  The key, here, is to put all of your
service/configuration point declarations (and even the static contributions)
your application uses into the common jar file.  Then, in the
customer-specific jar files, you put the contributions to those
service/configuration points.  Does that make sense?

-----Original Message-----
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 24, 2004 5:58 PM
To: [email protected]
Subject: Re: Configuration Question


I thought of that but the thing is most of the app is identical between 
the two versions.  It seems overkill to create seperate jars for the two 
customers.  I'm also trying to introduce hivemind incrementally into the 
project.  The current way of configuring things is to use property files 
that sit outside of the main webapp (on the classpath).  Can 
hivemodule.xml be read from any location other than WEB-INF?

Regards,

Glen

Hensley, Richard wrote:

  
Assuming you are running two different instances of the application. I
    
would
  
make an interface jar, customer a and customer b jar. The interface jar
would contain the service-point declarations, and the customer jars would
contains the implementation declarations.

Kind of like this

interfaces.jar!META-INF/hivemodule.xml

   <service-point id="ObjectFactory"
   interface="my.package.ObjectFactory">
   </service-point>

customera.jar!META-INF/hivemodule.xml

   <implementation service-id="my.package.ObjectFactory">
       <invoke-factory model="singleton"
service-id="hivemind.BuilderFactory">
           <construct
           class="my.package.customera.ObjectFactoryImpl">
           </construct>
       </invoke-factory>
   </implementation>

customerb.jar!META-INF/hivemodule.xml

   <implementation service-id="my.package.ObjectFactory">
       <invoke-factory model="singleton"
service-id="hivemind.BuilderFactory">
           <construct
           class="my.package.customerb.ObjectFactoryImpl">
           </construct>
       </invoke-factory>
   </implementation>

Depending on which customer you are configuring, you throw the correct jar
of implementations in the class path and away you go. We use it quite
sucessfully.

Richard

-----Original Message-----
From: Glen Stampoultzis [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 24, 2004 2:34 PM
To: [email protected]
Subject: Configuration Question

I have the following situation.

We have one application code base that is configured differently for two 
(or more in the future) different customers.

Say I have interface Foo and two implementations that implement that 
interface - one for each customer.  What's the best way of configuring 
these sorts of differences?

Is there any way of saying in hivemind that I prefer one service 
implementation over another in HM?

Regards,

Glen Stampoultzis


    

Reply via email to