Hi, Joerg!
Hmm, okay - we have already added the IBM IDE Utility classes to
our workspace. We then imported the Java source for Cocoon 2 into its
own project in the workspace. We then created individual projects for
all of the various components that Cocoon 2 uses (e.g. Ant, Avalon,
Batik, FOP, etc.). The idea here was to allow us to be able to update
these other components without having to mess with the Cocoon 2 stuff.
Having to restart the servlet engine for each change to the
sitemap isn't a big deal for us, since we're more concerned about being
able to get in and take a look at what our custom generators and
transformers are doing in the debugger.
> - cocoon uses it's own classloader for the generated stuff. This
> means that this classloader won't find the classes living inside
> VAJ
This makes sense, but what if we're trying to simply observe how
one of the pre-existing generators or transformers work? VAJ in 3.5.3
has the capability to debug routines in external classes, and then you
can tell VAJ where to look for the source code.
The point I'm driving at is that if changing out portions of the
Cocoon 2 source code is the only way to get it to work under VAJ, then I
guess that is what we will have to do. We would prefer (if possible)
not to have to modify the Cocoon 2 code; for example, is there a way to
tell Cocoon2's classloader where to look for classes it is trying to
load.
In fact from spending all day working on this issue today, it
almost looks like when Cocoon2 tries to compile the sitemap, it does so
successfully, but then for some reason can't find the compiled code.
(It still does this, even after adding the directory pointed to by the
java.io.tmpdir property to the classpath. Is this the directory used by
Cocoon as it's "work directory"?)
Please go ahead and send along the required changes to both the
C2 code to import the code into VAJ's workspace, and the necessary
changes to the xsp.xsl logic sheet.
Thank you very much in advance.
Sincerely,
Noah Kaufman
Metatomix, Inc.
-----Original Message-----
From: Joerg Henne [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 20, 2001 6:37 AM
To: [EMAIL PROTECTED]
Subject: Re: More on Debugging Cocoon2 in VAJ
Hi,
"Kaufman, Noah" wrote:
>
> The problem we're having is that Cocoon 2 works fine with Tomcat
> outside of the debugger, but when we run Cocoon 2 in the debugger it
> craps out with the following error: "The sitemap handler's sitemap is
> not available." which means absolutely nothing to us, since it then
> tells you to look in the Cocoon 2 log for more information - of which
> there is none.
regarding C2 and VAJ you have to keep in mind a few things:
- The sitemap consists of a generated and compiled Java class
- VAJ is able to load these classes if you add the work/cocoon directory
to the "extra classpath", however, you won't be able to debug them and
reloading won't work (which means to restart the servlet engine for
every change you make to the sitemap)
- cocoon uses it's own classloader for the generated stuff. This means
that this classloader won't find the classes living inside VAJ
There are several way to make Cocoon work inside VAJ anyway, but they
all
involve some drawbacks. The solution we went with (prior to giving up on
VAJ in favor of NetBeans) looks like this:
1) Add the IBM IDE Utility classes to your workspace
2) Replace the C2 code that compiles the generated code with code that
actually perfoms an IMPORT into the VAJ workspace
3) Update the xsp.xsl logicsheet so that the timestamp of generated
Classes is set not in a static initializer, but in the consuructor. This
is necessary due to the fact that VAJ won't re-execute static blocks
when it reloads a class.
Please let me know if you want to take that route - I can provide you
with the necessary changes to the cocoon code.
Joerg Henne
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
