Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of lars_huttar@sil.org designates
 208.145.81.51 as permitted sender)
Message-ID: <459D6B6D.3090409@sil.org>
Date: Thu, 04 Jan 2007 15:02:37 -0600
From: Lars Huttar <lars_huttar@sil.org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Running Cocoon in debugger
References: <459D013D.2010903@sil.org>
 <f767f0600701040847m65d7fecew21550553f64d4e70@mail.gmail.com>
 <459D5708.6080203@sil.org> <b7bdc6c0ba1d90bb0e4a0142aa49729a@comcast.net>
In-Reply-To: <b7bdc6c0ba1d90bb0e4a0142aa49729a@comcast.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Solved!
Again, thanks to all who wrote in with suggestions and questions. You 
prodded me in the right directions.

The problem causing Jetty not to start Cocoon was in web.xml. Based on a 
tip at 
http://www.servlets.com/archive/servlet/ReadMsg?msgId=534721&listName=jetty-support, 
I checked Cocoon's WEB-INF\web.xml and found that in Cocoon 2.1.7 I had 
long ago commented out the DOCTYPE declaration. [Why? An unsuccessful 
attempt to speed up Cocoon's startup time under Tomcat.] This had not 
caused Cocoon to fail under Tomcat, but it did under Jetty.
After reinstating the DOCTYPE, jetty ran Cocoon successfully again.

On 1/4/2007 2:23 PM, Mark Lundquist wrote:
> On Jan 4, 2007, at 11:35 AM, Lars Huttar wrote:
>
>     09:42:46.355 WARN!!
>     org.mortbay.util.MultiException[org.xml.sax.SAXParseException:
>     Document root element "web-app", must match DOCTYPE root "null".]
>     at org.mortbay.http.HttpServer.start(HttpServer.java:640)
>     at org.mortbay.jetty.Server.main(Server.java:429)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     ...
>     at Loader.run(Unknown Source)
>     at Loader.main(Unknown Source)
>     09:44:51.166 EVENT Started HttpContext[/]
>
>     The WARN is nothing new, I think, so I've been ignoring it...
>     maybe I shouldn't be??
>
>
> It's not normal, see below...
>
>     Any idea what document is failing to parse?
>
>
> It's a file like the webdefaults.xml that is shipped in 
> tools/jetty/conf (probably that very file, if you are using cocoon.bat 
> or whatever, starting Jetty from the Cocoon distibution � HTH...
>
> This error message is relevant, and so is the line that follows:
>
> 09:44:51.166 EVENT Started HttpContext[/]
>
> It should look instead like this:
>
> 11:52:06.987 EVENT Started WebApplicationContext[/,./webapp]
>
> The log message that you are getting meants that Jetty is not finding 
> something like tools/jetty/conf/main.xml, and that is what is causing 
> Jetty to display the page that says "No context on this server matched 
> or handled this request".
Thanks for digging into this. As noted above, I managed to find the 
problem. I appreciate your sharing your familiarity with Jetty!
>
>     I was going to try raw jdb as a simplest case, to see if it worked;
>
> You could, and it would, but you would then just have a very 
> unsatisfactory debugging environment.
But I would know that Cocoon and its servlet container were correctly 
configured for debugging, with a lot less configuration than it would 
take to set up Eclipse for debugging.
>
>     if so then I could work up to getting Eclipse configured to work
>     with Cocoon.
>
> It's not really "working up to", because being able to debug it w/ jdb 
> is not on the path to getting to the happy place where you are 
> debugging it with Eclipse.
I believe it *is* on the path... see previous response. When you 
currently have no debugging configuration, and don't know what you're 
doing, it's a lot easier to set up a debugging scenario if you can 
isolate debuggee configuration from debugger config. That way when it 
doesn't work, you have an idea whether it's a problem with debugger 
config or debuggee config. In other words, once I know that I have 
Jetty/Cocoon set up right for remote debugging, I can proceed to attempt 
remote debugging via Eclipse with much more confidence.
>
>     Or am I mistaken in thinking that you can debug Cocoon without
>     Eclipse?
>
>
> You /can/, but... :-(
>
> You can also eat a liter of pickled herring in one sitting. I'm sure 
> that is also possible, physically.
>
I'm sure debugging Cocoon with Eclipse is better than with jdb, but I 
have to crawl before I can walk.
My debugging requirements may even be small enough that jdb would do the 
job.

As for the pickled herring...
    With mustard?   :-)
>
>         2. Eclipse must only know about sources of your application
>         and Cocoon
>         to debug happy your applications. It does not care about your
>         configs
>         etc. You just have to import Cocoon as project into Eclipse's
>         workspace
>         and create project for your java classes and set-up necessary
>         dependencies on jars. That's all.
>
>
>     That's good to know. I figured you could probably debug Cocoon in
>     Eclipse without having a SVN working copy of Cocoon, but the
>     instructions at http://wiki.apache.org/cocoon/LoadInEclipse assume
>     you check Cocoon out of SVN.
>
>
> Yes, that's a problem with those instructions... they are targeted at 
> Cocoon developers who are debugging Cocoon proper (vs. a Cocoon-based 
> application). The aspects of "debug with Eclipse" and "set up Eclipse 
> for your Cocoon trunk SVN working area" are conflated (our "separation 
> of concerns" is not so good there... I remember going down that path 
> trying to learn this too :-)
>
>     I'm not familiar with Eclipse so was reluctant to spend time
>     figuring out how to do it independent of the instructions. E.g. it
>     seems non-trivial to learn how to specify where all the jar files
>     are, and all the source code, etc. Are there instructions anywhere
>     on how to do this?
>
>
> I don't have much time right now to hunt around for it, but... there 
> are ant targets to build the .project and .classpath files for 
> Eclipse, I just don't know if those were added in Cocoon 2.1.7. You 
> know, now that I think of it, I'm sure that those targets /are/ in 
> 2.1.7. Troll the list archives and I'm sure you'll find what you're 
> looking for, or maybe someone else here will just remember off the top 
> of their head...
>
>     I guess I will have to bite the bullet and learn Eclipse if I want
>     to use Eclipse to debug Cocoon.
>
> A little bit, yes. But that learning is well worth it. This is from a 
> former reluctant Eclipse learner :-). I was like, "vim is my IDE" ;-). 
> I didn't want to deal with the learning curve and dragged my feet on 
> the Eclipse thing, but I can tell you... do yourself a favor and take 
> a day to learn the basics of Eclipse, it will pay you back well...
OK, thanks for the tip. I've been wanting to learn Eclipse, so the 
encouragement is well received. It's just that most of my development 
work is at the Cocoon user level -- working with sitemaps and XSLTs and 
XSPs. I rarely do Java coding and debugging, so it's harder to maintain 
what knowledge of Eclipse I do acquire.
>
> Anyway � as I understand it, (a) you have this problem where Jetty 
> doesn't start up right when you do the "cocoon.bat servlet-debug", and 
> (b) you haven't actually tried debugging Jetty+Cocoon in Eclipse yet, 
> you're still trying to figure out (a). Right?
Yes. (I actually tried debugging Jetty+Cocoon in jdb, but it failed to 
connect. I then discovered Jetty wasn't actually running Cocoon, and 
figured I needed to solve (a) first.)
> I see you have sent a couple more emails since I started this one, so 
> maybe you have it figured out by now. If not: what happens when you do 
> plain old "cocoon.bat servlet"? Do the log messages look right in the 
> case, and do you see good things when you browse to the webapp site 
> root? Or not?
The console errors (which I assume are the same as any log messages) did 
not differ based on whether I used "servlet" or "servlet-debug".


Anyway, I've now got Jetty/Cocoon successfully running with "cocoon 
servlet-debug".
However, when I try connecting to them remotely with a debugger (jdb or 
Eclipse), it fails.

(1)
Trying with jdb:
C:\Program Files\Java\jdk1.5.0_09\bin>jdb -attach localhost:8000
java.io.IOException: shmemBase_attach failed: The system cannot find the 
file specified
        at com.sun.tools.jdi.SharedMemoryTransportService.attach0(Native 
Method)
        at 
com.sun.tools.jdi.SharedMemoryTransportService.attach(SharedMemoryTransportService.java:90)
        at 
com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:98)
        at 
com.sun.tools.jdi.SharedMemoryAttachingConnector.attach(SharedMemoryAttachingConnector.java:45)
        at 
com.sun.tools.example.debug.tty.VMConnection.attachTarget(VMConnection.java:358)
        at 
com.sun.tools.example.debug.tty.VMConnection.open(VMConnection.java:168)
        at com.sun.tools.example.debug.tty.Env.init(Env.java:63)
        at com.sun.tools.example.debug.tty.TTY.main(TTY.java:964)
Fatal error:
Unable to attach to target VM.


(2)
Trying with Eclipse:
I did Project / Debug... / Remote Java Application / New
Project: Apache Cocoon (which I had set up to use the Cocoon 2.1.7 
source distro root)
Connection type: Standard (Socket Attach) [the only choice in the list]
Host: localhost
Port: 8000
(I also unchecked "Run in background" on the Common tab.)
When I click the "Debug" button, I get a dialog saying, "Errors exist in 
required project(s): Apache cocoon. Continue launch?"
I click Yes, and after a moment of "Establishing connection...", I get:
    Exception occurred during launch
    Reason: failed to connect to remote VM. Connection refused.
    Details:
        Connection refused: connect

OK, so configuring Eclipse to remotely debug wasn't so bad, assuming I 
did it right.
But apparently I still don't have (a) right. I suspect methods (1) and 
(2) are failing for the same reason.
Any ideas on why I can't connect to the Jetty jvm?

Thanks again for your time and attention. Progress has been made! I'm 
almost there!

Lars


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org