Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Aaron Mulder <am...@alumni.princeton.edu>]

On Thu, 4 Nov 2004 scm@geronimo.apache.org wrote:
>  Would be nice to have "dump EAR here, it gets (re)deployed" directory
>  
> +[jboynes] I really, really don't like this option. With the right
> plugins to Ant/Maven (which I think +most projects would be using) it
> should not +be any harder to distribute an application to the server
> than it is to copy it into a directory. +By using a command the
> developers/admin can see if the operation worked without scanning the
> server +logs for errors. It also avoids all the problems with the
> scanner hitting partially copied files, +race conditions between seeing
> the module and the plan, being able to revert if it failed, and so
> forth. +

	For what it's worth, I think you're arguing for correctness over 
convenience.  While that's nice in admin tools, I'm not sure it's really a 
win for development tools, and certainly not for initially attempting to 
attract new developers.

	For what it's worth, I can't recall having a problem with Tomcat,
JBoss or WebLogic where it processed a partially copied file or had a race
condition or was unable to revert or it was unclear to me whether the
application was successfully deployed (either you get big stack traces or
you don't).  So I think we can solve those problems.

	More importantly, the first time any J2EE developer sits down
with a new server, I bet they try to deploy some app they have sitting
around, and I bet they try to do it by dumping it in the deploy directory.  
Now we can teach them to use a tool instead, but I think in rejecting a
hot deploy directory you're introducing a hurdle to adoption (must consult
doucmentation and learn tool syntax and set up tool execution environment)
because you don't like the standard process.

	But, all that said, I hope to make the deployment tool convenient 
enough that it's not a very big hurdle.

Aaron

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Dain Sundstrom <ds...@gluecode.com>]

On Nov 4, 2004, at 12:52 PM, Jeremy Boynes wrote:

> Aaron Mulder wrote:
>> 	For what it's worth, I can't recall having a problem with Tomcat,
>> JBoss or WebLogic where it processed a partially copied file or had a 
>> race
>> condition or was unable to revert or it was unclear to me whether the
>> application was successfully deployed (either you get big stack 
>> traces or
>> you don't).  So I think we can solve those problems.
>
> I have seen that many times. The obvious use case is when you are 
> doing testing where you end up doing something like:
>
>   copy file to directory
>   run tests
>
> and the app has not finished deploying yet. So then you add a couple 
> of "sleep for a bit" but when you are running a couple hundred tests 
> that gets to be boring.

So... people do all sorts of stupid stuff, and we can't stop them.  I 
don't think we should restrict a feature just because some people use 
is incorrectly.

>> 	More importantly, the first time any J2EE developer sits down
>> with a new server, I bet they try to deploy some app they have sitting
>> around, and I bet they try to do it by dumping it in the deploy 
>> directory.  Now we can teach them to use a tool instead, but I think 
>> in rejecting a
>> hot deploy directory you're introducing a hurdle to adoption (must 
>> consult
>> doucmentation and learn tool syntax and set up tool execution 
>> environment)
>> because you don't like the standard process.
>
> <cheap-shot>"standard process" - wouldn't that be JSR-88?</cheap-shot>
>
> There's nothing to stop anyone doing this - just write a GBean that 
> acts as a directory scanner and invokes the online deployer. If they 
> wanted to be fancy, they could have ones that scanned websites using 
> WebDAV or offered some basic security.

You lost me... you seem to be arguing against adding this feature, but 
then you say that "there's nothing to stop anyone doing this".  So it 
is possible, but you don't want Geronimo to provide this?

-dain

Re: [Apache Geronimo Wiki] Updated: WishList/M3

[Jeremy Boynes <jb...@gluecode.com>]

Aaron Mulder wrote:
> 
> 	For what it's worth, I can't recall having a problem with Tomcat,
> JBoss or WebLogic where it processed a partially copied file or had a race
> condition or was unable to revert or it was unclear to me whether the
> application was successfully deployed (either you get big stack traces or
> you don't).  So I think we can solve those problems.
> 

I have seen that many times. The obvious use case is when you are doing 
testing where you end up doing something like:

   copy file to directory
   run tests

and the app has not finished deploying yet. So then you add a couple of 
"sleep for a bit" but when you are running a couple hundred tests that 
gets to be boring.

> 	More importantly, the first time any J2EE developer sits down
> with a new server, I bet they try to deploy some app they have sitting
> around, and I bet they try to do it by dumping it in the deploy directory.  
> Now we can teach them to use a tool instead, but I think in rejecting a
> hot deploy directory you're introducing a hurdle to adoption (must consult
> doucmentation and learn tool syntax and set up tool execution environment)
> because you don't like the standard process.
> 

<cheap-shot>"standard process" - wouldn't that be JSR-88?</cheap-shot>

There's nothing to stop anyone doing this - just write a GBean that acts 
as a directory scanner and invokes the online deployer. If they wanted 
to be fancy, they could have ones that scanned websites using WebDAV or 
offered some basic security.

I think having good tools is useful and I appreciate the work you are 
doing on the deployer. I'm not trying to be difficult or over "correct", 
just trying to ensure that we don't repeat the mistakes of the past, at 
least without thinking about them. Reminds me of the post on Slashdot 
yesterday about problems with Virtual Worlds.

http://www.gamasutra.com/features/20041103/bartle_pfv.htm

--
Jeremy