headers
Carsten Ziegeler | 1 Jun 2006 08:27
Picon
Favicon

Re: [continuum] BUILD FAILURE: Core Webapp

Ups, of course the new test case is the reason for cocoon core to fail
building, not core webapp.

Carsten
Jorg Heymans wrote:
> Carsten Ziegeler wrote:
> 
>> I added a test case for this bug, so this is the reason why the build is
>> currently failing.
> 
> good to know, tnx for the info.
> 
> 
> Jorg
> 
> 

--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 0 comments |
headers
Bertrand Delacretaz | 1 Jun 2006 08:56
Picon
Favicon
Gravatar

Re: GetTogether

On 5/26/06, Ralph Goers <Ralph.Goers <at> dslextreme.com> wrote:

> It looks like ApacheCon US is going to be Oct 9-13 in Austin, TX...
> ...I'm just wondering if it would be possible to
> overlap the two and do the GetTogether in conjunction with the training
> days of ApacheCon.

FWIW, I don't think I would travel to Austin for a GetTogether only.

But it might be a good option for people attending ApacheCon US (dunno
if I'll be there yet).

Note that there's usually a Hackathon in parallel with the tutorial
days, so an informal get together is easy to setup anyway.

-Bertrand
Permalink | Reply | 0 comments |
headers
Antonio Gallardo | 1 Jun 2006 09:10
Favicon

Re: poi hssf-serializer built in limitation

Hi Marc,

Jira is now our bug tracking system.

Best Regards,

Antonio Gallardo.

Marc Portier escribió:
> Hi there,
>
> I've ran accross a hard-coded limit in our ms-excel-format serizalizer
> (and it looks like I'm the second one :-)
>  http://issues.apache.org/bugzilla/show_bug.cgi?id=24490 )
>
> $ find -name EPStyleRegion.java |xargs cat -n |head -65|tail
> $ find -name EPStyleRegion.java |xargs cat -n |head -102|tail -16
>
> It causes style-formatting-regions to be ignored if they span more then
> 2000 cells.
>
> Apart from the (to me quite dense) remarks in the code there is little
> to be found about what are the actual motives for this, or how we could
> assess if the limitations still stand in todays world or not.
>
> In fact, in terms of code-evolution I could only find this limit
> appeared to be in the original commit already.
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103825320630080&w=2
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Ziegeler | 1 Jun 2006 11:27
Picon
Favicon

Please review changes to WildcardHelper

Hi,

I just fixed the bug in our wildcard helper. The problem was the
following: if a pattern ends with a constant string (like ".xml")
and the uri in question contained this constant twice (like
("hello.xml.xml") the pattern did not match.

I added a junit test case for this and now the tests all succeed.
BUT, while looking at the wildcard helper code, I found several smelling
code place, like unreachable code etc. which I cleaned up.
In addition the fix for the bug "seems" to work, but I'm not 100% sure
if it breaks something else.
So, it would be great if others can review the code.

I'm not sure if the code of the wildcard helper is correct at all; I
guess there are still other cases where the pattern does not match
although it should. So I think we have to rewrite the code anyway. One
idea I had is to transform the pattern into a regexp and then use
one of the regexp libraries for matching.

WDYT
Carsten

--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 33 comments |
headers
Reinhard Poetz | 1 Jun 2006 11:34
Picon
Favicon

Re: Please review changes to WildcardHelper

Carsten Ziegeler wrote:

> I just fixed the bug in our wildcard helper. The problem was the
> following: if a pattern ends with a constant string (like ".xml")
> and the uri in question contained this constant twice (like
> ("hello.xml.xml") the pattern did not match.
> 
> I added a junit test case for this and now the tests all succeed.
> BUT, while looking at the wildcard helper code, I found several smelling
> code place, like unreachable code etc. which I cleaned up.
> In addition the fix for the bug "seems" to work, but I'm not 100% sure
> if it breaks something else.
> So, it would be great if others can review the code.

Great!!! I was wondering who really understands this class ;-) I'm happy that 
it's at least one of us.

My following proposal might sound strange but I would like to see the 
WildcardHelper within a separate module as I found several usecases outside of 
Cocoon and always had to copy it. On the other hand the WildcardHelper is only 
one single class. WDOT?

--

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carsten Ziegeler | 1 Jun 2006 12:01
Picon
Favicon

Re: Please review changes to WildcardHelper

Reinhard Poetz wrote:

> Great!!! I was wondering who really understands this class ;-) I'm happy that 
> it's at least one of us.
Hehe, thanks for the compliments, but it took me some time to understand
*parts* of it :)

> 
> My following proposal might sound strange but I would like to see the 
> WildcardHelper within a separate module as I found several usecases outside of 
> Cocoon and always had to copy it. On the other hand the WildcardHelper is only 
> one single class. WDOT?

Hmm, now, I don't think that it's Cocoon's objective to provide common
utility classes,
so what about contributing it to commons-lang?

Carsten

--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 0 comments |
headers
Bruno Dumon | 1 Jun 2006 15:49
Favicon

Re: Please review changes to WildcardHelper

On Thu, 2006-06-01 at 11:27 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> I just fixed the bug in our wildcard helper. The problem was the
> following: if a pattern ends with a constant string (like ".xml")
> and the uri in question contained this constant twice (like
> ("hello.xml.xml") the pattern did not match.
> 
> I added a junit test case for this and now the tests all succeed.
> BUT, while looking at the wildcard helper code, I found several smelling
> code place, like unreachable code etc. which I cleaned up.
> In addition the fix for the bug "seems" to work, but I'm not 100% sure
> if it breaks something else.
> So, it would be great if others can review the code.
> 
> I'm not sure if the code of the wildcard helper is correct at all; I
> guess there are still other cases where the pattern does not match
> although it should. So I think we have to rewrite the code anyway. One
> idea I had is to transform the pattern into a regexp and then use
> one of the regexp libraries for matching.

This won't be of much help, but I thought the wildcard matcher is
significantly faster than regexpes.

PS: I like the idea of moving it to commons-lang. I've used it on
several occasions outside Cocoon.

--

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
(Continue reading)

Permalink | Reply | 5 comments |
headers
Carsten Ziegeler | 1 Jun 2006 15:59
Picon
Favicon

Re: Please review changes to WildcardHelper

Bruno Dumon wrote:
> On Thu, 2006-06-01 at 11:27 +0200, Carsten Ziegeler wrote:
>> I'm not sure if the code of the wildcard helper is correct at all; I
>> guess there are still other cases where the pattern does not match
>> although it should. So I think we have to rewrite the code anyway. One
>> idea I had is to transform the pattern into a regexp and then use
>> one of the regexp libraries for matching.
> 
> This won't be of much help, but I thought the wildcard matcher is
> significantly faster than regexpes.
> 
Yes, the wildcard matcher is indeed faster (although the question is if
it really makes a difference for the performance of the whole request).
Why do you think that using regexp won't be of much help? The regexp
libraries are tried and trusted.

Carsten
--

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Permalink | Reply | 3 comments |
headers
Bruno Dumon | 1 Jun 2006 16:28
Favicon

Re: Please review changes to WildcardHelper

On Thu, 2006-06-01 at 15:59 +0200, Carsten Ziegeler wrote:
> Bruno Dumon wrote:
> > On Thu, 2006-06-01 at 11:27 +0200, Carsten Ziegeler wrote:
> >> I'm not sure if the code of the wildcard helper is correct at all; I
> >> guess there are still other cases where the pattern does not match
> >> although it should. So I think we have to rewrite the code anyway. One
> >> idea I had is to transform the pattern into a regexp and then use
> >> one of the regexp libraries for matching.
> > 
> > This won't be of much help, but I thought the wildcard matcher is
> > significantly faster than regexpes.
> > 
> Yes, the wildcard matcher is indeed faster (although the question is if
> it really makes a difference for the performance of the whole request).
> Why do you think that using regexp won't be of much help? The regexp
> libraries are tried and trusted.

The "won't be of much help" refered to my remark, not to the regexp
libraries ;-)

--

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno <at> outerthought.org                          bruno <at> apache.org
Permalink | Reply | 0 comments |
headers
Reinhard Poetz | 1 Jun 2006 16:50
Picon
Favicon

Re: Please review changes to WildcardHelper

Carsten Ziegeler wrote:

> Yes, the wildcard matcher is indeed faster (although the question is if
> it really makes a difference for the performance of the whole request).

I _seem to remember_ that loooong time ago Stefano did some profiling and one of 
the results was that in his test scenario about 10 % of the time was consumed in 
matchers. Maybe somebody else has some newer figures.

--

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Permalink | Reply | 1 comment |

Gmane