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ò ilgro...@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.**htmlhttp://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.orgusers-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
