I was thinking along the lines of:
{explodedwar}/META-INF but if it needs to be in {explodedwar}/WEB-INF/classes/META-INF I can live with that.
Thanks,
Glen
James Carman wrote:
Not by default. The “default” registry picks up all META-INF/hivemodule.xml files on the classpath. Now, if you have a file in your war named WEB-INF/classes/META-INF/hivemodule.xml, then it WILL pick that up. Is that what you meant?
-----Original Message----- *From:* Glen Stampoultzis [mailto:[EMAIL PROTECTED] *Sent:* Thursday, November 25, 2004 5:24 PM *To:* [email protected] *Subject:* Re: Configuration Question
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] <mailto:[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] <mailto:[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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
