Re: Live reload in production?

2011-12-13 Thread trsvax
Personally I like the latest project layout with AppModule, DevelopmentModule
etc. I would think the default should be off and the value overridden in the
DevelopmentModule to on. 

I also think -Dtapestry.execution-mode=development should be documented on
the Getting Started page.

Finally I think the sample app should have the values and the documentation
for these kinds of settings on the Index page. The easiest way to do that
would be to create a DisplayConfig component and put it in the sample
Index.tml. 

I think all the defaults should be set for production but it should be
obvious what the recommendations for development are and how to change them.

--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Live-reload-in-production-tp4313825p5072072.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

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



Re: Live reload in production?

2011-12-13 Thread Bård Magnus Kvalheim


 For 5.4, we can introduce yet another level of indirection that
 indicates that live reloading is desired in production mode; perhaps
 an enum to define what gets reloaded.  Is there a JIRA issue yet?


Thanks Howard - that sounds great.
Created issue: https://issues.apache.org/jira/browse/TAP5-1789




 
  Not a showstopper - just want to know what my options are...
 
  thanks
  Magnus
 
  On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski a...@ii.edu.mk
 wrote:
 
  On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
   On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com
 wrote:
  
   Disabled, so you automatically get better performance. I don't think
 you
   should have to tweak Tapestry options to get better performance.
  
   Good point. But a similar argument can be used: enabled, so you get a
   faster development environment without tweaking options. My gosh,
   these decisions are hard. :)
 
  I would like to know what is truly the nature of the problem with live
  reload (besides possibility to get the application in an inconsistent
  state of which every developer is aware).
 
  What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
  it raising exponentially on the number of all pages? Memory use? Permgen
  filling too quickly?
  Is it really only about performance, or does it have other problems too?
  What other (under the hood) differences do production and development
  modes have?
 
  Howard started this discussion without really explaining the reasons for
  not having it at all or even the reasons for not having an option that
  would enable it in production.
 
 



 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




Re: Live reload in production?

2011-12-12 Thread Magnus Kvalheim
Any update on this?

We're about to upgrade to T5.3, but conveniently use template reload in
production on rare occasions.
From prior discussions a symbol would/could be introduced, but don't seem
like it has..?

Any way of supporting reload(without production=false)? Or is the dynamic
component the way to go?

Not a showstopper - just want to know what my options are...

thanks
Magnus

On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski a...@ii.edu.mk wrote:

 On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
  On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com wrote:
 
  Disabled, so you automatically get better performance. I don't think you
  should have to tweak Tapestry options to get better performance.
 
  Good point. But a similar argument can be used: enabled, so you get a
  faster development environment without tweaking options. My gosh,
  these decisions are hard. :)

 I would like to know what is truly the nature of the problem with live
 reload (besides possibility to get the application in an inconsistent
 state of which every developer is aware).

 What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
 it raising exponentially on the number of all pages? Memory use? Permgen
 filling too quickly?
 Is it really only about performance, or does it have other problems too?
 What other (under the hood) differences do production and development
 modes have?

 Howard started this discussion without really explaining the reasons for
 not having it at all or even the reasons for not having an option that
 would enable it in production.




Re: Live reload in production?

2011-12-12 Thread Howard Lewis Ship
On Mon, Dec 12, 2011 at 1:20 PM, Magnus Kvalheim mag...@kvalheim.dk wrote:
 Any update on this?

 We're about to upgrade to T5.3, but conveniently use template reload in
 production on rare occasions.
 From prior discussions a symbol would/could be introduced, but don't seem
 like it has..?

 Any way of supporting reload(without production=false)? Or is the dynamic
 component the way to go?

No real options for 5.3; the code simply is not present. I guess you
could run in development mode, and change the handling of the
exception report (if you are not always doing so). You may experience
some minor memory leak issues, as in development mode, component
fields with FieldConduits will write values into fields as the
FieldConduit's get() or set() method is invoked ... basically, this
means that per-thread state can get into a shared page instance and
will not be cleared (but will be rapidly overwritten by other
threads).  It doesn't affect class behavior, the fields are never
read, just written to, except in terms of dangling references to
otherwise unused objects.

For 5.4, we can introduce yet another level of indirection that
indicates that live reloading is desired in production mode; perhaps
an enum to define what gets reloaded.  Is there a JIRA issue yet?


 Not a showstopper - just want to know what my options are...

 thanks
 Magnus

 On Fri, Apr 22, 2011 at 9:01 PM, Vangel V. Ajanovski a...@ii.edu.mk wrote:

 On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
  On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com wrote:
 
  Disabled, so you automatically get better performance. I don't think you
  should have to tweak Tapestry options to get better performance.
 
  Good point. But a similar argument can be used: enabled, so you get a
  faster development environment without tweaking options. My gosh,
  these decisions are hard. :)

 I would like to know what is truly the nature of the problem with live
 reload (besides possibility to get the application in an inconsistent
 state of which every developer is aware).

 What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
 it raising exponentially on the number of all pages? Memory use? Permgen
 filling too quickly?
 Is it really only about performance, or does it have other problems too?
 What other (under the hood) differences do production and development
 modes have?

 Howard started this discussion without really explaining the reasons for
 not having it at all or even the reasons for not having an option that
 would enable it in production.





-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-22 Thread Vangel V. Ajanovski
On 20.04.2011 21:03, Thiago H. de Paula Figueiredo wrote:
 On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com wrote:

 Disabled, so you automatically get better performance. I don't think you
 should have to tweak Tapestry options to get better performance.

 Good point. But a similar argument can be used: enabled, so you get a
 faster development environment without tweaking options. My gosh,
 these decisions are hard. :)

I would like to know what is truly the nature of the problem with live
reload (besides possibility to get the application in an inconsistent
state of which every developer is aware).

What is the range of the performance penalty? 0.01%, 1%, 5%, 20%, ... is
it raising exponentially on the number of all pages? Memory use? Permgen
filling too quickly?
Is it really only about performance, or does it have other problems too?
What other (under the hood) differences do production and development
modes have?

Howard started this discussion without really explaining the reasons for
not having it at all or even the reasons for not having an option that
would enable it in production.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Live reload in production?

2011-04-21 Thread Michal Gruca
my $0.02. If it was enabled till today then we should leave it that way. 
In documentation there should be note that it is possible to speed up
significantly application by doing something and with cost of no live class
reloads in production.


Regards,
Michal

--
View this message in context: 
http://tapestry-users.832.n2.nabble.com/Live-reload-in-production-tp6288037p6293772.html
Sent from the Tapestry Users mailing list archive at Nabble.com.

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



Re: Live reload in production?

2011-04-21 Thread Mark
On Wed, Apr 20, 2011 at 4:07 PM, Howard Lewis Ship hls...@gmail.com wrote:

 That's my intention.  Live class reloading would be disabled in
 production, and enable in development.


I think that is reasonable, but I think it should be treated similar to
tapestry.secure-enabled.  By default it is off in development and on in
production, but you can override it to turn it on if you need to use
security in development mode. That way the majority of users can benefit
from sensible defaults while allowing the flexibility for people who need
it.

I think this type of approach is ideal for handling the paradox of choice
issue--particularly in programming frameworks.  It keeps things simple for
the majority of users, but flexible for people whose needs are a bit
different.

Mark


Re: Live reload in production?

2011-04-20 Thread antalk
We have 2 live webapps running and we do not use or rely on live class
reloading. Even more, i dont even have access or allowance to change a
production website at runtime. Our policy is that everything needs to be
tested and accepted before even going to production.

If something is wrong or needs to be changed i have to create a new version
with the changes and this needs to be re-deployed.

If this is not possible we shutdown the app instead of changing a production
webapp.



--
View this message in context: 
http://tapestry.1045711.n5.nabble.com/Live-reload-in-production-tp4313825p4315096.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

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



Re: Live reload in production?

2011-04-20 Thread Vangel V. Ajanovski
On 19.04.2011 19:11, Howard Lewis Ship wrote:
 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.
Live reloading was a life saver for me in production.

We started with a term enrollment application that supports the whole
workflow of a student choosing elective courses and submitting his
choice and getting approval by the academic adviser, and also automatic
inclusion of students in courses. We went in production with just 90% of
the use-cases covered with alpha quality code. While in production we
fixed bugs and developed the remaining 10%. So live reloading was very
helpful.

But this application is constantly growing and has become almost a whole
student information system with courses, enrollments, grades, exams,
class schedule, finances :) This constant growth and running in
production on alpha quality code means that there were and there will be
many many bugs. Since the problem is usually in the business logic, not
in the GUI itself, the introduction of live reloading of service classes
was in fact the most useful thing of all.

If you are in position to set it up so that one can choose whether he
needs live reloading of all class, just services, or not at all, (or
maybe package by package) this would be the best.




smime.p7s
Description: S/MIME Cryptographic Signature


Re: Live reload in production?

2011-04-20 Thread Vangel V. Ajanovski
On 20.04.2011 01:36, Howard Lewis Ship wrote:
 Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll
Ouch.
How about letting the community vote on this? I would hate to go back to
JSP or PHP.
 probably have to introduce a new symbol to allow this to be enabled in
 production. But I think the vast majority of deployments will not need
Yes, as soon as possible.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: Live reload in production?

2011-04-20 Thread Thiago H. de Paula Figueiredo
On Wed, 20 Apr 2011 06:26:12 -0300, Vangel V. Ajanovski a...@ii.edu.mk  
wrote:



On 20.04.2011 01:36, Howard Lewis Ship wrote:

Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll

Ouch.
How about letting the community vote on this? I would hate to go back to
JSP or PHP.


You can stick to 5.2.4 while 5.3 doesn't provide live class reloading in  
production. Or use 5.3 in non-production mode in production.



probably have to introduce a new symbol to allow this to be enabled in
production. But I think the vast majority of deployments will not need

Yes, as soon as possible.




--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com  
Ênfase em Java da Faculdade Pitágoras

http://www.arsmachina.com.br

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



Re: Live reload in production?

2011-04-20 Thread Adam Zimowski
probably have to introduce a new symbol to allow this to be enabled in
production. But I think the vast majority of deployments will not need

At the very least, can there be a patch that could be applied to 5.3
source on this ?

On Wed, Apr 20, 2011 at 7:56 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
 On Wed, 20 Apr 2011 06:26:12 -0300, Vangel V. Ajanovski a...@ii.edu.mk
 wrote:

 On 20.04.2011 01:36, Howard Lewis Ship wrote:

 Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll

 Ouch.
 How about letting the community vote on this? I would hate to go back to
 JSP or PHP.

 You can stick to 5.2.4 while 5.3 doesn't provide live class reloading in
 production. Or use 5.3 in non-production mode in production.

 probably have to introduce a new symbol to allow this to be enabled in
 production. But I think the vast majority of deployments will not need

 Yes, as soon as possible.



 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
 Coordenador e professor da Especialização em Engenharia de Software com
 Ênfase em Java da Faculdade Pitágoras
 http://www.arsmachina.com.br

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



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



Re: Live reload in production?

2011-04-20 Thread Massimo Lusetti
On Wed, Apr 20, 2011 at 1:36 AM, Howard Lewis Ship hls...@gmail.com wrote:

 On Tue, Apr 19, 2011 at 4:22 PM, Adam Zimowski zimowsk...@gmail.com wrote:
 Excuse me asking, but with class reloading disabled in production,
 template reloading still works, correct?

 My designer who mostly does TML's expects templates be reloadable in 
 production.


 Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll
 probably have to introduce a new symbol to allow this to be enabled in
 production. But I think the vast majority of deployments will not need
 this (and may like the increased throughput and lowered memory
 utilization).

I'm on the screwed side of the moon too.

I've never planned to use it in production but happened. We discovered
a bug in a decision-maker point of the app business and fortunately we
had the exploded jar so we simply swapped the bugged class with the
fixed one and all was solved and everyone happy. Quick fix is a big
win here.

After that even I've always kept that feature in mind when plan deploy...

Cheers
-- 
Massimo
http://meridio.blogspot.com

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



Re: Live reload in production?

2011-04-20 Thread Mark
 Does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?

  and what critical benefit does this offer?

I've used live class reloading on a production system a few times, but
it always felt wrong to me. :)

However, keep in mind that the ease of development means some people
are going to use Tapestry for things that normally would be handled by
a scripting language. In some of those situations live class reloading
in production may make sense.

I understand the problems with giving people too many options.
However it can be really tricky to decide what should be configurable
and what need to be fixed.  I wouldn't want to use a word processor
that only allowed me to type in Times Roman because that was the only
font the developers used and they didn't see any reason others would
need to use anything different.

It seems that the real advantage of having fewer options would be when
it lets you keep the code base simpler, but in this case it isn't like
you plan to remove the live class reloading capability.  It will still
be needed for development.

But personally it wouldn't hamper any of my current projects if it
were turned off in production.

Mark

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



Re: Live reload in production?

2011-04-20 Thread Thiago H. de Paula Figueiredo

On Wed, 20 Apr 2011 13:32:17 -0300, Mark mark-li...@xeric.net wrote:


I understand the problems with giving people too many options.
However it can be really tricky to decide what should be configurable
and what need to be fixed.  I wouldn't want to use a word processor
that only allowed me to type in Times Roman because that was the only
font the developers used and they didn't see any reason others would
need to use anything different.


Agreed. This is an option that is important for Tapestry users. What I  
think should be discussed is what's the best default value for it: enabled  
or disabled?


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Live reload in production?

2011-04-20 Thread Adam Zimowski
 What I think should be discussed is what's the best default value for it: 
 enabled or disabled?

That, to us makes no difference, as long as the option is there in 5.3 :-)

On Wed, Apr 20, 2011 at 12:11 PM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
 On Wed, 20 Apr 2011 13:32:17 -0300, Mark mark-li...@xeric.net wrote:

 I understand the problems with giving people too many options.
 However it can be really tricky to decide what should be configurable
 and what need to be fixed.  I wouldn't want to use a word processor
 that only allowed me to type in Times Roman because that was the only
 font the developers used and they didn't see any reason others would
 need to use anything different.

 Agreed. This is an option that is important for Tapestry users. What I think
 should be discussed is what's the best default value for it: enabled or
 disabled?

 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br

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



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



Re: Live reload in production?

2011-04-20 Thread LLTYK
Disabled, so you automatically get better performance. I don't think you
should have to tweak Tapestry options to get better performance.

--
View this message in context: 
http://tapestry-users.832.n2.nabble.com/Live-reload-in-production-tp6288037p6291747.html
Sent from the Tapestry Users mailing list archive at Nabble.com.

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



Re: Live reload in production?

2011-04-20 Thread Thiago H. de Paula Figueiredo

On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com wrote:


Disabled, so you automatically get better performance. I don't think you
should have to tweak Tapestry options to get better performance.


Good point. But a similar argument can be used: enabled, so you get a  
faster development environment without tweaking options. My gosh, these  
decisions are hard. :)


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Live reload in production?

2011-04-20 Thread Mark
 Good point. But a similar argument can be used: enabled, so you get a faster
 development environment without tweaking options. My gosh, these decisions
 are hard. :)

Couldn't it be enabled by default in development mode and disabled by
default in production mode? Isn't that how HTTPS and some other things
are handled?

Mark

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



Re: Live reload in production?

2011-04-20 Thread Kalle Korhonen
On Wed, Apr 20, 2011 at 10:03 PM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
 On Wed, 20 Apr 2011 15:21:10 -0300, LLTYK ll...@mailinator.com wrote:
 Disabled, so you automatically get better performance. I don't think you
 should have to tweak Tapestry options to get better performance.
 Good point. But a similar argument can be used: enabled, so you get a faster
 development environment without tweaking options. My gosh, these decisions
 are hard. :)

Everybody wants better performance but only certain group of users
want/need reloading in production. For the whole discussion -
personally I think live reloading is the wrong way to solve the
application upgrade / patching problem, you give up too much for the
benefit. I've been doing skinny wars, deploying dependent libs
separately and auto-reloading of the web app for a few years, to
achieve production deployment and updates in less than two seconds.
Together with Tomcat 7's parallel deployment, you get a nice zero
downtime environment.

Kalle


 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br

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



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



Re: Live reload in production?

2011-04-20 Thread Howard Lewis Ship
On Wed, Apr 20, 2011 at 12:37 PM, Mark mark-li...@xeric.net wrote:
 Good point. But a similar argument can be used: enabled, so you get a faster
 development environment without tweaking options. My gosh, these decisions
 are hard. :)

 Couldn't it be enabled by default in development mode and disabled by
 default in production mode? Isn't that how HTTPS and some other things
 are handled?


That's my intention.  Live class reloading would be disabled in
production, and enable in development.

 Mark

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





-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-20 Thread Nikla Ratinen


Hi,

In a busy live environment I would prefer disabled by default
but still doable programmatically for occasional critical patching.
This would allow reloading to be hooked for example to some
administrative web service and result in better atomicity if multiple
files need to be patched.

That said, I currently deploy entire app most of the times.

Cheers,
--Nikla


On 20.4.2011 22:43, Kalle Korhonen wrote:

On Wed, Apr 20, 2011 at 10:03 PM, Thiago H. de Paula Figueiredo
thiag...@gmail.com  wrote:

On Wed, 20 Apr 2011 15:21:10 -0300, LLTYKll...@mailinator.com  wrote:

Disabled, so you automatically get better performance. I don't think you
should have to tweak Tapestry options to get better performance.

Good point. But a similar argument can be used: enabled, so you get a faster
development environment without tweaking options. My gosh, these decisions
are hard. :)

Everybody wants better performance but only certain group of users
want/need reloading in production. For the whole discussion -
personally I think live reloading is the wrong way to solve the
application upgrade / patching problem, you give up too much for the
benefit. I've been doing skinny wars, deploying dependent libs
separately and auto-reloading of the web app for a few years, to
achieve production deployment and updates in less than two seconds.
Together with Tomcat 7's parallel deployment, you get a nice zero
downtime environment.

Kalle


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



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





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



Live reload in production?

2011-04-19 Thread Howard Lewis Ship
Out of curiosity ... does anyone out there rely on live class
(template, message catalog, whatever) reloading in their live,
production application?  Now, normally, I'd think not, because the
deployed app will be packaged in a WAR and the unit of redeployment is
the entire WAR ... but I suppose some people could be using the
exploded WAR format, which would allow classes and templates to be
updated while the application runs.

Live reloading is a feature that was originally intended for
development only; Tapestry 5.2 supports live reloading in the live
application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
see some improvements in throughput and a reduction in memory
utilization in production applications ... but it's not too late to
shift things so that 5.3 can support production reloading as well.
I'd prefer not to, however.

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-19 Thread Thiago H. de Paula Figueiredo

I'm not using 5.2 yet (sigh), but I do use exploded WARs in deployment.

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Live reload in production?

2011-04-19 Thread Howard Lewis Ship
On Tue, Apr 19, 2011 at 11:23 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
 On Tue, 19 Apr 2011 15:21:44 -0300, Howard Lewis Ship hls...@gmail.com
 wrote:

 On Tue, Apr 19, 2011 at 11:07 AM, Thiago H. de Paula Figueiredo
 thiag...@gmail.com wrote:

 I'm not using 5.2 yet (sigh), but I do use exploded WARs in deployment.

 Well then, you better add support for that back in, with a new symbol
 perhaps ;-}

 The ideal solution was to have a symbol for enabling the live class
 reloading . . . But I won't ask you that. :)

No, you are right about adding Yet Another Symbol.  However, I have a
philosophical problem with make every change subject to some
configuration: it basically abdicates responsibility of the framework
developers (us), forcing framework users to make critical decisions.
This came up in the excellent book The Paradox of Choice, which is
recommended reading. If you look at, for example, Mac/iPhone apps,
you'll see consistently that they have fewer options and less
configuration than equivalent Windows apps ... and people love them
more (I've just seen this with my wife, who starting using Pages after
years of Word).

Now this specific case is one that treads onto hallowed ground of
backwards compatibility, so it may be something where we introduce a
symbol, and mark it immediately as deprecated (I always introduce a
SymbolConstant static value, to provide documentation, and as a place
to hang @Deprecated), so that people have a release to get used to the
change.



 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br






 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
 Coordenador e professor da Especialização em Engenharia de Software com
 Ênfase em Java da Faculdade Pitágoras
 http://www.arsmachina.com.br




-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-19 Thread Bob Harner
On Tue, Apr 19, 2011 at 2:53 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 11:23 AM, Thiago H. de Paula Figueiredo
 thiag...@gmail.com wrote:
 On Tue, 19 Apr 2011 15:21:44 -0300, Howard Lewis Ship hls...@gmail.com
 wrote:

 On Tue, Apr 19, 2011 at 11:07 AM, Thiago H. de Paula Figueiredo
 thiag...@gmail.com wrote:

 I'm not using 5.2 yet (sigh), but I do use exploded WARs in deployment.

Just to be specific: Thiago said he is using exploded WARs in
deployment, but I didn't see where he said whether he depends on live
class reloading in production.


 Well then, you better add support for that back in, with a new symbol
 perhaps ;-}

 The ideal solution was to have a symbol for enabling the live class
 reloading . . . But I won't ask you that. :)

 No, you are right about adding Yet Another Symbol.  However, I have a
 philosophical problem with make every change subject to some
 configuration: it basically abdicates responsibility of the framework
 developers (us), forcing framework users to make critical decisions.
 This came up in the excellent book The Paradox of Choice, which is
 recommended reading. If you look at, for example, Mac/iPhone apps,
 you'll see consistently that they have fewer options and less
 configuration than equivalent Windows apps ... and people love them
 more (I've just seen this with my wife, who starting using Pages after
 years of Word).

 Now this specific case is one that treads onto hallowed ground of
 backwards compatibility, so it may be something where we introduce a
 symbol, and mark it immediately as deprecated (I always introduce a
 SymbolConstant static value, to provide documentation, and as a place
 to hang @Deprecated), so that people have a release to get used to the
 change.



 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
 and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 http://www.arsmachina.com.br






 --
 Thiago H. de Paula Figueiredo
 Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
 instructor
 Owner, Ars Machina Tecnologia da Informação Ltda.
 Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
 Coordenador e professor da Especialização em Engenharia de Software com
 Ênfase em Java da Faculdade Pitágoras
 http://www.arsmachina.com.br




 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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



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



Re: Live reload in production?

2011-04-19 Thread Igor Drobiazko
I never used live reloading in production, but it might be a cool marketing
weapon. We could promote it as seomthing similar to ZeroTurnaround's
LiveRebel:

http://www.zeroturnaround.com/liverebel/

Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
and roll back changes to live applications instantly -  without Downtime

On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com wrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




-- 
Best regards,

Igor Drobiazko
http://tapestry5.de


Re: Live reload in production?

2011-04-19 Thread Howard Lewis Ship
On Tue, Apr 19, 2011 at 4:00 PM, Igor Drobiazko
igor.drobia...@gmail.com wrote:
 I never used live reloading in production, but it might be a cool marketing
 weapon. We could promote it as seomthing similar to ZeroTurnaround's
 LiveRebel:

 http://www.zeroturnaround.com/liverebel/

 Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
 and roll back changes to live applications instantly -  without Downtime

I don't like to over-promise. Live reloading has some limitations in
terms of reloading of service layer objects. I think having a seamless
redeploy model is for the application servers to handle, not the
framework.

Basically, in production, you want to hype fast and stable.  In
development you want to hype, agile and testable.


 On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com wrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




 --
 Best regards,

 Igor Drobiazko
 http://tapestry5.de




-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-19 Thread Adam Zimowski
Excuse me asking, but with class reloading disabled in production,
template reloading still works, correct?

My designer who mostly does TML's expects templates be reloadable in production.

Adam

PS.

On a side note, what about a hybrid switch? Like component class
reloading but disable service reloading?


On Tue, Apr 19, 2011 at 6:14 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 4:00 PM, Igor Drobiazko
 igor.drobia...@gmail.com wrote:
 I never used live reloading in production, but it might be a cool marketing
 weapon. We could promote it as seomthing similar to ZeroTurnaround's
 LiveRebel:

 http://www.zeroturnaround.com/liverebel/

 Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
 and roll back changes to live applications instantly -  without Downtime

 I don't like to over-promise. Live reloading has some limitations in
 terms of reloading of service layer objects. I think having a seamless
 redeploy model is for the application servers to handle, not the
 framework.

 Basically, in production, you want to hype fast and stable.  In
 development you want to hype, agile and testable.


 On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com wrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




 --
 Best regards,

 Igor Drobiazko
 http://tapestry5.de




 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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



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



Re: Live reload in production?

2011-04-19 Thread Howard Lewis Ship
On Tue, Apr 19, 2011 at 4:22 PM, Adam Zimowski zimowsk...@gmail.com wrote:
 Excuse me asking, but with class reloading disabled in production,
 template reloading still works, correct?

 My designer who mostly does TML's expects templates be reloadable in 
 production.


Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll
probably have to introduce a new symbol to allow this to be enabled in
production. But I think the vast majority of deployments will not need
this (and may like the increased throughput and lowered memory
utilization).


 Adam

 PS.

 On a side note, what about a hybrid switch? Like component class
 reloading but disable service reloading?


 On Tue, Apr 19, 2011 at 6:14 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 4:00 PM, Igor Drobiazko
 igor.drobia...@gmail.com wrote:
 I never used live reloading in production, but it might be a cool marketing
 weapon. We could promote it as seomthing similar to ZeroTurnaround's
 LiveRebel:

 http://www.zeroturnaround.com/liverebel/

 Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
 and roll back changes to live applications instantly -  without Downtime

 I don't like to over-promise. Live reloading has some limitations in
 terms of reloading of service layer objects. I think having a seamless
 redeploy model is for the application servers to handle, not the
 framework.

 Basically, in production, you want to hype fast and stable.  In
 development you want to hype, agile and testable.


 On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com wrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




 --
 Best regards,

 Igor Drobiazko
 http://tapestry5.de




 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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



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





-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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



Re: Live reload in production?

2011-04-19 Thread Lenny Primak
I think live reload in production is a terrible idea.  
Production should be locked down.  Even if you are using exploded version of 
the application,
the app server should explicitly be told to reload the app, in which case live 
reloading is not required.


On Apr 19, 2011, at 7:36 PM, Howard Lewis Ship wrote:

 On Tue, Apr 19, 2011 at 4:22 PM, Adam Zimowski zimowsk...@gmail.com wrote:
 Excuse me asking, but with class reloading disabled in production,
 template reloading still works, correct?
 
 My designer who mostly does TML's expects templates be reloadable in 
 production.
 
 
 Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll
 probably have to introduce a new symbol to allow this to be enabled in
 production. But I think the vast majority of deployments will not need
 this (and may like the increased throughput and lowered memory
 utilization).
 
 
 Adam
 
 PS.
 
 On a side note, what about a hybrid switch? Like component class
 reloading but disable service reloading?
 
 
 On Tue, Apr 19, 2011 at 6:14 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 4:00 PM, Igor Drobiazko
 igor.drobia...@gmail.com wrote:
 I never used live reloading in production, but it might be a cool marketing
 weapon. We could promote it as seomthing similar to ZeroTurnaround's
 LiveRebel:
 
 http://www.zeroturnaround.com/liverebel/
 
 Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
 and roll back changes to live applications instantly -  without Downtime
 
 I don't like to over-promise. Live reloading has some limitations in
 terms of reloading of service layer objects. I think having a seamless
 redeploy model is for the application servers to handle, not the
 framework.
 
 Basically, in production, you want to hype fast and stable.  In
 development you want to hype, agile and testable.
 
 
 On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com 
 wrote:
 
 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.
 
 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.
 
 --
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 
 --
 Best regards,
 
 Igor Drobiazko
 http://tapestry5.de
 
 
 
 
 --
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 
 
 
 
 
 -- 
 Howard M. Lewis Ship
 
 Creator of Apache Tapestry
 
 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!
 
 (971) 678-5210
 http://howardlewisship.com
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
 For additional commands, e-mail: users-h...@tapestry.apache.org
 


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



Re: Live reload in production?

2011-04-19 Thread Adam Zimowski
I plead to ask, if possible to enable a switch for template reloading.
I may be screwed, literally...

Adam

On Tue, Apr 19, 2011 at 6:36 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 4:22 PM, Adam Zimowski zimowsk...@gmail.com wrote:
 Excuse me asking, but with class reloading disabled in production,
 template reloading still works, correct?

 My designer who mostly does TML's expects templates be reloadable in 
 production.


 Well, then, you're screwed in Tapestry 5.3 :-)  Looks like we'll
 probably have to introduce a new symbol to allow this to be enabled in
 production. But I think the vast majority of deployments will not need
 this (and may like the increased throughput and lowered memory
 utilization).


 Adam

 PS.

 On a side note, what about a hybrid switch? Like component class
 reloading but disable service reloading?


 On Tue, Apr 19, 2011 at 6:14 PM, Howard Lewis Ship hls...@gmail.com wrote:
 On Tue, Apr 19, 2011 at 4:00 PM, Igor Drobiazko
 igor.drobia...@gmail.com wrote:
 I never used live reloading in production, but it might be a cool marketing
 weapon. We could promote it as seomthing similar to ZeroTurnaround's
 LiveRebel:

 http://www.zeroturnaround.com/liverebel/

 Imagine a new slogan on Tapestry's webpage: With Tapestry you can roll out
 and roll back changes to live applications instantly -  without Downtime

 I don't like to over-promise. Live reloading has some limitations in
 terms of reloading of service layer objects. I think having a seamless
 redeploy model is for the application servers to handle, not the
 framework.

 Basically, in production, you want to hype fast and stable.  In
 development you want to hype, agile and testable.


 On Tue, Apr 19, 2011 at 7:11 PM, Howard Lewis Ship hls...@gmail.com 
 wrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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




 --
 Best regards,

 Igor Drobiazko
 http://tapestry5.de




 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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



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





 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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



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



Re: Live reload in production?

2011-04-19 Thread Thiago H. de Paula Figueiredo
On Tue, 19 Apr 2011 20:39:46 -0300, Adam Zimowski zimowsk...@gmail.com  
wrote:



I plead to ask, if possible to enable a switch for template reloading.


I guess this won't be a problem, as it doesn't touch class  
transformations, proxies, etc.


--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor

Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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



Re: Live reload in production?

2011-04-19 Thread Patrick Moore
Hi Howard,


Maybe the question should really be:


Does anyone out there rely on live class
(template, message catalog, whatever) reloading in their live,
production application?

 and what critical benefit does this offer?


I am with you on the paradox of choice. When I roll out new versions, there
are usually db schema and directory structure changes not just UI changes.
So the roll out has to have the server brought down.

I would love to have an atomic updating service. A new war is placed in a
staging location. The db update magically happens and then the older server
is brought down and replaced with the new server. But absence this magical
update genie, I would prefer the performance improvements because that will
be useful every day.

For those who feel that they need this, is there any sort of hooking that a
side project could use to restore this functionality without impact the
people who rather take the benefits of not having dynamic class loading in
production? Or maybe they just run in development mode on the production
box? ( maybe silly statement - but we are still on T4 :-( )


Patrick Moore
Amplafi
http://amplafi.com
mobile: 650-207-9792
Put your front window on your front page
personal blog : http://sworddance.com/blog


On Tue, Apr 19, 2011 at 10:11 AM, Howard Lewis Ship hls...@gmail.comwrote:

 Out of curiosity ... does anyone out there rely on live class
 (template, message catalog, whatever) reloading in their live,
 production application?  Now, normally, I'd think not, because the
 deployed app will be packaged in a WAR and the unit of redeployment is
 the entire WAR ... but I suppose some people could be using the
 exploded WAR format, which would allow classes and templates to be
 updated while the application runs.

 Live reloading is a feature that was originally intended for
 development only; Tapestry 5.2 supports live reloading in the live
 application, but as of yesterday, Tapestry 5.3 does NOT. I'm hoping to
 see some improvements in throughput and a reduction in memory
 utilization in production applications ... but it's not too late to
 shift things so that 5.3 can support production reloading as well.
 I'd prefer not to, however.

 --
 Howard M. Lewis Ship

 Creator of Apache Tapestry

 The source for Tapestry training, mentoring and support. Contact me to
 learn how I can get you up and productive in Tapestry fast!

 (971) 678-5210
 http://howardlewisship.com

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