You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/05/13 20:52:55 UTC

Release tomorrow?

I haven't read all mails from this week yet, but it seems
that nothing is preventing us from a release tomorrow.

Or did I oversee something?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/


Re: Release tomorrow?

Posted by Ugo Cei <u....@cbim.it>.
Ugo Cei wrote:
> Fine. I'll commit the changes to the build files ASAP, so we can 
> reenable the testcase before the release.

Done.

		Ugo



Re: Release tomorrow?

Posted by Ugo Cei <ug...@apache.org>.
Il giorno 16/mag/04, alle 22:53, Upayavira ha scritto:

> Also, since committing the webapp/test-suite, I found 
> webapp/samples/test, which serves much the same purpose. So I should 
> really change the test suite to use that, and remove the 
> webapp/test-suite. I'll try to do this before the release, as it would 
> be best if it doesn't go out with a release.

Fine. I'll commit the changes to the build files ASAP, so we can 
reenable the testcase before the release.

	Ugo


-- 
Ugo Cei - http://beblogging.com/


Re: Release tomorrow?

Posted by Upayavira <uv...@upaya.co.uk>.
Ugo Cei wrote:

> I *almost* got the CocoonBeanTestCase to succeed. After adding the 
> blocks' lib directories to the classpath, we still have a failure, 
> because the src/webapp/test-suite/sitemap.xmap file references a file 
> named stylesheets/xdoc2html.xslt that is not there! There is a file 
> named "simple-xdoc2html.xsl" but using it instead gives a failure when 
> checking the length of the pipeline output.
>
> Where has "xdoc2html.xslt" gone?

If you've got there, you've got the job done, which is great. The rest 
should be pretty easy. I'll try to look at it tomorrow.

Also, since committing the webapp/test-suite, I found 
webapp/samples/test, which serves much the same purpose. So I should 
really change the test suite to use that, and remove the 
webapp/test-suite. I'll try to do this before the release, as it would 
be best if it doesn't go out with a release.

Regards, Upayavira




Re: Release tomorrow?

Posted by Ugo Cei <ug...@apache.org>.
I *almost* got the CocoonBeanTestCase to succeed. After adding the 
blocks' lib directories to the classpath, we still have a failure, 
because the src/webapp/test-suite/sitemap.xmap file references a file 
named stylesheets/xdoc2html.xslt that is not there! There is a file 
named "simple-xdoc2html.xsl" but using it instead gives a failure when 
checking the length of the pipeline output.

Where has "xdoc2html.xslt" gone?

	Ugo


-- 
Ugo Cei - http://beblogging.com/


Re: Release tomorrow?

Posted by Ugo Cei <ug...@apache.org>.
Il giorno 14/mag/04, alle 08:32, Upayavira ha scritto:

> Ugo Cei wrote:
>
>> Il giorno 13/mag/04, alle 23:57, Joerg Heinicke ha scritto:
>>
>>>> Running org.apache.cocoon.bean.CocoonBeanTestCase
>>>> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec
>>>> TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED
>>>
>>>
>>> Some info on it from Upayavira:
>>> http://marc.theaimsgroup.com/?t=108011464200003&r=1&w=4
>>
>>
>> We just need an Avalon guru, then ;-).
>
> Yup. This test case just shows up something that has been wrong for a 
> _very_ long time. I'm reluctant to remove it, as that which it shows 
> up should be fixed rather than ignored.
>
> Either I finally work it out (which probably won't happen in a hurry) 
> or someone else looks into it. How to remove reliance upon the 
> servlet.jar. Hmm.

I did some investigation on this issue. The problem seems to be caused 
by the fact that the CocoonBeanTestCase does:

cocoon.setConfigFile("WEB-INF/cocoon.xconf");

where cocoon.xconf references classes that are contained in blocks, but 
the blocks JARs are not in the classpath when the testcase is run. I 
tried to fix it by adding them, but now the test fails with

java.lang.NoClassDefFoundError: javax/jms/MessageListener

So I think we need to also add the libraries that blocks depend on. 
I'll try this later.

	Ugo


-- 
Ugo Cei - http://beblogging.com/


RE: JCS status

Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Aaron:

Thanks for the answer. I already forwarded your reply to Cocoon dev. I
hope we will use JCS as the default persistent store in Cocoon. I will
post back any decision from Cocoon. AFAIK, that would be fine for JCS to
have another project that use it. I already read some of the bad things
that people at Hibernate wrote about JCS and I am sure that all is FUD.

Best Regards,

Antonio Gallardo

Aaron Smuts dijo:
> The diskcache shutdown storage problem (where the keys were not being
> stored) should be solved.
>
> Let me know if you have any problems.
>
> Cheers,
>
> Aaron
>
>> -----Original Message-----
>> From: Antonio Gallardo [mailto:agallardo@agssa.net]
>> Sent: Friday, May 14, 2004 4:13 AM
>> To: turbine-jcs-dev@jakarta.apache.org
>> Cc: dev@cocoon.apache.org
>> Subject: JCS status
>>
>> Hi:
>>
>> We, at Apache Cocoon project, are looking for a replacement for jisp.
> As I
>> posted few months ago, we found JCS project as a good candidate for
> this
>> task.
>>
>> We have interest in know if the problem related to "something at
> shutdown"
>> is already solved. The interest is because we are considering to
> release
>> soon and we will be glad to make Apache JCS our default persistent
> cache
>> store.
>>
>> Can you comment about that?
>>
>> Best Regards,
>>
>> Antonio Gallardo
>>
>> PS: I am cc-ing to the cocoon dev list.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
> turbine-jcs-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org


JCS status

Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:

We, at Apache Cocoon project, are looking for a replacement for jisp. As I
posted few months ago, we found JCS project as a good candidate for this
task.

We have interest in know if the problem related to "something at shutdown"
is already solved. The interest is because we are considering to release
soon and we will be glad to make Apache JCS our default persistent cache
store.

Can you comment about that?

Best Regards,

Antonio Gallardo

PS: I am cc-ing to the cocoon dev list.

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org


JCS status

Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:

We, at Apache Cocoon project, are looking for a replacement for jisp. As I
posted few months ago, we found JCS project as a good candidate for this
task.

We have interest in know if the problem related to "something at shutdown"
is already solved. The interest is because we are considering to release
soon and we will be glad to make Apache JCS our default persistent cache
store.

Can you comment about that?

Best Regards,

Antonio Gallardo

PS: I am cc-ing to the cocoon dev list.

Re: Release tomorrow?

Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 14.05.2004 14:03, Sylvain Wallez wrote:
>
>> Can someone summarize the pro and cons of both JCS and EHCache, both
>> from a license and technical POV?
>
> Don't have any experience with them, but both are Apache license. And
> technical: http://ehcache.sourceforge.net/, section "A replacement for
> JCS".

Hehe. But JCS is our own dogfood. With JCS we cannot risk that someelse
wake up a day and said:

"You know guy, I am going GPL".

And the same JISP history again.

Best Regards,

Antonio Gallardo


Re: Release tomorrow?

Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.05.2004 14:03, Sylvain Wallez wrote:

> Can someone summarize the pro and cons of both JCS and EHCache, both 
> from a license and technical POV?

Don't have any experience with them, but both are Apache license. And 
technical: http://ehcache.sourceforge.net/, section "A replacement for JCS".

Joerg

Re: Release tomorrow?

Posted by Sylvain Wallez <sy...@apache.org>.
David Crossley wrote:

>We had a IRC discussion about this last FirstFriday. At the end i
>searched the mail archives ...
><xley>  'grep ehcache dev@cocoon' shows that the discussion was
>inconclusive
><xley>  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107879126611385
>seems to prefer JCS store
>  
>

Can someone summarize the pro and cons of both JCS and EHCache, both 
from a license and technical POV?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Re: Release tomorrow?

Posted by David Crossley <cr...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> >Bertrand Delacretaz wrote:
> Sylvain Wallez a écrit :
> >>
> >>>...What's the status of EHCache and JCS? Can't we consider 
> >>one of them as the default persistent store?
> >>
> >>I think there's an issue with JCS, something at shutdown IIRC?
> >>And, also IIRC, Unico reported using EHCache with no problems.    
> >
> >Ah, thanks, Sylvain for the info!
> >
> >So, I think we should not release today, switch to EHCache, test
> >it over the weekend and then release on monday or tuesday.
> 
> +1 ! Persistent cache is a must-have.

We had a IRC discussion about this last FirstFriday. At the end i
searched the mail archives ...
<xley>  'grep ehcache dev@cocoon' shows that the discussion was
inconclusive
<xley>  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107879126611385
seems to prefer JCS store

--David




Re: Release tomorrow?

Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:

>Bertrand Delacretaz wrote:
> 
>  
>
>>Le 14 mai 04, à 10:50, Sylvain Wallez a écrit :
>>    
>>
>>>...What's the status of EHCache and JCS? Can't we consider 
>>>      
>>>
>>one of them 
>>    
>>
>>>as the default persistent store?
>>>      
>>>
>>I think there's an issue with JCS, something at shutdown IIRC?
>>And, also IIRC, Unico reported using EHCache with no problems.
>>
>>    
>>
>Ah, thanks, Sylvain for the info!
>
>So, I think we should not release today, switch to EHCache, test
>it over the weekend and then release on monday or tuesday.
>  
>

+1 ! Persistent cache is a must-have.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


RE: Release tomorrow?

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
 
> Le 14 mai 04, à 10:50, Sylvain Wallez a écrit :
> > ...What's the status of EHCache and JCS? Can't we consider 
> one of them 
> > as the default persistent store?
> 
> I think there's an issue with JCS, something at shutdown IIRC?
> And, also IIRC, Unico reported using EHCache with no problems.
> 
Ah, thanks, Sylvain for the info!

So, I think we should not release today, switch to EHCache, test
it over the weekend and then release on monday or tuesday.

Carsten


Re: Release tomorrow?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 mai 04, à 10:50, Sylvain Wallez a écrit :
> ...What's the status of EHCache and JCS? Can't we consider one of them 
> as the default persistent store?

I think there's an issue with JCS, something at shutdown IIRC?
And, also IIRC, Unico reported using EHCache with no problems.

-Bertrand


Re: Release tomorrow?

Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:

>Bertrand Delacretaz wrote: 
>  
>
>>To me the most serious issue is bugzilla 26753 (persistent 
>>store corruption),
>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
>>
>>But IIUC disabling the persistent store is the easiest 
>>workaround, if so it wouldn't it be better to ship the 
>>release with the persistent store disabled?
>>
>>    
>>
>Hmm, yes this is a serious issue - but we have this in all 
>2.1.x releases :) - so perhaps we should simply add this
>to the "known issues" category as well.
>  
>

Mmmh... no, this was revealed by 2.1.4, after I cleaned up the use of 
store components in the code. Before 2.1.4, that bug was hidden since 
IIRC content was actually never fetched from the persistent cache...

So this really is a serious issue, and releasing a version without a 
persistent cache is an IMO an important functionnal limitation.

What's the status of EHCache and JCS? Can't we consider one of them as 
the default persistent store?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


RE: Release tomorrow?

Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> Bertrand Delacretaz wrote:
>>
>> Le 14 mai 04, à 09:59, Carsten Ziegeler a écrit :
>>
>> >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
>> >>
>> >> ...
>> > Hmm, yes this is a serious issue - but we have this in all 2.1.x
>> > releases :) - so perhaps we should simply add this to the "known
>> > issues" category as well.
>>
>> Ok - but isn't there a super-easy way of disabling the
>> persistent store by default? Not sure about this, but if it's
>> just two lines it might be better.
>>
> I think: no :) - this is an old issue that doesn't affect everyone
> and if we turn off the persistent store everyone might forget about
> it.
> Anyway, discussing this between the two of us doesn't really help :)

While you are talking, we listen ;-)

To me this is a serious blocker. It would not help to build a serious
reputation for the overall Cocoon community. Cocoon is a serious project
with great people and I think we cannot release code that we know is bad
or that could have a big performance issue.

>From the user view, knowing that, the question is: who will use it?
And if the answer is: noone, then why release?

I propose to stop the release for a week or so and try to solve the issue
first.

Best Regards,

Antonio Gallardo


RE: Release tomorrow?

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
> 
> Le 14 mai 04, à 09:59, Carsten Ziegeler a écrit :
> 
> >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
> >>
> >> ...
> > Hmm, yes this is a serious issue - but we have this in all 2.1.x 
> > releases :) - so perhaps we should simply add this to the "known 
> > issues" category as well.
> 
> Ok - but isn't there a super-easy way of disabling the 
> persistent store by default? Not sure about this, but if it's 
> just two lines it might be better.
> 
I think: no :) - this is an old issue that doesn't affect everyone
and if we turn off the persistent store everyone might forget about
it.
Anyway, discussing this between the two of us doesn't really help :)
I will start assembling the release in approx. one hour - if someone
thinks disabling is the way to go, disable it but please add
a comment to the updating docs!

> 
> Good question ;-)
> At the very least it could be some notes/bugzilla numbers at 
> the bottom of welcome.xml?

I added a section to the updating docs which should be the first
document users should read if they update.
(Perhaps there might be a better place, but finding the best place
shouldn't prevent us from releasing today).

So what else should go into that?

Carsten


Re: Release tomorrow?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 mai 04, à 09:59, Carsten Ziegeler a écrit :

>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
>>
>> ...
> Hmm, yes this is a serious issue - but we have this in all
> 2.1.x releases :) - so perhaps we should simply add this
> to the "known issues" category as well.

Ok - but isn't there a super-easy way of disabling the persistent store 
by default? Not sure about this, but if it's just two lines it might be 
better.

> ...Ehm, where is this "known issues" section?

Good question ;-)
At the very least it could be some notes/bugzilla numbers at the bottom 
of welcome.xml?
-Bertrand


RE: Release tomorrow?

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote: 
> 
> To me the most serious issue is bugzilla 26753 (persistent 
> store corruption),
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753
> 
> But IIUC disabling the persistent store is the easiest 
> workaround, if so it wouldn't it be better to ship the 
> release with the persistent store disabled?
> 
Hmm, yes this is a serious issue - but we have this in all 
2.1.x releases :) - so perhaps we should simply add this
to the "known issues" category as well.

> David also mentions
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28680, IMHO 
> this could go into the "known issues" category.

Yes, together with the problems in the logging configuration,
Joerg mentioned. 

Ehm, where is this "known issues" section?

> 
> Other points do not seem to seriously affect a release.
> 
Yes, agreed.

Carsten


Re: Release tomorrow?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 mai 04, à 09:35, Carsten Ziegeler a écrit :

> Ok, so this is "fixed" for the release :)
>
> What about the items that David mentions?
>
> http://marc.theaimsgroup.com/?t=108358572500003

To me the most serious issue is bugzilla 26753 (persistent store 
corruption),
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26753

But IIUC disabling the persistent store is the easiest workaround, if 
so it wouldn't it be better to ship the release with the persistent 
store disabled?

David also mentions 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28680, IMHO this 
could go into the "known issues" category.

Other points do not seem to seriously affect a release.

-Bertrand


RE: Release tomorrow?

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, so this is "fixed" for the release :)

What about the items that David mentions?

http://marc.theaimsgroup.com/?t=108358572500003

Carsten

 

> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org] 
> Sent: Friday, May 14, 2004 9:26 AM
> To: dev@cocoon.apache.org
> Subject: Re: Release tomorrow?
> 
> Le 14 mai 04, à 09:13, Ugo Cei a écrit :
> 
> > ..Personally, I wouldn't want to ship a release with a broken 
> > testsuite. I know it amounts to sweeping it under the rug, but I'd 
> > rather remove the testcase temporarily for the release and 
> put it back 
> > just after...
> 
> Agreed - removing or replacing the test by a prominent 
> message saying "test disabled due to issue xyz" (ideally a 
> bugzilla number) sounds good.
> -Bertrand
> 


Re: Release tomorrow?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 mai 04, à 09:13, Ugo Cei a écrit :

> ..Personally, I wouldn't want to ship a release with a broken 
> testsuite. I know it amounts to sweeping it under the rug, but I'd 
> rather remove the testcase temporarily for the release and put it back 
> just after...

Agreed - removing or replacing the test by a prominent message saying 
"test disabled due to issue xyz" (ideally a bugzilla number) sounds 
good.
-Bertrand


Re: Release tomorrow?

Posted by Ugo Cei <u....@cbim.it>.
Bertrand Delacretaz wrote:
> Note that, if it's been wrong for a long time, it does not make a 
> difference for the release.

Personally, I wouldn't want to ship a release with a broken testsuite. I 
know it amounts to sweeping it under the rug, but I'd rather remove the 
testcase temporarily for the release and put it back just after.

I might try to fix the problem, but not today and I'm no Avalon guru by 
any means.

	Ugo



Re: Release tomorrow?

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 14 mai 04, à 08:32, Upayavira a écrit :

> Ugo Cei wrote:
> ...
>>>> TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED
>
> ...Yup. This test case just shows up something that has been wrong for 
> a _very_ long time. I'm reluctant to remove it, as that which it shows 
> up should be fixed rather than ignored.

Note that, if it's been wrong for a long time, it does not make a 
difference for the release.
-Bertrand


Re: Release tomorrow?

Posted by Upayavira <uv...@upaya.co.uk>.
Ugo Cei wrote:

> Il giorno 13/mag/04, alle 23:57, Joerg Heinicke ha scritto:
>
>>> Running org.apache.cocoon.bean.CocoonBeanTestCase
>>> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec
>>> TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED
>>
>>
>> Some info on it from Upayavira:
>> http://marc.theaimsgroup.com/?t=108011464200003&r=1&w=4
>
>
> We just need an Avalon guru, then ;-).

Yup. This test case just shows up something that has been wrong for a 
_very_ long time. I'm reluctant to remove it, as that which it shows up 
should be fixed rather than ignored.

Either I finally work it out (which probably won't happen in a hurry) or 
someone else looks into it. How to remove reliance upon the servlet.jar. 
Hmm.

Regards, Upayavira




Re: Release tomorrow?

Posted by Ugo Cei <ug...@apache.org>.
Il giorno 13/mag/04, alle 23:57, Joerg Heinicke ha scritto:

>> Running org.apache.cocoon.bean.CocoonBeanTestCase
>> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec
>> TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED
>
> Some info on it from Upayavira:
> http://marc.theaimsgroup.com/?t=108011464200003&r=1&w=4

We just need an Avalon guru, then ;-).

-- 
Ugo Cei - http://beblogging.com/


Re: Release tomorrow?

Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.05.2004 23:40, Ugo Cei wrote:

>> I haven't read all mails from this week yet, but it seems
>> that nothing is preventing us from a release tomorrow.
>>
>> Or did I oversee something?
> 
> How about this?
> 
> Running org.apache.cocoon.bean.CocoonBeanTestCase
> Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec
> TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED

Some info on it from Upayavira:
http://marc.theaimsgroup.com/?t=108011464200003&r=1&w=4

Joerg

Re: Release tomorrow?

Posted by Ugo Cei <ug...@apache.org>.
Il giorno 13/mag/04, alle 20:52, Carsten Ziegeler ha scritto:

> I haven't read all mails from this week yet, but it seems
> that nothing is preventing us from a release tomorrow.
>
> Or did I oversee something?
>

How about this?

Running org.apache.cocoon.bean.CocoonBeanTestCase
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,864 sec
TEST org.apache.cocoon.bean.CocoonBeanTestCase FAILED

-- 
Ugo Cei - http://beblogging.com/


Re: Release tomorrow?

Posted by David Crossley <cr...@apache.org>.
Carsten Ziegeler wrote:
> I haven't read all mails from this week yet, but it seems
> that nothing is preventing us from a release tomorrow.
> 
> Or did I oversee something?

The other thread that discussed the release has
some outstanding issues:
http://marc.theaimsgroup.com/?t=108358572500003

--David


Re: Release tomorrow?

Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler dijo:
> I haven't read all mails from this week yet, but it seems
> that nothing is preventing us from a release tomorrow.
>
> Or did I oversee something?

Not sure, but the petstore sample is not working for me. I cannot switch
to other views (see the technology select combobox).

Best Regards,

Antonio Gallardo


Re: Release tomorrow?

Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 14.05.2004 03:07, Antonio Gallardo wrote:
>
>>>And my forms did no longer work due to a classpath issue. Cocoon
>>>delivers common collections 3.0, Tomcat has an older version of this jar
>>>in common/lib - and Tomcat seems to prefer its own one. Is that correct
>>>behaviour? How shall I get my version of a jar in the webapp to be used?
>>>Not every webapp has a paranoid classloader ... thanks again to Sylvain
>>>for that nice piece of work :)
>>
>>
>> Hi Jörg:
>>
>> Are you tried to replace the common-collection from Cocoon in Tomcat?
>
> Yes, and that works of course, but is not an option. What about the next
> webapp using yet another version of this jar? This Tomcat behaviour
> forces me to use the same collection jar for every webapp - that's why I
> asked if this is correct behaviour at all.

I think this is part of the jar hell. I understand the concerns about
changing the default delivered by Tomcat, but we are doing the same with
xerces. Can this be seen as a non-option too? If we try to be practical,
the best we can do is change the old lib distributed by Tomcat.

>> What version of Tomcat are u using?
>
> 4.1.29

We are using Apache Tomcat/5.0.24 and don't have this kind of problems.

I hope you found a solution to the problem. :-D

Best Regards,

Antonio Gallardo

Re: Release tomorrow?

Posted by Joerg Heinicke <jo...@gmx.de>.
On 14.05.2004 03:07, Antonio Gallardo wrote:

>>And my forms did no longer work due to a classpath issue. Cocoon
>>delivers common collections 3.0, Tomcat has an older version of this jar
>>in common/lib - and Tomcat seems to prefer its own one. Is that correct
>>behaviour? How shall I get my version of a jar in the webapp to be used?
>>Not every webapp has a paranoid classloader ... thanks again to Sylvain
>>for that nice piece of work :)
> 
> 
> Hi Jörg:
> 
> Are you tried to replace the common-collection from Cocoon in Tomcat?

Yes, and that works of course, but is not an option. What about the next 
webapp using yet another version of this jar? This Tomcat behaviour 
forces me to use the same collection jar for every webapp - that's why I 
asked if this is correct behaviour at all.

> What version of Tomcat are u using?

4.1.29

Joerg

Re: Release tomorrow?

Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 13.05.2004 20:52, Carsten Ziegeler wrote:
>
>> I haven't read all mails from this week yet, but it seems
>> that nothing is preventing us from a release tomorrow.
>>
>> Or did I oversee something?
>
> Nothing that I'm aware of.
>
> BTW, I already upgraded my project at work today to
> 2.1.5-almostReleased. My 2.1.4 logkit.xconf did no longer work because
> of missing this change:
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/webapp/WEB-INF/logkit.xconf?r1=1.7&r2=1.8&diff_format=h
> Cocoon failed to initialize the logging. And I thought first it was the
> "every logger manager" commit ...
>
> And my forms did no longer work due to a classpath issue. Cocoon
> delivers common collections 3.0, Tomcat has an older version of this jar
> in common/lib - and Tomcat seems to prefer its own one. Is that correct
> behaviour? How shall I get my version of a jar in the webapp to be used?
> Not every webapp has a paranoid classloader ... thanks again to Sylvain
> for that nice piece of work :)

Hi Jörg:

Are you tried to replace the common-collection from Cocoon in Tomcat? What
version of Tomcat are u using?

Best Regards,

Antonio Gallardo


Re: Release tomorrow?

Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.05.2004 20:52, Carsten Ziegeler wrote:

> I haven't read all mails from this week yet, but it seems
> that nothing is preventing us from a release tomorrow.
> 
> Or did I oversee something?

Nothing that I'm aware of.

BTW, I already upgraded my project at work today to 
2.1.5-almostReleased. My 2.1.4 logkit.xconf did no longer work because 
of missing this change: 
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/webapp/WEB-INF/logkit.xconf?r1=1.7&r2=1.8&diff_format=h
Cocoon failed to initialize the logging. And I thought first it was the 
"every logger manager" commit ...

And my forms did no longer work due to a classpath issue. Cocoon 
delivers common collections 3.0, Tomcat has an older version of this jar 
in common/lib - and Tomcat seems to prefer its own one. Is that correct 
behaviour? How shall I get my version of a jar in the webapp to be used? 
Not every webapp has a paranoid classloader ... thanks again to Sylvain 
for that nice piece of work :)

Joerg