You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Thiago H. de Paula Figueiredo" <th...@gmail.com> on 2009/09/24 15:39:27 UTC

A survey about redeployment time in the Java EE world

http://www.zeroturnaround.com/blog/java-ee-container-redeploy-restart-turnaround-report/

It makes one very compelling reason to use Tapestry 5: live class  
reloading avoids almost most redeploys related to the web tier. :)

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Sep 2009 10:56:17 -0300, Ilya Obshadko  
<il...@gmail.com> escreveu:

> I'm totally OK with Jetty, but it demonstrates pretty the same behavior  
> if running inside Eclipse IDE server adaptor. Probably I'm missing  
> something
> obvious?

I run Jetty in embedded mode: add it to the classpath (using Maven, with  
the test scope) and use this snippet to run it:

Server server = new Server(8080);

WebAppContext webapp = new WebAppContext();

webapp.setParentLoaderPriority(true);
webapp.setContextPath("/");
webapp.setWar("src/main/webapp"); // or any other exploded root webapp  
folder
webapp.setDefaultsDescriptor("src/main/webapp/WEB-INF/webdefault.xml"); //  
only needed in Windows because of the file locking issue
server.setHandler(webapp);

try {
	server.start();
	server.join();
}
catch (Exception e) {
	e.printStackTrace();
}

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by "Juan E. Maya" <ma...@gmail.com>.
llya i use Sysdeo http://www.eclipsetotale.com/tomcatPlugin.html for
tomcat inside Eclipse.
It allows to detect changes in the java fiese without the need of a
context reload. The changes detected are limited but it's a pretty
boost for my productivity.

On Thu, Sep 24, 2009 at 3:56 PM, Ilya Obshadko <il...@gmail.com> wrote:
>>
>> Live class reloading is a great feature.
>>> But I couldn't figure out yet how one should configure, for example,
>>> Tomcat 6 in development environment to avoid redeployments after each and
>>> every
>>> change in the code. Are there any solutions?
>>>
>>
>> Use Jetty instead: faster, simpler, more modular. :) Take a look at the
>> reloadable attribute in the Context tag. Try making your context not
>> reloadable.
>>
>
> I'm totally OK with Jetty, but it demonstrates pretty the same behavior if
> running inside Eclipse IDE server adaptor. Probably I'm missing something
> obvious?
>
>
> --
> Ilya Obshadko
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by Ilya Obshadko <il...@gmail.com>.
>
> Live class reloading is a great feature.
>> But I couldn't figure out yet how one should configure, for example,
>> Tomcat 6 in development environment to avoid redeployments after each and
>> every
>> change in the code. Are there any solutions?
>>
>
> Use Jetty instead: faster, simpler, more modular. :) Take a look at the
> reloadable attribute in the Context tag. Try making your context not
> reloadable.
>

I'm totally OK with Jetty, but it demonstrates pretty the same behavior if
running inside Eclipse IDE server adaptor. Probably I'm missing something
obvious?


-- 
Ilya Obshadko

Re: A survey about redeployment time in the Java EE world

Posted by Kalle Korhonen <ka...@gmail.com>.
Yes, it works fine. I'm using all the latest stuff including m2eclipse
dev version and life's good :)

Kalle


On Thu, Sep 24, 2009 at 10:25 AM, Ilya Obshadko <il...@gmail.com> wrote:
>>
>> That's simply not true. I love Jetty and it's very well implemented
>> but the core Tomcat runs and starts up just as fast as Jetty. I bet
>> Ilya's issue is he tries to use Eclipse own JEE container support,
>> which is using the traditional concept - copy files, redeploy
>> application on change. Use run-jetty-run or sysdeo's Tomcat plugin
>> with Eclipse (or http://merve.sourceforge.net/ for Tomcat similar
>> run-jetty-run but the development stalled). I prefer sysdeo's because
>> it has much finer control of the application classpath.
>>
>
> Thank you, I think this is it. Do you know if sysdeo's plugin works with
> Eclipse Galileo?
>
>
>> Note that while I use Tomcat for development my designers happily run
>> mvn jetty:run and edit the live templates without ever really having
>> to understand and worry about the underlying machinery.
>>
>>
>
>
> --
> Ilya Obshadko
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by Ilya Obshadko <il...@gmail.com>.
>
> That's simply not true. I love Jetty and it's very well implemented
> but the core Tomcat runs and starts up just as fast as Jetty. I bet
> Ilya's issue is he tries to use Eclipse own JEE container support,
> which is using the traditional concept - copy files, redeploy
> application on change. Use run-jetty-run or sysdeo's Tomcat plugin
> with Eclipse (or http://merve.sourceforge.net/ for Tomcat similar
> run-jetty-run but the development stalled). I prefer sysdeo's because
> it has much finer control of the application classpath.
>

Thank you, I think this is it. Do you know if sysdeo's plugin works with
Eclipse Galileo?


> Note that while I use Tomcat for development my designers happily run
> mvn jetty:run and edit the live templates without ever really having
> to understand and worry about the underlying machinery.
>
>


-- 
Ilya Obshadko

Re: A survey about redeployment time in the Java EE world

Posted by Kalle Korhonen <ka...@gmail.com>.
On Thu, Sep 24, 2009 at 6:49 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Thu, 24 Sep 2009 10:46:31 -0300, Ilya Obshadko <il...@gmail.com>
> escreveu:
>> Live class reloading is a great feature.
>> But I couldn't figure out yet how one should configure, for example,
>> Tomcat 6 in development environment to avoid redeployments after each and
>> every
>> change in the code. Are there any solutions?
> Use Jetty instead: faster, simpler, more modular. :) Take a look at the
> reloadable attribute in the Context tag. Try making your context not
> reloadable.

That's simply not true. I love Jetty and it's very well implemented
but the core Tomcat runs and starts up just as fast as Jetty. I bet
Ilya's issue is he tries to use Eclipse own JEE container support,
which is using the traditional concept - copy files, redeploy
application on change. Use run-jetty-run or sysdeo's Tomcat plugin
with Eclipse (or http://merve.sourceforge.net/ for Tomcat similar
run-jetty-run but the development stalled). I prefer sysdeo's because
it has much finer control of the application classpath.

Note that while I use Tomcat for development my designers happily run
mvn jetty:run and edit the live templates without ever really having
to understand and worry about the underlying machinery.

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Sep 2009 10:46:31 -0300, Ilya Obshadko  
<il...@gmail.com> escreveu:

> Live class reloading is a great feature.
> But I couldn't figure out yet how one should configure, for example,  
> Tomcat 6 in development environment to avoid redeployments after each  
> and every
> change in the code. Are there any solutions?

Use Jetty instead: faster, simpler, more modular. :) Take a look at the  
reloadable attribute in the Context tag. Try making your context not  
reloadable.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by Ilya Obshadko <il...@gmail.com>.
Live class reloading is a great feature.
But I couldn't figure out yet how one should configure, for example, Tomcat
6 in development environment to avoid redeployments after each and every
change in the code. Are there any solutions? I use Eclipse, if it makes
sense.

On Thu, Sep 24, 2009 at 5:39 PM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:

>
> http://www.zeroturnaround.com/blog/java-ee-container-redeploy-restart-turnaround-report/
>
> It makes one very compelling reason to use Tapestry 5: live class reloading
> avoids almost most redeploys related to the web tier. :)
>
>

-- 
Ilya Obshadko

Re: A survey about redeployment time in the Java EE world

Posted by Daniel Jue <te...@gmail.com>.
> And that is for development, for deployment I have a bigger problem because
> it is under Tomcat 6 which is behind AJP fronted by MS IIS.
> And if the application is packaged from maven as a WAR, then all the classes
> are inside packed in a JAR, which Tomcat extracts in a temporary place and
> sometimes is not refreshed even if you bring a newer WAR.
> So I have to stop the application, clean the WAR, clean the extracted
> folders, clean the temp and work folders ...
>
>

^^^^^
I have exactly this scenario and it's a PITFA.  Another option is to
use eclipse's "Export to War" feature if you are using WTP.  It
doesn't bundle your classes into a jar first.  There's probably also a
maven option to leave your classes un-jarred, if that saves you time.
(I don't know for sure)

In any case, class reloading and war redeploys have always been harder
than they should be, especially if you're trying to get the tomcat
manager to stop the web app and redeploy.  I have a batch file to
delete the old war and exploded war and copy over the new one.  Then I
start up the service again and it explodes my war.

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by ningdh <ni...@gmail.com>.
I love  mvnDebug with jetty:run, so not only the web tier, all the class changes are reloaded perfectly, except new a method and new a class.

DH
----- Original Message ----- 
From: "Thiago H. de Paula Figueiredo" <th...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Thursday, September 24, 2009 10:37 PM
Subject: Re: A survey about redeployment time in the Java EE world


> Em Thu, 24 Sep 2009 11:28:09 -0300, Vangel V. Ajanovski <aj...@ii.edu.mk>  
> escreveu:
> 
>> Hi, I would really like to have live class reloading but it doesn't work
>> for all classes because I use the pattern with Spring and Hibernate
>> described at:
>> http://wiki.apache.org/tapestry/Tapstry5First_project_with_Tapestry5%2C_Spring_and_Hibernate
>> So the changes in the DAO or Manager classes are not reflected without
>> reloading the application.
> 
> Tapestry class reloading only works for the classes it controls: pages,  
> components and mixins. But it is a huge productivity boost anyway. :)
> 
>> And that is for development, for deployment I have a bigger problem
>> because it is under Tomcat 6 which is behind AJP fronted by MS IIS.
>> And if the application is packaged from maven as a WAR, then all the
>> classes are inside packed in a JAR, which Tomcat extracts in a temporary
>> place and sometimes is not refreshed even if you bring a newer WAR.
>> So I have to stop the application, clean the WAR, clean the extracted
>> folders, clean the temp and work folders ...
> 
> But the live class reloading can still be used in development, while not  
> being used in production.
> 
> -- 
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
>

Re: A survey about redeployment time in the Java EE world

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Sep 2009 11:28:09 -0300, Vangel V. Ajanovski <aj...@ii.edu.mk>  
escreveu:

> Hi, I would really like to have live class reloading but it doesn't work
> for all classes because I use the pattern with Spring and Hibernate
> described at:
> http://wiki.apache.org/tapestry/Tapstry5First_project_with_Tapestry5%2C_Spring_and_Hibernate
> So the changes in the DAO or Manager classes are not reflected without
> reloading the application.

Tapestry class reloading only works for the classes it controls: pages,  
components and mixins. But it is a huge productivity boost anyway. :)

> And that is for development, for deployment I have a bigger problem
> because it is under Tomcat 6 which is behind AJP fronted by MS IIS.
> And if the application is packaged from maven as a WAR, then all the
> classes are inside packed in a JAR, which Tomcat extracts in a temporary
> place and sometimes is not refreshed even if you bring a newer WAR.
> So I have to stop the application, clean the WAR, clean the extracted
> folders, clean the temp and work folders ...

But the live class reloading can still be used in development, while not  
being used in production.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: A survey about redeployment time in the Java EE world

Posted by "Vangel V. Ajanovski" <aj...@ii.edu.mk>.
On 24.09.2009 15:39, Thiago H. de Paula Figueiredo wrote:
> http://www.zeroturnaround.com/blog/java-ee-container-redeploy-restart-turnaround-report/ 
>
>
> It makes one very compelling reason to use Tapestry 5: live class 
> reloading avoids almost most redeploys related to the web tier. :)
>
Hi, I would really like to have live class reloading but it doesn't work 
for all classes because I use the pattern with Spring and Hibernate 
described at:
http://wiki.apache.org/tapestry/Tapstry5First_project_with_Tapestry5%2C_Spring_and_Hibernate

So the changes in the DAO or Manager classes are not reflected without 
reloading the application.

And that is for development, for deployment I have a bigger problem 
because it is under Tomcat 6 which is behind AJP fronted by MS IIS.
And if the application is packaged from maven as a WAR, then all the 
classes are inside packed in a JAR, which Tomcat extracts in a temporary 
place and sometimes is not refreshed even if you bring a newer WAR.
So I have to stop the application, clean the WAR, clean the extracted 
folders, clean the temp and work folders ...