OK, I found a simpler solution. I let SlideRepository simply implement
Component so that ECM won't generate a proxy for it. This would probably
also have fixed the previous bug.

Cocoon should startup normally now.

Unico

> -----Original Message-----
> From: Unico Hommes 
> Sent: woensdag 3 december 2003 12:30
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit: 
> cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/
> source/impl SlideSourceFactory.java
> 
>  
> 
> > -----Original Message-----
> > From: Andrew Savory [mailto:[EMAIL PROTECTED]
> > Sent: woensdag 3 december 2003 12:26
> > To: [EMAIL PROTECTED]
> > Subject: Re: cvs commit: 
> > cocoon-2.1/src/blocks/slide/java/org/apache/cocoon/components/
> > source/impl SlideSourceFactory.java
> > 
> > Hi,
> > 
> > On 3 Dec 2003, at 11:18, Joerg Heinicke wrote:
> > 
> > > When does this happen? At compile time there is a mock class, 
> > > furthermore you have a NoClassDefFoundError, that means as
> > much as the
> > > class was there, but is no longer. At Cocoon deploy/start
> > time? This
> > > would be really bad. It would be the second block not working by 
> > > default. Or at runtime? Then it's up to you. The jta.jar 
> is missing.
> > > There is also a note in the slide samples.
> > 
> > It's at startup. Basically, Cocoon and Jetty fail to start. 
> > I've disabled slide in local.blocks.properties and Cocoon starts 
> > again.
> > 
> > I don't appear to have a copy of jta.jar or jta-spec1_0_1.jar
> > - is this something that should be added to the slide lib 
> directory in 
> > CVS?
> > 
> > 
> 
> Well we can't for legal reasons. Maybe we should just copy 
> the mock classes to the webapp classpath. Anybody know if 
> that is legal?
> 
> Unico
> 
> 

Reply via email to