[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[lepido-dev] Re: [Contribution] Sitemap Debugger/Trace
|
Hi Jens,
Sorry for the late answer, I took me some time to have an in-depth look
at the code and triggered some difficult thoughts (see below).
Jens Maukisch wrote:
It would therefore be good to work together on the unified debugger
architecture mentioned in the Lepido proposal [1], merging your
experience with the sunBow debugger together with our ideas and
prototypes for an extensible debugger, that would also be based on
Eclipse's generic debugger infrastructure.
Yes, sure, thats the long term goal. But to get things started somehow
we need something as a base to start from. Whether if it's your code
or ours or if we decide to start from scratch does not matter but in
some way we need to get started :-)
I perfectly agree with this, we need to get started. However, and I'm
sorry to say that, the current code and architecture of the sunBow
debugger doesn't seem to me as being a viable starting code base. Too
many limitations that prevent it to become a full-fledged debugger
without a total rewrite.
If you can provide your code (maybe with some lines of text on how it
works on the Eclipse and on the Cocoon side) I will be happy to have
a look at it and see how we can e.g. merge things etc. It doesn't
matter if your stuff is finished or not.
As I said, my code is some proof of concept demonstrating that using AOP
(AspectWerkz actually -- soon to be merged with AspectJ in its 1.5
version) we can intercept instruction execution in various
interpretation engines on the runtime side and access all the needed
runtime information that represent the equivalent of local variables in
a Java debugger.
I haven't touched this for about a year now, and I'd like to clean it up
before publishing it.
As the debugger affects Cocoon directly we have not only to discuss
on how it is done on the Eclipse side but on how it can be done best
in Cocoon.
Using AspectWerkz and loadtime code weaving, there's not a single line
to change in Cocoon. Just drop in a jar and change some startup
properties and you're done. That's the very interesting point in this
approach, which also allows to write debugger drivers for third-party
libraries.
So we have on one hand some existing code that IMO isn't a good starting
point and on the other side some promising ideas but no running code. In
order for the debugger to get started, I think the best would be to
organize a dedicated session during the GetTogether hackathon, hoping
you will be there.
I will cleanup the prototype code and upgrade it to the latest
AspectWerkz so that we have some actual material to discuss on. This
will unfortunately not happend before the end of next week as I have to
prepare my GT talk.
In the meantime, here are some very interesting resources about the
Eclipse debugger framework:
- How to write an Eclipse debugger:
http://www.eclipse.org/articles/Article-Debugger/how-to.html
- Material of the EclipseCon 2005 tutorial:
http://www.eclipsecon.org/2005/presentations/EclipseCon2005_Tutorial21.zip
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
