You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ml...@s-und-n.de on 2002/12/12 10:08:31 UTC
Cocoon IDE with debugger
I have been following the discussion about a Cocoon IDE, debugger etc. with
some interest (although my email connection is limited this week). As most
of you know we have developed some plugins for eclipse that can help with
Cocoon based application development. You can download "sunBow" from here:
http://radio.weblogs.com/0108489/. sunBow is free although not (yet) open
source.
In addition we have implemented part of a debugger (consisting of another
plugin and the Cocoon side) that some of you saw in Ghent. Sylvain posted
the link to a screenshot earlier.
At the moment I am trying to convince "the powers" that we should donate
sunBow and the debugger to Cocoon. There are various reasons for this that
I won't get into now. The outcome of my push to do this is also uncertain
at the moment.
Now, Nicola mentioned that the concept for the debugger he discussed with
Gianugo should not be based on eclipse. So that would of course rule out
what we currently have.
Anyway, whatever the outcome I look forward to this new development as it
certainly is something that is needed badly. Perhaps Gianugo and Nicola
could provide some details on what they are thinking of?
Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Gianugo Rabellino <gi...@apache.org>.
mlangham@s-und-n.de wrote:
>
> In addition we have implemented part of a debugger (consisting of another
> plugin and the Cocoon side) that some of you saw in Ghent. Sylvain posted
> the link to a screenshot earlier.
Yes, and it looks cool indeed.
> At the moment I am trying to convince "the powers" that we should donate
> sunBow and the debugger to Cocoon. There are various reasons for this that
> I won't get into now. The outcome of my push to do this is also uncertain
> at the moment. >
> Now, Nicola mentioned that the concept for the debugger he discussed with
> Gianugo should not be based on eclipse. So that would of course rule out
> what we currently have.
Hmmm... not really. How about working together on a underlying common
debugging architecture? I'm talking about communication protocols
between a debugger and the server, as well as needed server-side
components. This way one might be free to implement the client at will,
so that you might have the Eclipse plugin as part of a broader set of
Cocoon tools, Cocoon might include a Swing plugin, some other might
write a command line debugger... how about it? It might be a good way to:
1. not reinvent the wheel: S&N might consider donating the "generic"
components, while preserving the investment in the commercial eclipse
stuff (your boss might like that better ;-)).
2. have a flexible architecture wich might allow for future extension.
Think JPDA for Cocoon.
How does that sound?
Ciao,
--
Gianugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Christian Haul wrote:
> On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
>
>>Anyway, whatever the outcome I look forward to this new development as it
>>certainly is something that is needed badly. Perhaps Gianugo and Nicola
>>could provide some details on what they are thinking of?
>
> What we were discussing is a possibility to debug the pipeline.
[...]
> The third and most promising variant would be to place the debug
> transformer at the end of the pipeline. It could pop up a window
> showing the current event and a button to continue. Since processing
> is stopped until the SAX event call returns, it would be possible to
> single step the pipeline in conjunction with the log transformer.
>
> Of course, a deluxe debug transformer could show the generated
> document so far and event allow to inspect the objectModel.
>
> Actually, I believe that showing the Document in a tree control would
> be relatively simple. Adding an option whether to confirm every event,
> or only special events (like endDocument) would be nice as well. And
> together with the XPathProcessor's selectSingleNode it should be
> relatively simple to break on XPath expressions as well.
Yup, Gianugo and I have expanded on this last possibility, and I already
have some code that shows it's doable.
Basically, the concept is to create a DebuggingPipeline, and a
DebuggingCachingPipeline, that insert special debugging connectors
between the components of the pipeline. These log all events, and
interact with a client debugger via an Avalon CocoonDebuggerComponent
that works as a proxy.
In this way we can see all that is happening in the pipeline event per
event, component per component, and be able to set xpath breakpoints.
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephan Michels wrote:
[...]
>>Anyway, how that tool works is flawed, and will not necessarily work
>>with all pipelines (this came out in the Stammtisch), since they might
>>rely on the events being processed through the whole pipeline instead of
>>being cached.
>
> Do you mean the 'Captor' component or the profiling component?
I've seen the profiling one.
> To allow debuging on a server, you should only need to 'instrumentable'
> the profiling component, I think.
Something like that, but with changes to the way it works, hooks to act
on the stream, etc...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Stephan Michels <st...@apache.org>.
On Thu, 12 Dec 2002, Nicola Ken Barozzi wrote:
>
> Bruno Dumon wrote:
> > On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
> >
> >>Christian Haul wrote:
> >>
> >>
> >>>On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
> >>>
> >>>
> >>>>Anyway, whatever the outcome I look forward to this new development as it
> >>>>certainly is something that is needed badly. Perhaps Gianugo and Nicola
> >>>>could provide some details on what they are thinking of?
> >>>
> >>>
> >>>What we were discussing is a possibility to debug the pipeline. For
> >>>this we have currently the LogTransformer. One could put this between
> >>>several transformation steps and see what happened.
> >>
> >>sounds very similar to captor which has been posted once as a patch by
> >>Bruno: http://outerthought.net/captor.html
> >
> > well, there's a difference though. Captor is very useful in itself for
> > people wanting to understand pipelines, though its completely un-useful
> > if you're writing your own SAX-transformer which (during development)
> > might be quite buggy and generate invalid SAX-events. But for many users
> > out there captor can be extremely useful.
>
> Our idea is based on the profiling component in Cocoon CVS, so yes, we
> have seen it.
I have included the concept the 'Captor' in the profiling pipelines for
some time ago, but only for Cocoon 2.1.(Thanks to Bruno)
> Anyway, how that tool works is flawed, and will not necessarily work
> with all pipelines (this came out in the Stammtisch), since they might
> rely on the events being processed through the whole pipeline instead of
> being cached.
Do you mean the 'Captor' component or the profiling component?
To allow debuging on a server, you should only need to 'instrumentable'
the profiling component, I think.
My 2 cents, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Bruno Dumon wrote:
> On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
>
>>Christian Haul wrote:
>>
>>
>>>On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
>>>
>>>
>>>>Anyway, whatever the outcome I look forward to this new development as it
>>>>certainly is something that is needed badly. Perhaps Gianugo and Nicola
>>>>could provide some details on what they are thinking of?
>>>
>>>
>>>What we were discussing is a possibility to debug the pipeline. For
>>>this we have currently the LogTransformer. One could put this between
>>>several transformation steps and see what happened.
>>
>>sounds very similar to captor which has been posted once as a patch by
>>Bruno: http://outerthought.net/captor.html
>
> well, there's a difference though. Captor is very useful in itself for
> people wanting to understand pipelines, though its completely un-useful
> if you're writing your own SAX-transformer which (during development)
> might be quite buggy and generate invalid SAX-events. But for many users
> out there captor can be extremely useful.
Our idea is based on the profiling component in Cocoon CVS, so yes, we
have seen it.
Anyway, how that tool works is flawed, and will not necessarily work
with all pipelines (this came out in the Stammtisch), since they might
rely on the events being processed through the whole pipeline instead of
being cached.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2002-12-12 at 10:44, Steven Noels wrote:
> Christian Haul wrote:
>
> > On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
> >
> >>Anyway, whatever the outcome I look forward to this new development as it
> >>certainly is something that is needed badly. Perhaps Gianugo and Nicola
> >>could provide some details on what they are thinking of?
> >
> >
> > What we were discussing is a possibility to debug the pipeline. For
> > this we have currently the LogTransformer. One could put this between
> > several transformation steps and see what happened.
>
> sounds very similar to captor which has been posted once as a patch by
> Bruno: http://outerthought.net/captor.html
>
well, there's a difference though. Captor is very useful in itself for
people wanting to understand pipelines, though its completely un-useful
if you're writing your own SAX-transformer which (during development)
might be quite buggy and generate invalid SAX-events. But for many users
out there captor can be extremely useful.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Steven Noels <st...@outerthought.org>.
Christian Haul wrote:
> On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
>
>>Anyway, whatever the outcome I look forward to this new development as it
>>certainly is something that is needed badly. Perhaps Gianugo and Nicola
>>could provide some details on what they are thinking of?
>
>
> What we were discussing is a possibility to debug the pipeline. For
> this we have currently the LogTransformer. One could put this between
> several transformation steps and see what happened.
sounds very similar to captor which has been posted once as a patch by
Bruno: http://outerthought.net/captor.html
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Cocoon IDE with debugger
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 12.Dec.2002 -- 10:08 AM, mlangham@s-und-n.de wrote:
> Anyway, whatever the outcome I look forward to this new development as it
> certainly is something that is needed badly. Perhaps Gianugo and Nicola
> could provide some details on what they are thinking of?
What we were discussing is a possibility to debug the pipeline. For
this we have currently the LogTransformer. One could put this between
several transformation steps and see what happened.
A little improved would be a solution that captures a complete
document after one step and displays it. This doucment could be used
to feed the next step in the pipeline. This, however, does not deal
well with communications through a sidechannel like the
objectModel. I.e. during the transformation the objectModel could be
changed which in turn affects another transformation step.
The third and most promising variant would be to place the debug
transformer at the end of the pipeline. It could pop up a window
showing the current event and a button to continue. Since processing
is stopped until the SAX event call returns, it would be possible to
single step the pipeline in conjunction with the log transformer.
Of course, a deluxe debug transformer could show the generated
document so far and event allow to inspect the objectModel.
Actually, I believe that showing the Document in a tree control would
be relatively simple. Adding an option whether to confirm every event,
or only special events (like endDocument) would be nice as well. And
together with the XPathProcessor's selectSingleNode it should be
relatively simple to break on XPath expressions as well.
This should be an outline of our discussion (Nicola, Gianugo, and
myself) on Monday.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org