Looking at running multiple Anthill Instances

"O'Hara, Patrick" <[email protected]> Fri, 25 Jul 2003 12:53:25 -0500
Newsgroups gmane.comp.java.anthill.devel
Message-ID <[email protected]>
This is a multi-part message in MIME format.

------_=_NextPart_001_01C352D5.A5748398
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C352D5.A5748398"


------_=_NextPart_002_01C352D5.A5748398
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Let me start out by explaining why we are interested in running multiple =
instances of Anthill.  We are a Software Development company.  We have a =
standard product that we customize for our clients.  The product must be =
build for a specific J2EE platform (i.e. WebSphere, WebLogic, etc).  =
This has been pretty workable until our latest iteration.  We have =
changed to a component based development model.  This means that we have =
a project for each release of each component (we have about 50 =
components many have two releases, some have 3).  We have a project for =
each release of our standard project (2 at this time).  Finally we have =
a project for each release of a customer specific implementation.  This =
is exagerated by the fact that most projects have two sets of build =
scripts (one produces a developer build and one produces a release =
build).  The result is not going to work under anthill.  We are =
currently using anthill to build just one of our customers and the =
project files and dependencies are becoming hard to maintain. =20

Our solution is to run two instances of anthill for each customer.  One =
instance would handle dev builds (nightly), the other would create =
release builds (as required).

One cannot currently run multiple instances of anthill.  The issue is in =
how properties are handled.  I would like to make two changes that will =
resolve this problem.  The first change is to have the =
AnthillAdminServlet check it's initialization parameters before looking =
for the property file.  If the ANTHILL_ROOT_DIR_KEY has been specified, =
then this servlet will use that value.  If it has not been specified =
then the value from the proeprty file would be used.

The next change would be to store the properties statically in the =
Anthill class.  The issue with storing the properties in the System =
properties is that all instances of anthill within the VM must have the =
same property values.  There are 11 spots in code that would need to =
change to accomplish this.

The one issue I see with this solution is that the Pagelet work =
directory is also stored in the System properties.  Would this cause a =
problem for multiple instances of the app?

Finally, is there a different approach that you can suggest to solve our =
issue.

Thanks in advance for the time that you spend on this.




Patrick O'Hara
Developer
Riverwood Solutions, Inc.
V262-408-3849
F262-408-3840
N17 W24222 Riverwood Dr.
Suite 330
Waukesha, WI 53188-1162
 <<O'Hara, Patrick.vcf>>=20

------_=_NextPart_002_01C352D5.A5748398
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6396.0">
<TITLE>Looking at running multiple Anthill Instances</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Let me start out by explaining why we =
are interested in running multiple instances of Anthill.&nbsp; We are a =
Software Development company.&nbsp; We have a standard product that we =
customize for our clients.&nbsp; The product must be build for a =
specific J2EE platform (i.e. WebSphere, WebLogic, etc).&nbsp; This has =
been pretty workable until our latest iteration.&nbsp; We have changed =
to a component based development model.&nbsp; This means that we have a =
project for each release of each component (we have about 50 components =
many have two releases, some have 3).&nbsp; We have a project for each =
release of our standard project (2 at this time).&nbsp; Finally we have =
a project for each release of a customer specific implementation.&nbsp; =
This is exagerated by the fact that most projects have two sets of build =
scripts (one produces a developer build and one produces a release =
build).&nbsp; The result is not going to work under anthill.&nbsp; We =
are currently using anthill to build just one of our customers and the =
project files and dependencies are becoming hard to maintain.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Our solution is to run two instances of =
anthill for each customer.&nbsp; One instance would handle dev builds =
(nightly), the other would create release builds (as =
required).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">One cannot currently run multiple =
instances of anthill.&nbsp; The issue is in how properties are =
handled.&nbsp; I would like to make two changes that will resolve this =
problem.&nbsp; The first change is to have the AnthillAdminServlet check =
it's initialization parameters before looking for the property =
file.&nbsp; If the ANTHILL_ROOT_DIR_KEY has been specified, then this =
servlet will use that value.&nbsp; If it has not been specified then the =
value from the proeprty file would be used.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The next change would be to store the =
properties statically in the Anthill class.&nbsp; The issue with storing =
the properties in the System properties is that all instances of anthill =
within the VM must have the same property values.&nbsp; There are 11 =
spots in code that would need to change to accomplish this.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The one issue I see with this solution =
is that the Pagelet work directory is also stored in the System =
properties.&nbsp; Would this cause a problem for multiple instances of =
the app?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Finally, is there a different approach =
that you can suggest to solve our issue.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks in advance for the time that you =
spend on this.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Patrick O'Hara</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Developer</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Riverwood Solutions, Inc.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">V262-408-3849</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">F262-408-3840</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">N17 W24222 Riverwood Dr.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Suite 330</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Waukesha, WI 53188-1162</FONT>

<BR><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> &lt;&lt;O'Hara, =
Patrick.vcf&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C352D5.A5748398--

------_=_NextPart_001_01C352D5.A5748398
Content-Type: text/x-vcard;
	name="O'Hara, Patrick.vcf"
Content-Transfer-Encoding: base64
Content-Description: O'Hara, Patrick.vcf
Content-Disposition: attachment;
	filename="O'Hara, Patrick.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOk8nSGFyYTtQYXRyaWNrDQpGTjpPJ0hhcmEsIFBh
dHJpY2sNClRJVExFOkFwcGwgQXJjaA0KVEVMO1dPUks7Vk9JQ0U6KDI2Mik0MDgtMzg0OQ0KQURS
O1dPUks6O1dhdWtlc2hhLCBXSQ0KTEFCRUw7V09SSzpXYXVrZXNoYSwgV0kNCkVNQUlMO1BSRUY7
SU5URVJORVQ6cGF0cmljay5vaGFyYUByd3NvbC5jb20NClJFVjoyMDAzMDcwN1QxODMzMDBaDQpF
TkQ6VkNBUkQNCg==

------_=_NextPart_001_01C352D5.A5748398--