Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=bYft0XC0xXKcIa2IxlcIYWjro2FfKTZPZuNAvI2npQkw9p6mP9qcWXpheH2lizpA+5No39JKP+FtBj0ZuDT+DrfbS6NlXnTbyIqike8BaR9I6Muvrp6Kk1Zu7gR3lT9CrDuRIUr141H3ByA/pOpci3GVsSDeuDwtnQQC1zlg4OE=
  ;
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <435D0F55.5060409@savoirtech.com>
References: <435BEDB5.5070008@apache.org> <435C069E.4000503@gmail.com>
 <435C07E7.1030301@savoirtech.com>
 <5070D7E3-FF8B-4430-946F-873300CA6376@apache.org>
 <435D0F55.5060409@savoirtech.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <1b7a199291d229f4c0fc477ba907044a@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: The autodeploy feature in Geronimo
Date: Mon, 24 Oct 2005 09:58:26 -0700
To: dev@geronimo.apache.org


On Oct 24, 2005, at 9:44 AM, Jeff Genender wrote:

>
>
> Geir Magnusson Jr. wrote:
>> On Oct 23, 2005, at 6:00 PM, Jeff Genender wrote:
>>>
>>>
>>> Sachin Patel wrote:
>>>
>>>> Jacek Laskowski wrote:
>>>>  Am I right that the simplest solution is to develop a GBean that
>>>>
>>>>> would monitor a directory and hand over a deployable to a deployer?
>>>>>
>>>> This was my thinking as well.  The directory would listen for  
>>>> adds, modifications, and deletions.
>>>>
>>>
>>> I think this may be somewhat confusing.  I think when dropping in  
>>> the directory, it should should deploy...then be immediately  
>>> removed from the directory.
>> Eeek.  I think you'd want it to remain - helps you figure out what  
>> exactly has been deployed.  IOW you can always look in the dir to see 
>>  what is supposedly running...
>
> Not necessarily...I think keeping the config store aligned with what 
> is in this directory will cause more headaches than not.  What if the 
> deployment fails?  Then what you have in config store will not match 
> this directory.  This is the problem in having 2 deployment areas.  I 
> really think this needs to be thought through.

Well, directory scanning hot deployment is a really bad idea and 
suffers from innumerable problems of this sort and basically cannot be 
made to work.   I think we should implement something compatible with 
other implementations of this bad idea and tell people not to use it.  
This means not altering stuff in the hot deploy directory ourselves but 
attempting to monitor it.  The other major problem is that it is 
completely incompatible with j2ee 1.4/jsr-88 separation of plans and 
applications.  I think we should restrict hot deploy to deploying 
archaic applications with plans inside the application.

Just MNSHO :-)

thanks
david jencks

>
>> geir
>>> IMHO, this dir should be for hot deploy only.  Let the deployer  
>>> decide if it should be updated or added.  I think the deletions  
>>> should not be done through this dir.  We should use the normal  
>>> undeploy capabilities of the deployer.
>>>
>>>
>>>>>
>>>>> Jacek
>>>>>
>>>
>