You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by gelo1234 <ge...@gmail.com> on 2013/01/30 11:19:05 UTC
Deployment scenarios for cocoon 3.0
Hello,
Im thinking about applying several urgent patches onto the running cocoon
3.0 web app _without_ application server restart (be it Tomcat).
Lets say I want to modify some code inside REST Controller
(MyRestController).
I presume that If I make some change in REST Controller class i wont be
able just to replace jar/class files on running Tomcat and thats it. It
will NOT pick up the changes.
So lets say i create a new class flle (another version of REST Controller:
MyRestController2) and upload that class/jar file to Tomcat, then change
Cocoon sitemap.xmap to have a new class:
<controller:call controller="rest-controller"
select="com.foo.controller.MyRestController2">
...
</controller:call>
and thats it ? Will Cocoon pick it up correctly WITHOUT Tomcat restart and
use the new code ?
Or yet I have to update/refresh somehow Spring context/configuration ?
<context:component-scan base-package="com.foo.controller"
use-default-filters="false"
name-generator="org.apache.cocoon.rest.controller.ControllerBeanNameGenerator"
scope-resolver="org.apache.cocoon.rest.controller.ControllerBeanScopeResolver">
<context:include-filter type="annotation"
expression="org.apache.cocoon.rest.controller.annotation.RESTController" />
</context:component-scan>
<context:annotation-config />
I know its NOT a good practice to "hot deploy" such code on a production
servers but sometimes you just need fast update and cannot restart app
server or use some 3rd party tools like Live Rebel etc.
I don't want to introduce a new block with the new controller in cocoon
app, because that would also be a valid option as i presume ?
Greetings,
Greg
Re: Deployment scenarios for cocoon 3.0
Posted by gelo1234 <ge...@gmail.com>.
Thank you for a quick response Francesco. It IS some option indeed.
But AFAIK Tomcat 7.0 loader is equivalent to Context reloadable attribute.
It just overwrites the global (Context) reloadable attribute that existed
also in previous Tomcat versions. Either the latter or the former brings
some drawbacks in terms of performance:
As [1] states: "This feature is very useful during application development,
but it requires significant runtime overhead and is not recommended for use
on deployed production applications."
Reloading Tomcat deployed web app/context with Tomcat Manager also brings
some (although small) time period of your web app/context unavailability.
Taking into consideration the engine restart time that oscillates between 2
to 4 seconds in Tomcat 7.0, there is no big deal whether
you restart the Tomcat engine or reload the app with Tomcat Manager (if
there is only one web app/context running inside Tomcat).
I was wondering if there are some OSGi related techniques/mechanism in
Cocoon 3.0 that could help bring another version/release of a given
component and switch to that on demand on a live system.
But I guess its just the application server (not framework/library like
Cocoon issue), so for instance WebLogic got web app versioning feature [2]
or some OSGi-compliant app servers got native support for it. So the proper
solution would be for instance to use Cocoon custom components as OSGI
bundles inside an OSGI-compliant web application server.
Thank you for your tip on Tomcat config.
Greetings,
Greg
[2]
http://docs.oracle.com/cd/E13222_01/wls/docs90/programming/versioning.html
2013/1/30 Francesco Chicchiriccò <il...@apache.org>
> On 30/01/2013 11:19, gelo1234 wrote:
>
>> Hello,
>>
>> Im thinking about applying several urgent patches onto the running cocoon
>> 3.0 web app _without_ application server restart (be it Tomcat).
>>
>> Lets say I want to modify some code inside REST Controller
>> (MyRestController).
>> I presume that If I make some change in REST Controller class i wont be
>> able just to replace jar/class files on running Tomcat and thats it. It
>> will NOT pick up the changes.
>>
>> So lets say i create a new class flle (another version of REST Controller:
>> MyRestController2) and upload that class/jar file to Tomcat, then change
>> Cocoon sitemap.xmap to have a new class:
>>
>> <controller:call controller="rest-controller" select="com.foo.controller.
>> **MyRestController2">
>> ...
>> </controller:call>
>>
>> and thats it ? Will Cocoon pick it up correctly WITHOUT Tomcat restart
>> and use the new code ?
>>
>> Or yet I have to update/refresh somehow Spring context/configuration ?
>>
>> <context:component-scan base-package="com.foo.**controller"
>> use-default-filters="false"
>> name-generator="org.apache.**cocoon.rest.controller.**
>> ControllerBeanNameGenerator"
>> scope-resolver="org.apache.**cocoon.rest.controller.**
>> ControllerBeanScopeResolver">
>> <context:include-filter type="annotation"
>> expression="org.apache.cocoon.**rest.controller.annotation.**RESTController"
>> />
>> </context:component-scan>
>>
>> <context:annotation-config />
>>
>> I know its NOT a good practice to "hot deploy" such code on a production
>> servers but sometimes you just need fast update and cannot restart app
>> server or use some 3rd party tools like Live Rebel etc.
>> I don't want to introduce a new block with the new controller in cocoon
>> app, because that would also be a valid option as i presume ?
>>
>
> Hi Greg,
> given the constraints you define above, I would suggest to solve your
> problem at Tomcat level by empowering the "reloadable" attribute of
> classloaders [1].
>
> In this way you don't need to modify anything at Cocoon level.
>
> Regards.
>
> [1] http://tomcat.apache.org/**tomcat-7.0-doc/config/loader.**html<http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/~ilgrosso/>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.**apache.org<us...@cocoon.apache.org>
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: Deployment scenarios for cocoon 3.0
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 30/01/2013 11:19, gelo1234 wrote:
> Hello,
>
> Im thinking about applying several urgent patches onto the running
> cocoon 3.0 web app _without_ application server restart (be it Tomcat).
>
> Lets say I want to modify some code inside REST Controller
> (MyRestController).
> I presume that If I make some change in REST Controller class i wont
> be able just to replace jar/class files on running Tomcat and thats
> it. It will NOT pick up the changes.
>
> So lets say i create a new class flle (another version of REST Controller:
> MyRestController2) and upload that class/jar file to Tomcat, then
> change Cocoon sitemap.xmap to have a new class:
>
> <controller:call controller="rest-controller"
> select="com.foo.controller.MyRestController2">
> ...
> </controller:call>
>
> and thats it ? Will Cocoon pick it up correctly WITHOUT Tomcat restart
> and use the new code ?
>
> Or yet I have to update/refresh somehow Spring context/configuration ?
>
> <context:component-scan base-package="com.foo.controller"
> use-default-filters="false"
> name-generator="org.apache.cocoon.rest.controller.ControllerBeanNameGenerator"
> scope-resolver="org.apache.cocoon.rest.controller.ControllerBeanScopeResolver">
> <context:include-filter type="annotation"
> expression="org.apache.cocoon.rest.controller.annotation.RESTController"
> />
> </context:component-scan>
>
> <context:annotation-config />
>
> I know its NOT a good practice to "hot deploy" such code on a
> production servers but sometimes you just need fast update and cannot
> restart app server or use some 3rd party tools like Live Rebel etc.
> I don't want to introduce a new block with the new controller in
> cocoon app, because that would also be a valid option as i presume ?
Hi Greg,
given the constraints you define above, I would suggest to solve your
problem at Tomcat level by empowering the "reloadable" attribute of
classloaders [1].
In this way you don't need to modify anything at Cocoon level.
Regards.
[1] http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org