Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor result. Although location
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26054.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
On 09.01.2004 14:06, [EMAIL PROTECTED] wrote:
unico 2004/01/09 05:06:13
Modified:tools/targets ide-build.xml
Log:
also remove class files from WEB-INF when preparing to run Jetty
inside eclipse
But doesn't this break unnecessarily the
Sorry for the delay. Have been taking a few days off from the computer.
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
I missed your previous proposal. Do you have a pointer?
It's here:
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Joerg Heinicke wrote:
On 08.01.2004 18:00, Daniel Fagerstrom wrote:
I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an
input module. It can among other things replace the StreamGenerator
and the PartSource.
* XModuleSource
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
...
[Read|Write]SessionTransformers
---
...
I forgot to mention the problem with output modules that I described in
the
[EMAIL PROTECTED] wrote:
Ok, to be sure, if there is now a memory leak with Recyclable components in
some cases, I did a simple test case:
Setting the maximum pool of a Recyclable component to 2, lookup ten
instances in a row and release them.
Now, guess what happens?
All ten instances get
Stefano Mazzocchi wrote:
I *hate* sized pools.
Ah, Berin, what strategy algorithm are you guys using for size management?
To be honest, the most brain-dead and simple. I only wanted to get the job
done--and would have wanted to deal with better algorithms in the future.
Essentially the pool
Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator.
snip
WDYT?
/me thinks it's great!
Some low-level remarks,
[EMAIL PROTECTED] wrote:
Ok, to be sure, if there is now a memory leak with Recyclable
components in
some cases, I did a simple test case:
Setting the maximum pool of a Recyclable component to 2, lookup ten
instances in a row and release them.
Now, guess what happens?
All ten
I have not been able to work on Cocoon actively in a while, and I really
enjoyed the time I have been able to work on it. I will be chasing other
projects, most of which will not be on the server side. If you have the
odd question, feel free to shoot me an email.
Thank you all for the
Berin Loritsch wrote:
I have not been able to work on Cocoon actively in a while, and I really
enjoyed the time I have been able to work on it. I will be chasing other
projects, most of which will not be on the server side. If you have the
odd question, feel free to shoot me an email.
Thank you
Tony Collen wrote:
Berin Loritsch wrote:
I have not been able to work on Cocoon actively in a while, and I really
enjoyed the time I have been able to work on it. I will be chasing other
projects, most of which will not be on the server side. If you have the
odd question, feel free to shoot me
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough to
build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
encountered (detected using the stack element's
Christopher Oliver wrote:
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough
to build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
encountered (detected
Upayavira wrote:
Marc Portier wrote:
now, in this case backendX is cocoon (modifiable) sources, so I would
guess some saveToSource/loadFromSource can be made quite generic and
might very well be candidates for natural extension of the woody2.js
Yup. You've confirmed what I suspected. What I
Berin Loritsch wrote:
Tony Collen wrote:
It was nice having you around on the lists. I can totally understand
and appreciate the burn-out factor. I've recently hit an
inspirational (as well as energy) low-point, but I'm still going to
press on. Everybody needs a vacation. good luck with
Berin Loritsch wrote:
snip/
Thank you for the kind words, though glorious return does seem a bit
grand for such an occasion. If you are curious what I am up to, you
can track it here: http://www.jroller.com/page/bloritsch/Weblog
I added it to my news aggregator as soon as you mentioned it
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Mmmh... if we push and pop stack frame indications, isn't it enough
to build a debugger?
The runtime part of the debugger can be a optional listener in
add/popStackFrame which suspends the execution when a breakpoint is
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26068.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26068.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26068.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
[Sorry for the delay...I have been mostly off the list for
the last few days because my mail box is full and dropping
messages. To fix this, I have purchased a virtual server
account and will have a new email address within a few days.]
How can we solve this the best? It should be possible to
Was the Java-calling documentation removed on purpose from
flow/api.xml? Was the information moved somewhere else?
CVS comment: Added support for dynamic compilation of Java classes to flow component
Diff link (careful, it is line-wrapped):
Guido Casper wrote:
Upayavira wrote:
Marc Portier wrote:
now, in this case backendX is cocoon (modifiable) sources, so I would
guess some saveToSource/loadFromSource can be made quite generic and
might very well be candidates for natural extension of the woody2.js
Yup. You've
Moved here:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/documentation/xdocs/use
rdocs/flow/java.xml?view=markup
-Original Message-
From: Tim Larson [mailto:[EMAIL PROTECTED]
Sent: Monday, January 12, 2004 11:54 AM
To: [EMAIL PROTECTED]
Subject: Flow java-calling docs removed?
Was
On 12 Jan 2004, at 16:40, Berin Loritsch wrote:
So your point is well taken, and is theorhetically correct. But don't
be
deceived, there is energy expended to convert from ad hoc cocoon
systems to
one based on blocks.
Very very true. This is understood and taken into consideration. At the
Just tossing a few ideas at the list before going home from work.
==
=== A few possible selection semantics ===
(A)
if ((boolean)expression) ... then ...
(B)
if ((boolean)expression) ... then ... else ...
(C)
if ((boolean)expression_1) ... then ...
On 12 Jan 2004, at 07:38, Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace (with
location information) spanning (possibly nested) invocations of the
sitemap, flowscript, and JXTemplateGenerator. Currently using the JVM
stack trace produces a poor
On 12 Jan 2004, at 16:35, Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
I started looking into how I could get a meaningful stack trace
(with location information) spanning (possibly nested) invocations
of the sitemap, flowscript, and JXTemplateGenerator.
snip
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
println() style debugging seems to work quite well. A source-level
debugger is mainly required when the development turnaround cycle is
long (e.g. J2EE apps). For example,
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
println() style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround cycle is long (e.g.
hi,
snip/
Great idea, i was thinking about doing some sort of sitemap debugging,
please keep in mind that output is not solely system.out but some sort
of UI,
perhaps to give some idea, the servlet, or command line might be replaced by
ui
see
http://meineseite.one.at/bh22351/cocoonbean-3.png,
or
On 12.01.2004 13:28, Unico Hommes wrote:
Yes, executing this target does break running Jetty without Eclipse, but
it was already doing that before my change :-)
The target is intended to be used only when running Jetty inside of
Eclipse so that Jetty will use the Eclipse project classpath without
On 12.01.2004 23:40, Sylvain Wallez wrote:
How about adding a message attribute to ProcessingNode, e.g:
map:match pattern=page/*
map:generate type=jx src=screens/{1}.xml message=match
is page/{1}/
which would output something like
sitemap:
On 11.01.2004 20:31, Vadim Gritsenko wrote:
Modified:src/blocks/lucene/java/org/apache/cocoon/components/search
SimpleLuceneCocoonIndexerImpl.java
Log:
can the analyzer classname stuff be removed?
May be it should be added instead?
If it is of any use and somebody
Joerg Heinicke wrote:
Unico Hommes wrote:
Yes, executing this target does break running Jetty without Eclipse, ...
snip/
I guess my objection was to theretical - and wrong :) Sorry for the noise.
Thanks for checking though Joerg. I too became concerned when
i saw the change.
--David
Christopher Oliver wrote:
Sylvain Wallez wrote:
- we need a popStackFrame() method, since once a component has been
executed successfully and execution continues in its following
siblings, it should no longer appear in the stack trace
The idea is that this stack trace is created during
Vadim Gritsenko dijo:
Christopher Oliver wrote:
Sylvain Wallez wrote:
- we need a popStackFrame() method, since once a component has been
executed successfully and execution continues in its following
siblings, it should no longer appear in the stack trace
The idea is that this stack
I don't think anyone is suggesting that there shouldn't be support for a
source level debugger. But that is a large project, IMO. And having the
ability to do println debugging doesn't preclude it.
My $0.02,
Chris
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18,
Joerg Heinicke wrote:
On 11.01.2004 20:31, Vadim Gritsenko wrote:
Modified:
src/blocks/lucene/java/org/apache/cocoon/components/search
SimpleLuceneCocoonIndexerImpl.java
Log:
can the analyzer classname stuff be removed?
May be it should be added instead?
If it
Hi all, the cvs module on the public cvs server (
:pserver:[EMAIL PROTECTED]:/home/cvspublic ) seems to be broken
for the cocoon-2.1 module. cocoon-2.2 is fine.
-Brian
Brian McCallister dijo:
Hi all, the cvs module on the public cvs server (
:pserver:[EMAIL PROTECTED]:/home/cvspublic ) seems to be broken
for the cocoon-2.1 module. cocoon-2.2 is fine.
Hi Brian!
Can you post the error you got in CVS?
Best Regards,
Antonio Gallardo
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
On 12 Jan 2004, at 18:18, Christopher Oliver wrote:
Also with the fast edit - reload - test cycle provided by Cocoon,
println() style debugging seems to work quite well. A
source-level debugger is mainly required when the development
turnaround
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer which currently reside in the batik block,
... and wikify
Vadim Gritsenko wrote:
[snip]
I don't like that message has been added to the core sitemap tags. How
about adding separate tag (ant-like):
map:debug message= {1} ./
It's easier to add/remove (comment/uncomment) a tag than an attribute.
Or, arguing syntax even more: ;)
map:log
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
...
AFAIK the new sources can cover all use cases for the mentioned
components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and
FragmentExtractorTransformer
Hm. Correction: this pair actually can
Hi Antonio!
Ignore that problem, it got confused because I initially tried to check
it out from the ssh cvs without thinking and it failed (no permissions)
but created a local copy of the module dir and CVS/Root with CVS info
that apparently overrode the -d. Bizarro.
-Brian
On Jan 12, 2004,
---
This mail is generated automatically using
Jakarta Ant. Contents are automatically
downloaded from Apache's Bugzilla.
---
Please do not reply to
Le Mardi, 13 jan 2004, à 03:41 Europe/Zurich, Tony Collen a écrit :
Vadim Gritsenko wrote:
[snip]
I don't like that message has been added to the core sitemap tags.
How about adding separate tag (ant-like):
map:debug message= {1} ./
It's easier to add/remove (comment/uncomment) a
Christopher Oliver wrote:
I don't think anyone is suggesting that there shouldn't be support for
a source level debugger. But that is a large project, IMO. And having
the ability to do println debugging doesn't preclude it.
You're right.
I agree with Vadim that an explicit sitemap
53 matches
Mail list logo
