You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Enrico Migliore <en...@fatti.com> on 2004/05/27 08:03:53 UTC
Re: Cocoon 2.1.5 - javaflow problem (3)
Joerg Heinicke wrote:
> On 26.05.2004 19:00, Enrico Migliore wrote:
>
>> Cocoon 2.1.5
>> --------------
>>
>> I modified the CalculatorFlow example and noticed that:
>>
>> 1. if Cocoon is restarded, CalculatorFlow.class is loaded and the java
>> code executed.
>>
>> 1. if Cocoon is NOT restarded, CalculatorFlow.class is never reloaded
>> and the java
>> code is NOT executed.
>
>
> I do not really understand. Where is this class placed? Why do you
> expect it being updated?
>
> Joerg
Hi Joerg,
fact
----
Cocoon places the class "CalculatorFlow.class" in the following directory:
webapp/WEB-INF/classes/org/apache/cocoon/samples/flow/java
---oOo---
what I did
----------
I slightly modified the original "CalculatorFlow.java" and copied my version
of "CalculatorFlow.class" in that directory. In order to see my changes,
then I reloaded the following URI:
http://localhost:8888/samples/blocks/javaflow/calculator.do
---oOo---
what I noticed
--------------
I noticed that Cocoon doesn't reload the new class. If I restart Cocoon,
instead, the new class is correctly loaded and I can see the changes.
---oOo---
what I guess
-------------
It seems that Cocoon caches the class "CalculatorFlow.class" and doens't
reload even if I modify it.
---oOo---
Thanks for any help,
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multivalue field - setValues()
Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2004-05-30 at 16:16, Bartosz Zgodzinski wrote:
> When a want to inicialize a single checkbox a write:
> form.getWidget("single_checkbox").setValue(true);
>
> What shouuld I do when a have a multivalue field with list-type="checkbox"?
>
> I supose I should use setValeus, like this:
> form.getWidget("multi_checkbox").setValues(???);
>
> What should I write there (???). I know that this should be Object[], but I
> don't know what does it sxacly mean? Please give me an example.
It should be an array of objects, and the type of the object should
correspond to the datatype defined for the multivaluefield. For example,
if that's "string", then it should be an array of java.lang.String
objects.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
multivalue field - setValues()
Posted by Bartosz Zgodzinski <ba...@poczta.onet.pl>.
When a want to inicialize a single checkbox a write:
form.getWidget("single_checkbox").setValue(true);
What shouuld I do when a have a multivalue field with list-type="checkbox"?
I supose I should use setValeus, like this:
form.getWidget("multi_checkbox").setValues(???);
What should I write there (???). I know that this should be Object[], but I
don't know what does it sxacly mean? Please give me an example.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Cocoon 2.1.5 - javaflow problem - solved!
Posted by Enrico Migliore <en...@fatti.com>.
Hi guys,
I had the following problem:
"Cocoon 2.1.5 java-flow block doesn't reload .class files"
The result of that was that each time I made a modification to a class
file of my web application, I had to restart Cocoon.
Here's how I solved the problem:
------------------------------------------------------------------------
I modified the "JavaInterpreter.java" file in order for Cocoon to reload
a .class file when it detects a modification in time.
Please, read the following instructions:
1. Before running Cocoon, you need to set the environment variable
COCOON_HOME to the absolute path of your installation.
I'm using a batch file with the following content:
set COCOON_HOME="D:\Programmi\cocoon\cocoon-2.1.53"
cocoon servlet
Cocoon, on my PC, is indeed installed in
"D:\Programmi\cocoon\cocoon-2.1.53"
2. I posted the modified: "JavaInterpreter.java" and
"cocoon-javaflow-block.jar"
files at the following URL
http://www.foskeea.org/cocoon/javaflow-modified.zip
3. The modifications I made are meant for debug purposes only.
Because, the current release of Cocoon (2.1.5) doesn't
reload .class files.
I used the "File.separator" field in order for the modifications to run
on any platform.
4. Each time you modify a .class file, please have your URL point to
the initial URI of your web application, to start fresh a new debug
session.
I'm using it and hope it'll help others,
ciao
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6.3) - solved!
Posted by Enrico Migliore <en...@fatti.com>.
Upayavira wrote:
> Wow. You really must not reload the cocoon servlet at each request.
> The servlet does a lot of things like initialising loads of avalon
> objects, etc. If you did that at every request, you can expect your
> servlet container to die very quickly.
>
> Jetty can reload a class if you compile it while at a breakpoint, I
> use that regularly. But to have it reload when a class has changed
> would be really neat.
>
> Regards, Upayavira
>
Dear Upayavira,
I modified the "JavaInterpreter.java" file in order for Cocoon to
reload a .class file
when it detects a modification in time. Please, read the following
instructions, in case
you want to try it
1. Before running Cocoon, you need to set the environment variable
COCOON_HOME
to the absolute path of your installation. I'm using a batch file
with the following
content:
set COCOON_HOME="D:\Programmi\cocoon\cocoon-2.1.53"
cocoon servlet
Cocoon, on my PC, is indeed installed in
"D:\Programmi\cocoon\cocoon-2.1.53"
2. I posted the modified: "JavaInterpreter.java" and
"cocoon-javaflow-block.jar"
files at the following URL
http://www.foskeea.org/cocoon/javaflow-modified.zip
3. The modifications I made are meant for debug purposes only. Because,
as you
know, the current release of Cocoon (2.1.5) doesn't reload .class files.
I used the "File.separator" field in order for the modifications to
run on any
platform.
4. Each time you modify a .class file, please have your URL point to the
initial URI
of your web application, to start fresh a new debug session.
I'm using it and hope it'll help others,
ciao
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6.2)
Posted by Upayavira <uv...@upaya.co.uk>.
Enrico Migliore wrote:
> Stephan Michels wrote:
>
>> On Sat, 29 May 2004, Enrico Migliore wrote:
>>
>>
>>
>>> Dear Stephan
>>>
>>> I may have spot where the problem is. In the following file:
>>>
>>> .\cocoon-2.1.5\src\blocks\javaflow\TODO.txt
>>>
>>> I found the following script:
>>>
>>> ----------------------------------------------------------------------------
>>>
>>> What is left to do?
>>> -------------------
>>> - allow the ability to reload the java flow classes using for
>>> example the
>>> CompilingClassLoader.
>>> ----------------------------------------------------------------------------
>>>
>>>
>>> Does that mean that, at the moment, it's not possible to reload a class
>>> at runtime?
>>>
>>
>>
>> Yes, that's true. But this depends on the reloading behaviour of the
>> servlet classloader. If a class changed and the servlet container
>> reload the whole servlet then there won't be a problem. But
>> if it doesn't reload the servlet then the ContinuationClassloader will
>> stick to the previous class.
>>
>> I think that your problem can be solved, but I never tested the
>> reloading
>> behaviour of jetty, because I don't know how to activate it.
>>
>> Stephan
>>
>
> Dear Stephan,
>
> I'm investingating about how to instruct Jetty to reload a servlet, and
> eventually I will post to the mailing list the result, in case of
> success.
>
> I got just one dubt: if I reload the Cocoon servlet at each client's
> request,
> all new classes' instances will forget completely their previous history:
> continuations, the value of all instance variables...am I right?
Wow. You really must not reload the cocoon servlet at each request. The
servlet does a lot of things like initialising loads of avalon objects,
etc. If you did that at every request, you can expect your servlet
container to die very quickly.
Jetty can reload a class if you compile it while at a breakpoint, I use
that regularly. But to have it reload when a class has changed would be
really neat.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6.2)
Posted by Enrico Migliore <en...@fatti.com>.
Stephan Michels wrote:
>On Sat, 29 May 2004, Enrico Migliore wrote:
>
>
>
>>Dear Stephan
>>
>> I may have spot where the problem is. In the following file:
>>
>> .\cocoon-2.1.5\src\blocks\javaflow\TODO.txt
>>
>>I found the following script:
>>
>>----------------------------------------------------------------------------
>> What is left to do?
>> -------------------
>> - allow the ability to reload the java flow classes using for example the
>> CompilingClassLoader.
>>----------------------------------------------------------------------------
>>
>>Does that mean that, at the moment, it's not possible to reload a class
>>at runtime?
>>
>>
>
>Yes, that's true. But this depends on the reloading behaviour of the
>servlet classloader. If a class changed and the servlet container
>reload the whole servlet then there won't be a problem. But
>if it doesn't reload the servlet then the ContinuationClassloader will
>stick to the previous class.
>
>I think that your problem can be solved, but I never tested the reloading
>behaviour of jetty, because I don't know how to activate it.
>
>Stephan
>
Dear Stephan,
I'm investingating about how to instruct Jetty to reload a servlet, and
eventually I will post to the mailing list the result, in case of success.
I got just one dubt: if I reload the Cocoon servlet at each client's
request,
all new classes' instances will forget completely their previous history:
continuations, the value of all instance variables...am I right?
thanks again for your help
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6.1)
Posted by Stephan Michels <st...@apache.org>.
On Sat, 29 May 2004, Enrico Migliore wrote:
> Dear Stephan
>
> I may have spot where the problem is. In the following file:
>
> .\cocoon-2.1.5\src\blocks\javaflow\TODO.txt
>
> I found the following script:
>
> ----------------------------------------------------------------------------
> What is left to do?
> -------------------
> - allow the ability to reload the java flow classes using for example the
> CompilingClassLoader.
> ----------------------------------------------------------------------------
>
> Does that mean that, at the moment, it's not possible to reload a class
> at runtime?
Yes, that's true. But this depends on the reloading behaviour of the
servlet classloader. If a class changed and the servlet container
reload the whole servlet then there won't be a problem. But
if it doesn't reload the servlet then the ContinuationClassloader will
stick to the previous class.
I think that your problem can be solved, but I never tested the reloading
behaviour of jetty, because I don't know how to activate it.
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6.1)
Posted by Enrico Migliore <en...@fatti.com>.
Dear Stephan
I may have spot where the problem is. In the following file:
.\cocoon-2.1.5\src\blocks\javaflow\TODO.txt
I found the following script:
----------------------------------------------------------------------------
What is left to do?
-------------------
- allow the ability to reload the java flow classes using for example the
CompilingClassLoader.
----------------------------------------------------------------------------
Does that mean that, at the moment, it's not possible to reload a class
at runtime?
thanks again
Enrico
> Dear Stephan
>
> thanks for your time, first!
>
> Let's put it like this:
>
> "In my webapp, I decided to move the logic of my application,
> from the sitemap to Javaflow. How can I debug the logic if there's no
> way to
> reload at run time a JavaFlow class? I can't restart Cocoon each time
> I recompile a class"
>
> thanks
> Enrico
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (6)
Posted by Enrico Migliore <en...@fatti.com>.
Dear Stephan
thanks for your time, first!
Let's put it like this:
"In my webapp, I decided to move the logic of my application,
from the sitemap to Javaflow. How can I debug the logic if there's no
way to
reload at run time a JavaFlow class? I can't restart Cocoon each time
I recompile a class"
thanks
Enrico
>Am Sa, den 29.05.2004 schrieb Enrico Migliore um 10:00:
>
>
>>Dear Stefan,
>>
>> I need Cocoon to reload the class file at least during the development
>>and debug
>> phase of my web application, in order to see the effect of code changes.
>>
>>
>
>I never tested class reloading.
>
>
>
>> I'm using Jetty as a Servlet container.
>>
>>
>
>How do you enable class/servlet reloading with Jetty? Then I can check
>this behaviour.
>
>Stephan.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
--
/*
*************************************************************
*
* Enrico Migliore - senior software engineer
*
* FATTI srl - OSGi, GPRS, and GSM systems
*
* Via Donatello 48 - 20020 - Solaro - Milano - Italy
* Phone: +39 (0)2 9679 9655
* Fax: +39 (0)2 9679 9373
* http://www.fatti.com
*
* e-mail: enrico.migliore@fatti.com
*
*************************************************************
*/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (5)
Posted by Stephan Michels <st...@apache.org>.
Am Sa, den 29.05.2004 schrieb Enrico Migliore um 10:00:
> Dear Stefan,
>
> I need Cocoon to reload the class file at least during the development
> and debug
> phase of my web application, in order to see the effect of code changes.
I never tested class reloading.
> I'm using Jetty as a Servlet container.
How do you enable class/servlet reloading with Jetty? Then I can check
this behaviour.
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (5)
Posted by Enrico Migliore <en...@fatti.com>.
Dear Stefan,
I need Cocoon to reload the class file at least during the development
and debug
phase of my web application, in order to see the effect of code changes.
After the deployment of the application, it's ok if the servlet engine
doesn't reload
the class file at each client request.
I'm using Jetty as a Servlet container.
thanks for your help
Enrico
>
>
>>On 27.05.2004 12:45, Enrico Migliore wrote:
>>
>>
>>>Right now I'm using the flowscript for the logic of my application, but
>>>I have to move fast to java. What do you think if I contact the authors
>>>of the javaflow block, and then post the solution of this problem?
>>>
>>>
>>Stephan, can you imagine any difference between the two blocks? IIUC
>>it's just a classloader issue. I can imagine that something is done on
>>this in the javaflow block for the continuations.
>>
>>
>
>Thanks Joerg for the pointer.
>
>Yes, it's correct, the ContinuationClassLoader doesn't handle reloading
>of classes. But I wonder in which case the classes can be reloaded.
>In my perception the whole servlet must be reloaded if a class has
>changed?! Which servlet container do you use?
>
>Does anyone know how to activate class reloading in Jetty?
>
>Stephan.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (4)
Posted by Stephan Michels <st...@apache.org>.
Am Fr, den 28.05.2004 schrieb Joerg Heinicke um 0:28:
> On 27.05.2004 12:45, Enrico Migliore wrote:
> > Right now I'm using the flowscript for the logic of my application, but
> > I have to move fast to java. What do you think if I contact the authors
> > of the javaflow block, and then post the solution of this problem?
>
> Stephan, can you imagine any difference between the two blocks? IIUC
> it's just a classloader issue. I can imagine that something is done on
> this in the javaflow block for the continuations.
Thanks Joerg for the pointer.
Yes, it's correct, the ContinuationClassLoader doesn't handle reloading
of classes. But I wonder in which case the classes can be reloaded.
In my perception the whole servlet must be reloaded if a class has
changed?! Which servlet container do you use?
Does anyone know how to activate class reloading in Jetty?
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (4)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.05.2004 12:45, Enrico Migliore wrote:
> the problem here is that I want Cocoon to reload a compiled class file.
> I don't want my application to load a source file in order for the JVM
> compiler to compile it.
Ok.
> The Apples example works perfect: I deploy a compiled class file (i.e.
> foo.class),
> press the RELOAD button of the browser and Cocoon reloads the class.
Don't know what is be the difference between both. Marc, do you have
anything hacked in Apples ;-)
> Right now I'm using the flowscript for the logic of my application, but
> I have to move fast to java. What do you think if I contact the authors
> of the javaflow block, and then post the solution of this problem?
Stephan, can you imagine any difference between the two blocks? IIUC
it's just a classloader issue. I can imagine that something is done on
this in the javaflow block for the continuations.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (4)
Posted by Enrico Migliore <en...@fatti.com>.
> On 27.05.2004 08:03, Enrico Migliore wrote:
>
>>>> Cocoon 2.1.5
>>>> --------------
>>>>
>>>> I modified the CalculatorFlow example and noticed that:
>>>>
>>>> 1. if Cocoon is restarded, CalculatorFlow.class is loaded and the java
>>>> code executed.
>>>>
>>>> 1. if Cocoon is NOT restarded, CalculatorFlow.class is never
>>>> reloaded and the java
>>>> code is NOT executed.
>>>
>>>
>>> I do not really understand. Where is this class placed? Why do you
>>> expect it being updated?
>>
>
>
>> fact
>> ----
>>
>> Cocoon places the class "CalculatorFlow.class" in the following
>> directory:
>>
>> webapp/WEB-INF/classes/org/apache/cocoon/samples/flow/java
>
>
> I wonder why it does that. Are you using the CompilingClassLoader?
>
>> what I did
>> ----------
>>
>> I slightly modified the original "CalculatorFlow.java" and copied my
>> version
>> of "CalculatorFlow.class" in that directory. In order to see my
>> changes,
>> then I reloaded the following URI:
>>
>> http://localhost:8888/samples/blocks/javaflow/calculator.do
>>
>> ---oOo---
>>
>> what I noticed
>> --------------
>>
>> I noticed that Cocoon doesn't reload the new class. If I restart Cocoon,
>> instead, the new class is correctly loaded and I can see the changes.
>>
>> ---oOo---
>>
>> what I guess
>> -------------
>>
>> It seems that Cocoon caches the class "CalculatorFlow.class" and doens't
>> reload even if I modify it.
>
>
> I guess, it's not a caching, but a "problem" with the class loader.
> Probably it's just a missing feature.
>
> While thinking about it I don't think you use the CompilingClassLoader
> (you copied the class file by hand), but all samples end in
> WEB-INF/classes. This means it is normal behaviour to not reload a
> changed class. You probably should simply use CompilingClassLoader.
> This would make also the copying of the class file superfluous.
>
> http://cocoon.apache.org/2.1/userdocs/flow/java.html#Dynamic+Compilation
>
> Joerg
>
Hi Joerg
thanks a lot for the suggestion and for your time. I followed the link
you sent me:
the problem here is that I want Cocoon to reload a compiled class file.
I don't want my application to load a source file in order for the JVM
compiler to compile it.
The Apples example works perfect: I deploy a compiled class file (i.e.
foo.class),
press the RELOAD button of the browser and Cocoon reloads the class.
Right now I'm using the flowscript for the logic of my application, but
I have to move fast to java. What do you think if I contact the authors
of the javaflow block, and then post the solution of this problem?
thanks
Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1.5 - javaflow problem (3)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.05.2004 08:03, Enrico Migliore wrote:
>>> Cocoon 2.1.5
>>> --------------
>>>
>>> I modified the CalculatorFlow example and noticed that:
>>>
>>> 1. if Cocoon is restarded, CalculatorFlow.class is loaded and the java
>>> code executed.
>>>
>>> 1. if Cocoon is NOT restarded, CalculatorFlow.class is never reloaded
>>> and the java
>>> code is NOT executed.
>>
>> I do not really understand. Where is this class placed? Why do you
>> expect it being updated?
> fact
> ----
>
> Cocoon places the class "CalculatorFlow.class" in the following directory:
>
> webapp/WEB-INF/classes/org/apache/cocoon/samples/flow/java
I wonder why it does that. Are you using the CompilingClassLoader?
> what I did
> ----------
>
> I slightly modified the original "CalculatorFlow.java" and copied my
> version
> of "CalculatorFlow.class" in that directory. In order to see my changes,
> then I reloaded the following URI:
>
> http://localhost:8888/samples/blocks/javaflow/calculator.do
>
> ---oOo---
>
> what I noticed
> --------------
>
> I noticed that Cocoon doesn't reload the new class. If I restart Cocoon,
> instead, the new class is correctly loaded and I can see the changes.
>
> ---oOo---
>
> what I guess
> -------------
>
> It seems that Cocoon caches the class "CalculatorFlow.class" and doens't
> reload even if I modify it.
I guess, it's not a caching, but a "problem" with the class loader.
Probably it's just a missing feature.
While thinking about it I don't think you use the CompilingClassLoader
(you copied the class file by hand), but all samples end in
WEB-INF/classes. This means it is normal behaviour to not reload a
changed class. You probably should simply use CompilingClassLoader. This
would make also the copying of the class file superfluous.
http://cocoon.apache.org/2.1/userdocs/flow/java.html#Dynamic+Compilation
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org