Re: [ESQL] Improvement....

[Torsten Curdt]

Niclas Hedhman wrote:

On Monday 27 January 2003 07:06, Torsten Curdt wrote:


What do the database to try to find the 6th row?

I think the answer is: scan the rest of the database after finding the
ONLY 5 rows that already exist.


No :) ...be sure - it doesn't



Well, that depends on the WHERE clause. For instance;

WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;

definately go through every record, whether the fields are indexed or not.


Aaah - now I got you guys! (sorry for being that slow ;)

Antonio, how comes that you always know you have 5 rows? This sounds 
quite unusual to me...
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Niclas Hedhman]

On Monday 27 January 2003 16:01, Torsten Curdt wrote:
> Niclas Hedhman wrote:
> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> >>>What do the database to try to find the 6th row?
> >>>
> >>>I think the answer is: scan the rest of the database after finding the
> >>>ONLY 5 rows that already exist.
> >>
> >>No :) ...be sure - it doesn't
> >
> > Well, that depends on the WHERE clause. For instance;
> >
> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
> >
> > definately go through every record, whether the fields are indexed or
> > not.
>
> Aaah - now I got you guys! (sorry for being that slow ;)
>
> Antonio, how comes that you always know you have 5 rows? This sounds
> quite unusual to me...

I can answer part of that;

1. You have the "count" from somewhere else.
2. You know that objects of type X has N attributes, always fixed.
3. I have 10,000,000 random records of N types. I want the first one of each 
type.

Sure there are other cases.

Niclas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Antonio Gallardo]

Niclas Hedhman dijo:
> On Monday 27 January 2003 16:01, Torsten Curdt wrote:
>> Niclas Hedhman wrote:
>> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
>> >>>What do the database to try to find the 6th row?
>> >>>
>> >>>I think the answer is: scan the rest of the database after finding
>> the ONLY 5 rows that already exist.
>> >>
>> >>No :) ...be sure - it doesn't
>> >
>> > Well, that depends on the WHERE clause. For instance;
>> >
>> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
>> >
>> > definately go through every record, whether the fields are indexed
>> or not.
>>
>> Aaah - now I got you guys! (sorry for being that slow ;)
>>
>> Antonio, how comes that you always know you have 5 rows? This sounds
>> quite unusual to me...
>
> I can answer part of that;
>
> 1. You have the "count" from somewhere else.
> 2. You know that objects of type X has N attributes, always fixed. 3. I
> have 10,000,000 random records of N types. I want the first one of each
> type.
>
> Sure there are other cases.
>
> Niclas

Thanks Niclas!

This is the example I tried to explain:

I have a table that store the status of some tickets. You always know how
many status there can be. If you said:

1-Open
2-Close
3-Invalid

Then if you want to show the history, you will ask for LIMIT 3, but the
database will try to find the 4th row after finding the only 3 that can
exist.

This is why I told this is a performance issue. Not an error.

Antonio Gallardo
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Pierpaolo Fumagalli as a cocoon committer

[Christian Haul]

On 26.Jan.2003 -- 05:30 PM, Nicola Ken Barozzi wrote:
> 
> Oh boy, this is fun...
> 
> I'd like to propose Pierpaolo Fumagalli, aka [EMAIL PROTECTED], aka Mr 
> Bugzilla notwithstanding, aka many other things as an active cocoon 
> committer, back from emeritus status.

+1 welcome back (please ignore duplicate if the original mail passes
   Mr. Spamfilter Nicola since posted from dialup ;-)

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Christian Haul]

On 27.Jan.2003 -- 02:49 AM, Antonio Gallardo wrote:
> Niclas Hedhman dijo:
> > On Monday 27 January 2003 16:01, Torsten Curdt wrote:
> >> Niclas Hedhman wrote:
> >> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
> >> >>>What do the database to try to find the 6th row?
> >> >>>
> >> >>>I think the answer is: scan the rest of the database after finding
> >> the ONLY 5 rows that already exist.
> >> >>
> >> >>No :) ...be sure - it doesn't
> >> >
> >> > Well, that depends on the WHERE clause. For instance;
> >> >
> >> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
> >> >
> >> > definately go through every record, whether the fields are indexed
> >> or not.

That's really bad! No way to refactor the schema or the query? Or use
a differen DBMS? E.g. in INFORMIX you can create an index based on a
user defined function...

> I have a table that store the status of some tickets. You always know how
> many status there can be. If you said:
> 
> 1-Open
> 2-Close
> 3-Invalid
> 
> Then if you want to show the history, you will ask for LIMIT 3, but the
> database will try to find the 4th row after finding the only 3 that can
> exist.
> 
> This is why I told this is a performance issue. Not an error.

Again I believe an index would help a lot more. With bad luck your
three rows are spread all over the table and you're going to have a
nearly complete table scan anyways.

And if it does improve performance, why do you want to use the
esql:limit tag instead of altering the SQL statement?

Anyway, since you offered to produce a patch, we should consider it.

My 2¢

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[GUMP] Build Failure - xml-cocoon2

[Sam Ruby]

This email is autogenerated from the output from:
<http://cvs.apache.org/builds/gump/2003-01-27/xml-cocoon2.html>


Buildfile: build.xml

init:
 [echo] --
 [echo] Apache Cocoon 20030127 [1999-2003]  
 [echo] --
 [echo] Building with Apache Ant version 1.6alpha compiled on January 27 2003
 [echo] using build file /home/rubys/jakarta/xml-cocoon2/build.xml
 [echo] --
 [echo]  WARNING: 
 [echo]This build is targeted for use with JVM 1.4
 [echo]   
 [echo]Using this build on a virtual machine other than the one   
 [echo]it is targeted for may result in runtime errors.  
 [echo]   
 [echo] --
  [taskdef] dropping /home/rubys/jakarta/jakarta-slide/dist/slide/lib/slide-kernel.jar 
from path as it doesn't exist
  [taskdef] dropping /home/rubys/php/lib/php/phpsrvlt.jar from path as it doesn't exist
  [taskdef] dropping /home/rubys/jakarta/xml-cocoon2/build/cocoon/classes from path as 
it doesn't exist
  [taskdef] dropping /home/rubys/jakarta/xml-cocoon2/tools/anttasks from path as it 
doesn't exist
[mkdir] Created dir: /home/rubys/jakarta/xml-cocoon2/tools/anttasks
[javac] Compiling 2 source files to /home/rubys/jakarta/xml-cocoon2/tools/anttasks
[javac] 9 warnings

optional-tests:
 [echo] Testing for optional components

bsf-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package BSF are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  BSF is required for the script action.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the BSF package from 
http://oss.software.ibm.com/developerworks/projects/bsf/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

rhino-warn:

jfor-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JFOR are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JFOR is required for the fo2rtf serializer.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the JFOR package from http://www.jfor.org/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

xmldb-warn:

php-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package PHP are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  PHP is required for the php generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get the PHP servlet (phpsrvlt.jar) from http://www.php.net/ and place 
the jar in the lib/optional dir
 [echo] *
 [echo] ***

naming-warn:

svg-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Batik are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Batik is required for the svg serializers.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Batik from http://xml.apache.org/batik/ and place the jar in the 
lib/optional dir
 [echo] *
 [echo] ***

tidy-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package JTidy are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  JTidy is required for the html generator.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get JTidy from http://sourceforge.net/projects/jtidy/ and place the jar 
in the lib/optional dir
 [echo] *
 [echo] ***

maybeupload-warn:

lucene-warn:

op-warning:
 [echo] **
 [echo] *
 [echo] *  Classes of the optional package Lucene are not 
 [echo] *  available. Apache Cocoon builds without them.
 [echo] *
 [echo] *  Lucene is required for the Cocoon searches.
 [echo] *
 [echo] *  Recovery:
 [echo] *  Get Lucene from http://jakarta.apache.org/lucene/ and place the jar in 
the lib/optional di

Re: [VOTE] Pierpaolo Fumagalli as a cocoon committer

[Stephan Michels]

On Mon, 27 Jan 2003, Christian Haul wrote:

> On 26.Jan.2003 -- 05:30 PM, Nicola Ken Barozzi wrote:
> >
> > Oh boy, this is fun...
> >
> > I'd like to propose Pierpaolo Fumagalli, aka [EMAIL PROTECTED], aka Mr
> > Bugzilla notwithstanding, aka many other things as an active cocoon
> > committer, back from emeritus status.
>
> +1 welcome back (please ignore duplicate if the original mail passes
>Mr. Spamfilter Nicola since posted from dialup ;-)

+1

Stephan Michels.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Antonio Gallardo]

Christian Haul dijo:
> On 27.Jan.2003 -- 02:49 AM, Antonio Gallardo wrote:
>> Niclas Hedhman dijo:
>> > On Monday 27 January 2003 16:01, Torsten Curdt wrote:
>> >> Niclas Hedhman wrote:
>> >> > On Monday 27 January 2003 07:06, Torsten Curdt wrote:
>> >> >>>What do the database to try to find the 6th row?
>> >> >>>
>> >> >>>I think the answer is: scan the rest of the database after
>> finding
>> >> the ONLY 5 rows that already exist.
>> >> >>
>> >> >>No :) ...be sure - it doesn't
>> >> >
>> >> > Well, that depends on the WHERE clause. For instance;
>> >> >
>> >> > WHERE SQRT(  SQ( a - b ) + SQ( c - d ) + SQ( e - f ) ) < g ;
>> >> >
>> >> > definately go through every record, whether the fields are
>> indexed
>> >> or not.
>
> That's really bad! No way to refactor the schema or the query? Or use a
> differen DBMS? E.g. in INFORMIX you can create an index based on a user
> defined function...
>
>> I have a table that store the status of some tickets. You always know
>> how many status there can be. If you said:
>>
>> 1-Open
>> 2-Close
>> 3-Invalid
>>
>> Then if you want to show the history, you will ask for LIMIT 3, but
>> the database will try to find the 4th row after finding the only 3
>> that can exist.
>>
>> This is why I told this is a performance issue. Not an error.
>
> Again I believe an index would help a lot more. With bad luck your three
> rows are spread all over the table and you're going to have a nearly
> complete table scan anyways.

This is not bad luck. ;-)
I cannot find an easy example. My queries envolves 5 or 7 tables. I have a
status table. This table contains the date, ticket and status. This is
because sometimes you search by status.

I recently read that this is not a good idea indexing a field with small
posibles values in a big table. That is my case. I am using Postgres, but
in general this is true.

Niclas pointed a example. I know this is not a good code, but the idea is
there. The point is: I know there are only 5 row, but the LIMIT clausule
will be written as:

LIMIT 6.

That will force to search the entire table for a row that never exists.

>
> And if it does improve performance, why do you want to use the
> esql:limit tag instead of altering the SQL statement?

How can I alter the statement? I can write LIMIT 5, but the code will
rewrite it to LIMIT 6! This is the point. Sometimes we need to assure that
the code write LIMIT 5 not LIMIT 6.

This is why I suggested to just check if there is the 
tag. If the tag is there, that means that the programmer is not sure if
there are or not more results.

Please think about this issue.

Best Regards,

Antonio Gallardo.

P.S: My english is very poor, sorry that I can not explain better this issue.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Torsten Curdt]

Thanks Niclas!


:)


This is the example I tried to explain:

I have a table that store the status of some tickets. You always know how
many status there can be. If you said:

1-Open
2-Close
3-Invalid

Then if you want to show the history, you will ask for LIMIT 3, but the
database will try to find the 4th row after finding the only 3 that can
exist.


Well, this might become a little off-topic...
...but wouldn't it be better to change your db design?


This is why I told this is a performance issue. Not an error.


Sure - the question is only how to integrate this easily since we would 
need to pass the information (more-results or not) from the logicsheet 
into the classes.

And please - no ugly hack like "setXXX"
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Remove old releases, Fwd: need some more web space conservatismagain

[Stefano Mazzocchi]

Vadim Gritsenko wrote:

Stefano Mazzocchi wrote:


Vadim Gritsenko wrote:


All:

Is it ok if I remove old Cocoon releases from the xml.apache.org?
To be precise:

cocoon-1.7.x
cocoon-1.8
cocoon-2.0
cocoon-2.0.1
cocoon-2.0.2
cocoon-2.0.3




-1, Brian asked for space conservatism, but that doesn't mean to 
destroy the history of this project.

he refers to removing nighly builds, ancient alpha and beta versions. 
releases should stay right where they are.




And he refers to "every minor release and beta version". What about 
removing those? We have betas and candidate releases:

Cocoon-2.0b1.zip
Cocoon-2.0b2.zip
Cocoon-2.0rc1a.zip
cocoon-2.0rc2.zip

no problem removing those.


We have minor releases:

cocoon-2.0.1
cocoon-2.0.2
cocoon-2.0.3
cocoon-2.0.4


those are not minor releases. Those are "releases", a release is 
something that you might build your stuff upon. It's a contract. Books, 
for example, use these contracts for years (before a new edition 
outdates another one, but that edition can still be used)

We can leave latest and previous release - 2.0.3 and 2.0.4 - and archive 
the rest on cocoondev.org.

I would like to keep all of our final releases in one place. I like 
kernel.org that does that. I consider this historical value and also a 
sense of respect to all those who may base their software on a version 
of Cocoon and let it run for 20 years without changing it.

Cocoon distribution is not the lastest version, is the *entire* 
collection of releases.

Damn, we advocate that open source software removes lock-ins, but how 
about decades-long ones?

I'm strongly against fragmenting our distribution space on different 
machines.

Forever. 



Generally speaking, I agree. Especially if they could not be reproduced 
from CVS. Moreover, all releases should be available and not only the 
set we have now (see  in this thread). But given limited 
hardware, I think it's ok to archive it on another machine.

What do you think?

I say we do this incrementally:

1) first we remove all the betas, alphas, release candidates from xml 
and jakarta

2) if the problem persists, we iterate again.

for the future, we'll think about ways to decentralize the distribution 
system even from the source.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[vote] Commit access back for Pier

[Stefano Mazzocchi]

Pier Fumagalli wrote:

On 23/1/03 19:09, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:



Geoff Howard wrote:



Is there a general level of comfort that the build requires this much
memory??


I'm personally not that comfortable (expecially since I only have 192Mb
on my machine and can't even upgrade it anymore :/) but the cocoon build
system is huge and very complex so it doesn't surprise me that it needs
that much memory.

but any patch that will lower memory use will be appreciated.



Two stages patch (verified on my box locally, so that might not help in all
cases): apply the attached patch to build.xml, and update the ant libraries
to 1.5.1.

Worked for me...


I'm lazy.

What about resorting your commit access so you can do it yourself?

I mean, you were the one who wrote the first Cocoon2 code in the first 
place and you are working to patch cocoon for jetty stuff. I don't want 
to be flooded with your patches :)

People, what do you think?

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Exciting Calendar Announcement (WAS [OT] Cocoon Calendar (WASRE: HAPPY BIRTHDAY STEFANO!))

[Stefano Mazzocchi]

Torsten Curdt wrote:


Please don't take it personal Stefano - with that color you looked like 
being on drugs or something ;)

personal? who told you I already wasn't? :)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ANNONUNCEMENT] ChartTransformer 0.0.4 released

[Stefano Mazzocchi]

Luca Morandini wrote:

Antonio,

thanks for your appreciation.

We'd like to insert it into the next release of Cocoon, but we're not committers :(   moreover, JFreeChart is (L)PGL.

In fairness though, I think licensing is not much of a problem, since (L)PGL is, more or less, equivalent to ASL and we could easily
provide some mock classes to prevent breaking the build, even in absence of the JFreeChart JARs.


Unfortunately, this is not the case. Those mock classes will have to be 
LGPL-ed as well and we won't be able to ship them with our stuff anyway 
(because of ASF policies)

LGPL was written for C code. Java, being highly dynamic, doesn't really 
distringuish between what is a library and what is your code. And the 
FSF likes it to be that way since they don't like java (being a non-free 
language from their point of view)

One day we'll have cocoon blocks and these problems will be solved but 
for now, we won't ship xGPL classes from official ASF distributions.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: People on the list.

[Stefano Mazzocchi]

Antonio Gallardo wrote:

Hi:

I am very happy today. I see that the project is growing very fast. This
is nice. Just the lastest greats events:

1-Cocoon 2.1 CVS more stable than ever (new cache subsystem)
2-Cocoon was raised to be a flag project of ASF!
3-New wiki.cocoondev.org
4-New calendar "Mens of Cocoon" that will improve marketing. ;-)
5-New transformer to generate charts!
6-Efforts in XForms and his connectivity with Databases.


don't forget flow! Cocoon is going to be remembered as the project who 
first project who introduced a serious architecture for 
continuation-based web development.

One day, you'll hear yourself saying "I remember the days when I had to 
save the state of my web application by myself in sessions" and you'll 
feel old, like when you hear people speaking about punch cards now.

We are writing technology history, people, one word at a time.

That events tell me that Cocoon is going in the right way! Well done guys!


Thank you. These comments are very appreciated.


Best Regards,

Antonio Gallardo.


P.S: Just curious. How many people are subscribed on the users and devel
list of Cocoon?


Last time I checked 600 on -dev and 1300 on -users.

Pier, you have access to those archives, can you update us?

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: ChartTransformer 0.0.4 urge a commiter!

[Stefano Mazzocchi]

Antonio Gallardo wrote:


I think it is time to start thinking in a plug-in technology for Cocoon.


Yes, it's time, but our avalon container is not good enough for that and 
avalon-dev is currently a big community mess.

I'm concerned. I really am. I'm about to fork and write my own avalon 
container for cocoon blocks and screw them this project can't wait 
another 6 months for a serious container to happen.

the block pressure will tear us apart.

As Steven pointed. It is inevitable to let people add more and more
components (generators, transformers, etc) to Cocoon.


True.


What about let people choice what they need? Then they will download only
the pieces of code they need. I know this currently can be done manually,
but we must find an easy and standard way to deploy the new components.
Like a "Lego" toy.


We already have a pretty detailed plan of action.

Look for "cocoon blocks" in the wiki.

But implementing it is hard, not technologically but politically. It 
must be done right from a community dynamic perspective and we have to 
get out with Cocoon 2.1 first.

But I'm wide open to suggestions on how to move this forward.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: People on the list.

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
>
> Antonio Gallardo wrote:
> > Hi:
> >
> > I am very happy today. I see that the project is growing very fast. This
> > is nice. Just the lastest greats events:
> >
> > 1-Cocoon 2.1 CVS more stable than ever (new cache subsystem)
> > 2-Cocoon was raised to be a flag project of ASF!
> > 3-New wiki.cocoondev.org
> > 4-New calendar "Mens of Cocoon" that will improve marketing. ;-)
> > 5-New transformer to generate charts!
> > 6-Efforts in XForms and his connectivity with Databases.
>
> don't forget flow! Cocoon is going to be remembered as the project who
> first project who introduced a serious architecture for
> continuation-based web development.
>
Sorry, to rain the party, but Cocoon is definetly not the first web
framework having continuations...those who talked to me about
flow might know to which framework I'm referring to...

But, we might be the first open source framework having continuations.

Carsten

Carsten Ziegeler
Open Source Group, S&N AG


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Torsten Curdt]

That's really bad! No way to refactor the schema or the query? Or use
a differen DBMS? E.g. in INFORMIX you can create an index based on a
user defined function...


...you were faster ;)
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: People on the list.

[Niclas Hedhman]

On Saturday 25 January 2003 22:05, Stefano Mazzocchi wrote:
> One day, you'll hear yourself saying "I remember the days when I had to
> save the state of my web application by myself in sessions" and you'll
> feel old, like when you hear people speaking about punch cards now.

Stefano, you must be younger than "remembering" punch cards. I started with 
computers in 1980, and heard that they were in use, but never saw them in 
action. Maybe you also remember "dynamic RAM" implemented with small ferrite 
coils sitting in an array on a 2-D frame?? Could fit a few kilo-bits per 
square meter!!

> We are writing technology history, people, one word at a time.

Bold statement. In fact, I hope you are wrong(!). Not that you won't manage to 
implement it, but by the time it is a matter of "do you remember", we have 
already left the "HTML age" and entered something yet unheard of, which I 
strongly believe waits to be "invented soon". 
Maybe I am naive. I though the same of Cobol 20 years ago.

Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Remove old releases, Fwd: need some more web space conservatism again

[Niclas Hedhman]

On Saturday 25 January 2003 21:42, Stefano Mazzocchi wrote:
> > Generally speaking, I agree. Especially if they could not be reproduced
> > from CVS. Moreover, all releases should be available and not only the
> > set we have now (see  in this thread). But given limited
> > hardware, I think it's ok to archive it on another machine.
> >
> > What do you think?
>
> I say we do this incrementally:
>
> 1) first we remove all the betas, alphas, release candidates from xml
> and jakarta
>
> 2) if the problem persists, we iterate again.
>
> for the future, we'll think about ways to decentralize the distribution
> system even from the source.

How could this possibly be a problem???

We talk about 60MB download, a release every week would be ~3GB per year, 
let's say 10GB to accommodate for larger distros, and other stuff (3x).

Where do I send the 30GB worth of RAID hard drives?

Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ANNONUNCEMENT] ChartTransformer 0.0.4 released

[Niclas Hedhman]

On Saturday 25 January 2003 21:59, Stefano Mazzocchi wrote:
> Unfortunately, this is not the case. Those mock classes will have to be
> LGPL-ed as well and we won't be able to ship them with our stuff anyway
> (because of ASF policies)

Well, LGPL allows you to distribute un-modified code unrestricted, providing a 
link back to the original project for source code (you don't need to ship the 
source). LGPL is NOT viral to the "linked" (which is questionable what that 
is in the letter of the law) code, only the modifications and "derived work" 
(also somewhat blur).
The mock classes can not be created, Stefano reasons, because you have to take 
the same interfaces, hence "derive work" from those interfaces.
But here is one interesting point, only those mock classes need to be LGPL and 
contributed back to the original project. Some well organized projects even 
allow "dummy" runtime implementations without violating LGPL, where you 
re-distribute their developer jar(s) for proper builds, which are often lean, 
and/or the implementation jars separately for the runtime environment.

BUT, it is a clogmaire (spelling?) out of proportions, and I suggest that ASF 
continues its policy, that Stefano is reciting.
Also note that a 3rd Party can take Cocoon (ASF) and XYZ (LGPL) and GLUE 
(LGPL) as a bundle.

> LGPL was written for C code. Java, being highly dynamic, doesn't really
> distringuish between what is a library and what is your code. And the
> FSF likes it to be that way since they don't like java (being a non-free
> language from their point of view)
>
> One day we'll have cocoon blocks and these problems will be solved but
> for now, we won't ship xGPL classes from official ASF distributions.

That sounds good When can I have it??

Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

UnBlocking Blocks

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote:

Antonio Gallardo wrote:


I think it is time to start thinking in a plug-in technology for Cocoon.



Yes, it's time, but our avalon container is not good enough for that 

Let's put down what is lacking, and what the intermediate goals are.

Avalon will do this now:
 - release Fortress
 - release Merlin extends Fortress
 - work on Avalon 5

Merlin is the thing that can give us real blocks.


But I'm wide open to suggestions on how to move this forward.


This is basically what I have proposed at the last live-meeting:
IMHO blocks need to be done in a slow and steady manner, because we are 
walking on new ground and I don' twant CocoonHEAD to break for big changes.
Avalon will soon release Fortress, that is a ECM successor.

Now, blocks are needed for two reasons:

 1  - separate components development and deployment from Cocoon
 2  - dynamic loading, polimorphic usage and wizbang super extra 
inheritance

I see the first part much easier to accomplish than the second, and we 
could get to that point much easier.

Step 1 is the last iteration of the .jar blocks.
Step 2 is the .cob system.

What do we need to get to step 1, that will alleviate problems a lot?

 - loading of Avalon components from the block jars
 - loading of Cocoon components from the block jars
 - way of defining blocks in the sitemap
 - automatic download of blocks

I imagine a

 components
   blocks

section, where I can specify the block to use, and the default download 
location, and the Cocoon components to load.

Something like:

 
  
  
 

and

 
 name="svg2png"
 src="o.a.c.s.SVGSerializer"
 block="batik"/>

This way we just tell the component to be loaded from a specific block.

The automatic download of blocks is not a problem. Krysalis Ruper 
already is able to download things and has a nice version specification 
system, so that part is solved.

What remains is the automatic load from the block jar, and how to tell 
the sitemap to do it.

Given that Fortress is ECM2, and given that we are going to release 
soon, if we need some feature we can ask if it can support it and move 
to Fortress.

This will give us breathing room for Merlin and proper block implementation.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: UnBlocking Blocks

[Nicola Ken Barozzi]

Nicola Ken Barozzi wrote:


Given that Fortress is ECM2, and given that we are going to release 
soon,  
Avaloners
Being multiproject %-)

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/modules/input DigestMetaModule.java

[cziegeler]

cziegeler2003/01/27 02:37:15

  Modified:src/java/org/apache/cocoon/generation
ServerPagesGenerator.java
   src/java/org/apache/cocoon/environment
AbstractEnvironment.java
   
src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation
SessionPreTransformer.java
   src/java/org/apache/cocoon/components/source/impl
SourceDeferredValidity.java
   src/java/org/apache/cocoon/components/modules/input
DigestMetaModule.java
  Log:
  Remove unused imports
  
  Revision  ChangesPath
  1.26  +1 -2  
xml-cocoon2/src/java/org/apache/cocoon/generation/ServerPagesGenerator.java
  
  Index: ServerPagesGenerator.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/generation/ServerPagesGenerator.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- ServerPagesGenerator.java 25 Jan 2003 02:58:57 -  1.25
  +++ ServerPagesGenerator.java 27 Jan 2003 10:37:15 -  1.26
  @@ -57,7 +57,6 @@
   import org.apache.avalon.framework.configuration.Configurable;
   import org.apache.avalon.framework.configuration.Configuration;
   import org.apache.avalon.framework.configuration.ConfigurationException;
  -import org.apache.avalon.framework.logger.LogEnabled;
   import org.apache.avalon.framework.parameters.Parameters;
   import org.apache.cocoon.ProcessingException;
   import org.apache.cocoon.ResourceNotFoundException;
  
  
  
  1.34  +1 -2  
xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java
  
  Index: AbstractEnvironment.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/environment/AbstractEnvironment.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- AbstractEnvironment.java  16 Jan 2003 14:33:32 -  1.33
  +++ AbstractEnvironment.java  27 Jan 2003 10:37:15 -  1.34
  @@ -53,7 +53,6 @@
   import org.apache.avalon.excalibur.collections.IteratorEnumeration;
   
   import org.apache.avalon.framework.component.ComponentManager;
  -import org.apache.avalon.framework.component.ComponentException;
   import org.apache.avalon.framework.logger.AbstractLogEnabled;
   
   import org.apache.cocoon.ProcessingException;
  
  
  
  1.5   +0 -1  
xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation/SessionPreTransformer.java
  
  Index: SessionPreTransformer.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/blocks/session-fw/java/org/apache/cocoon/webapps/session/transformation/SessionPreTransformer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SessionPreTransformer.java10 Jan 2003 21:12:07 -  1.4
  +++ SessionPreTransformer.java27 Jan 2003 10:37:15 -  1.5
  @@ -58,7 +58,6 @@
   import org.apache.cocoon.environment.SourceResolver;
   import org.apache.cocoon.webapps.session.SessionConstants;
   import org.apache.excalibur.source.SourceParameters;
  -import org.w3c.dom.DocumentFragment;
   import org.xml.sax.Attributes;
   import org.xml.sax.SAXException;
   
  
  
  
  1.3   +1 -3  
xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/SourceDeferredValidity.java
  
  Index: SourceDeferredValidity.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/SourceDeferredValidity.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SourceDeferredValidity.java   13 Jan 2003 13:12:30 -  1.2
  +++ SourceDeferredValidity.java   27 Jan 2003 10:37:15 -  1.3
  @@ -50,8 +50,6 @@
   */
   package org.apache.cocoon.components.source.impl;
   
  -import java.io.Serializable;
  -
   import org.apache.excalibur.source.Source;
   import org.apache.excalibur.source.SourceValidity;
   import org.apache.excalibur.source.impl.validity.DeferredValidity;
  
  
  
  1.13  +2 -2  
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java
  
  Index: DigestMetaModule.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- DigestMetaModule.java 17 Jan 2003 11:31:55 -  1.12
  +++ DigestMetaModule.java 27 Jan 2003 10:37:15 -  1.13
  @@ -118,7 +118,7 @@
   this.defaultProvider = 
this.inputConf.getAttribute("provider",this.defaultProvider);
 

cvs commit: xml-cocoon2/src/test/org/apache/cocoon/xml - New directory

[stephan]

stephan 2003/01/27 03:02:42

  xml-cocoon2/src/test/org/apache/cocoon/xml - New directory

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

caching "last-modified" in response header

[Yap, Mow Ching (Gamer.tv)]

does anyone know how to cache the last-modified value in the header for a
cached stream pipeline?

as far as i can tell, the stream pipeline in cache only stores the body of
the response. presumably the stream pipeline itself sets the response
headers for a cached response. is there anyway i can configure it to cache
and set the last-modified value in the header so that the servlet engine
sends out a 304 status code.

or even better, can cocoon itself set the 304 response based on the
last-modified date being equal to the if-modified-after?

cheers,
mooch.



DISCLAIMER - The preceding e-mail message (including any attachments)
contains information that may be confidential, may be protected by the
attorney-client or other applicable privileges, or may constitute non-public
information.  It is intended to be conveyed only to the designated
recipient(s) named above.  If you are not an intended recipient of this
message, please notify the sender by replying to this message and then
delete all copies of it from your computer system.  Any use, dissemination,
distribution, or reproduction of this message by unintended recipients is
not authorized and may be unlawful. The contents of this communication do
not necessarily represent the views of this company.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Pierpaolo Fumagalli as a cocoon committer

[Michael Melhem]

On Sun, Jan 26, 2003 at 05:30:49PM +0100, Nicola Ken Barozzi wrote:
> 
> Oh boy, this is fun...
> 
> I'd like to propose Pierpaolo Fumagalli, aka [EMAIL PROTECTED], aka Mr 
> Bugzilla notwithstanding, aka many other things as an active cocoon 
> committer, back from emeritus status.
> 
> So, given that he is willing to work again in Cocoon making us all 
> happy, and has already submitted some patches showing good humor, here 
> is my +1

+1

Michael
> 
> -- 
> Nicola Ken Barozzi   [EMAIL PROTECTED]
> - verba volant, scripta manent -
>(discussions get forgotten, just code remains)
> -
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ANNONUNCEMENT] ChartTransformer 0.0.4 released

[Luca Morandini]

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 2:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ANNONUNCEMENT] ChartTransformer 0.0.4 released


> Unfortunately, this is not the case. Those mock classes will have to be
> LGPL-ed as well and we won't be able to ship them with our stuff anyway
> (because of ASF policies)
>

Ok, if it is an official ASF policy, there is not much we can do about it :(

With all the due respect though, I think this is an error: there are countless 
packages (commercial or open source) begging to be
connected to Cocoon.
By not allowing even LGPL to be in there, we're missing a lot of opportunities.

Anyway, we (me, Piero, the folks at IPZS) will later decide what to do next... funny 
how value is destroyed in such religion wars !

Regards,

P.S.
Sooner or later a Westphalia treaty must be signed amongst the warring factions of 
open-source believers (
http://www.fortunecity.com/victorian/riley/787/30/Westfalia.html ).

-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [VOTE] Pierpaolo Fumagalli as a cocoon committer

[Davanum Srinivas]

+1

--- Michael Melhem <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 26, 2003 at 05:30:49PM +0100, Nicola Ken Barozzi wrote:
> > 
> > Oh boy, this is fun...
> > 
> > I'd like to propose Pierpaolo Fumagalli, aka [EMAIL PROTECTED], aka Mr 
> > Bugzilla notwithstanding, aka many other things as an active cocoon 
> > committer, back from emeritus status.
> > 
> > So, given that he is willing to work again in Cocoon making us all 
> > happy, and has already submitted some patches showing good humor, here 
> > is my +1
> 
> +1
> 
> Michael
> > 
> > -- 
> > Nicola Ken Barozzi   [EMAIL PROTECTED]
> > - verba volant, scripta manent -
> >(discussions get forgotten, just code remains)
> > -
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


=
Davanum Srinivas - http://xml.apache.org/~dims/

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

FW: cvs commit: CVSROOT avail

[Pier Fumagalli]

FYI, self enabling myself...

Pier

-- Forwarded Message
> From: [EMAIL PROTECTED]
> Date: 27 Jan 2003 14:00:37 -
> To: [EMAIL PROTECTED]
> Subject: cvs commit: CVSROOT avail
> 
> pier2003/01/27 06:00:37
> 
> Modified:.avail
> Log:
> cocoon-dev += pier (back from emeritus status)
> 
> Proposed by:
> 
> Nicola Ken Barozzi 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Votes:
> 
> John Morrison 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Gianugo Rabellino 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Torsten Curdt 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Bernhard Huber 
> Message-id: <[EMAIL PROTECTED]>
> 
> Bertrand Delacretaz 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Carsten Ziegeler 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Christian Haul 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Stephan Michels 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Stefano Mazzocchi 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Michael Melhem 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Davanum Srinivas 
> Message-ID: <[EMAIL PROTECTED]>
> 
> Revision  ChangesPath
> 1.1011+1 -1  CVSROOT/avail
> 
> Index: avail
> ===
> RCS file: /home/cvs/CVSROOT/avail,v
> retrieving revision 1.1010
> retrieving revision 1.1011
> diff -u -r1.1010 -r1.1011
> --- avail25 Jan 2003 00:57:01 -1.1010
> +++ avail27 Jan 2003 14:00:37 -1.1011
> @@ -89,7 +89,7 @@
>  avail|twl,dirkx,ndw|xml-commons
>  avail|twl,dirkx,duncan,mode,edwingo,costin|xml-site,xml-contrib
>  avail|twl,geuerp,dirkx,vdkoogh,amattheu|xml-site,xml-security,ws-site
> -avail|stefano,balld,ricardo,rubys,ben,zvia,giacomo,gears,bmclaugh,bloritsch,r
> ossb,jeremy,greenrd,dims,ssahuc,prussell,cziegeler,donaldp,mman,sylvain,vgrits
> enko,haul,morrijr,crossley,ovidiu,tcurdt,gianugo,froehlich,huber,dirkx,butlerm
> h,nicolaken,ivelin,kpiroumian,shannon,proyal,stephan,coliver,crafterm,acoliver
> ,stevenn,bdelacretaz,mlangham,michaelm,jefft|xml-cocoon,xml-cocoon2,xml-cocoon
> 2-apps,xml-site,xml-commons
> +avail|stefano,balld,ricardo,rubys,ben,zvia,giacomo,gears,bmclaugh,bloritsch,r
> ossb,jeremy,greenrd,dims,ssahuc,prussell,cziegeler,donaldp,mman,sylvain,vgrits
> enko,haul,morrijr,crossley,ovidiu,tcurdt,gianugo,froehlich,huber,dirkx,butlerm
> h,nicolaken,ivelin,kpiroumian,shannon,proyal,stephan,coliver,crafterm,acoliver
> ,stevenn,bdelacretaz,mlangham,michaelm,jefft,pier|xml-cocoon,xml-cocoon2,xml-c
> ocoon2-apps,xml-site,xml-commons
>  
> avail|andyc,abagchi,rahulj,rwebster,roddey,rpfeiffe,gmarcy,arkin,aruna1,mode,l
> ehors,jeffreyr,andyh,ericye,edwingo,duncan,david,mpogue,jpolast,twl,jberry,hni
> ne,estaub,louismau,billsch,lmartin,tng,costin,lynnm,elena,neilg,knoaman,jasons
> ,peiyongz,sandygao,rahuls,neeraj,dirkx,gareth|xml-xerces,xml-xerces-2.0,xml-cr
> imson,xml-site,xml-commons
>  
> avail|coar,dirkx,stefano,twl,andyh,sboag,jtauber,andyc,rpfeiffe,mpogue,mdierke
> n,kvisco,eduardop,abagchi,rahulj,rwebster,roddey,dleslie,mmidy,sanjiva,dmarsto
> n,pauldick,curcuru,dbertoni,jdonohue,robweir,balld,ricardo,zvia,gmarcy,arkin,d
> uncan,aruna1,rajiv,fotis,eschaeffer,arved,gears,jordan,keiron,stanislav,klease
> ,kellyc,artw,tore,bdelacretaz,chrisg,pbwest,pietsch,jeremias,olegt,vmote|xml-f
> op,xml-site,xml-commons
>  
> avail|twl,duncan,rubys,duftler,sanjiva,curbera,dbox,costin,mode,mpogue,sean,jm
> snell,gdaniels,kmitchell,jacek,martinf,matkovitsg,neyama,cnelson,avahe,dug,wcl
> oeten,sgg,nakamury,jechawke,robj,nagy,sstirling,snichol,dirkx|xml-soap,xml-sit
> e,ws-site
> 
> 
> 
> 
> 

-- End of Forwarded Message


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FW: cvs commit: CVSROOT avail

[Sylvain Wallez]

Pier Fumagalli wrote:


FYI, self enabling myself...
 


Damn, I didn't had the time to vote (our mail server just came up again 
after 3 days of problems).

Anyway, welcome back, Pier !

I owe you some special thanks since I became a Cocoon committer after 
sending numerous patches to solve your bugs. So every committer-wannabe 
reading this, subscribe quickly to cocoon-cvs and inspect closely all 
commits by Pier !
;-)

Sylvain

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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/webapp/WEB-INF web.xml

[cziegeler]

cziegeler2003/01/27 06:21:45

  Modified:src/webapp/WEB-INF web.xml
  Log:
  adding some more database drivers
  
  Revision  ChangesPath
  1.22  +9 -0  xml-cocoon2/src/webapp/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/src/webapp/WEB-INF/web.xml,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- web.xml   17 Dec 2002 15:16:31 -  1.21
  +++ web.xml   27 Jan 2003 14:21:45 -  1.22
  @@ -117,6 +117,15 @@
   
   org.hsqldb.jdbcDriver
   
  +
  +
  +
  +
  +
  + sun.jdbc.odbc.JdbcOdbcDriver
  + 
   
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: cvs commit: CVSROOT avail

[Vadim Gritsenko]

Sylvain Wallez wrote:


Pier Fumagalli wrote:


FYI, self enabling myself...
 


Damn, I didn't had the time to vote (our mail server just came up 
again after 3 days of problems).

Anyway, welcome back, Pier !

I owe you some special thanks since I became a Cocoon committer after 
sending numerous patches to solve your bugs. So every 
committer-wannabe reading this, subscribe quickly to cocoon-cvs and 
inspect closely all commits by Pier !
;-)


Ditto!

Vadim



Sylvain





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Antonio Gallardo]

Torsten Curdt dijo:
> Sure - the question is only how to integrate this easily since we would
> need to pass the information (more-results or not) from the logicsheet
> into the classes.
>
> And please - no ugly hack like "setXXX"
> --
> Torsten

I think XSL will permit an elegant solution. I think this will need just
to find if exist  tag. Example: Suppose we have:

5

the the esql.xsl will include code like:

if (exist )
   LIMIT 5+1
else
   LIMIT 5

I think this is an elegant solution. What you think?

Best Regards,

Antonio Gallardo.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Exciting Calendar Announcement (WAS [OT] Cocoon Calendar (WAS RE: HAPPY BIRTHDAY STEFANO!))

[Antonio Gallardo]

Stefano Mazzocchi dijo:
> Torsten Curdt wrote:
>
>> Please don't take it personal Stefano - with that color you looked
>> like  being on drugs or something ;)
>
> personal? who told you I already wasn't? :)
lol
Antonio
>
> --
> Stefano Mazzocchi   <[EMAIL PROTECTED]>
> 
>
>
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Torsten Curdt]

if (exist )
   LIMIT 5+1
else
   LIMIT 5

I think this is an elegant solution. What you think?


Sure - but the problem is that we also would need to adjust the length 
of the resultset inside the helper class. (you always want to see only 5 
rows in your page)

The length of the resultset inside the class would sometimes be one more 
and sometimes *exact* - depending on whether there is a  
tag or not. Which would be very confusing!

Give me a day to think about this...
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FW: cvs commit: CVSROOT avail

[Nicola Ken Barozzi]

Pier Fumagalli wrote:

FYI, self enabling myself...


Ahhh, shucks, you spoilt the joke :-P

Welcome, man! :-D


--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Antonio Gallardo]

Torsten Curdt dijo:
>> if (exist )
>>LIMIT 5+1
>> else
>>LIMIT 5
>>
>> I think this is an elegant solution. What you think?
>
> Sure - but the problem is that we also would need to adjust the length
> of the resultset inside the helper class. (you always want to see only 5
>  rows in your page)
>
> The length of the resultset inside the class would sometimes be one more
>  and sometimes *exact* - depending on whether there is a 
> tag or not. Which would be very confusing!

I dont agree. The LIMIT 5+1 is just a internal issue. From the user view.
he never knows we was asking 5+1 rows. He never can access the 5+1 row.
even if it exists.

I agree with you that also the can be a change into the "esqlhelper class"
into the method that retrieve the row and get it to the user.
>
> Give me a day to think about this...
You got it! ;-)
> --
> Torsten
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge acommiter!)

[Pier Fumagalli]

This discussion should be better if continued on [EMAIL PROTECTED]
I'm sending it here because of the last few lines pertinent to Cocoon
specifically.

Also, I'm not on [EMAIL PROTECTED], as I trust my peers over there to
do a great job and have not much time to contribute to the discussuin.

If you think it's appropriate, feel free to CC me as well...



"Ovidiu Predescu" <[EMAIL PROTECTED]> wrote:

> Pier,
> 
> On Sunday, Jan 26, 2003, at 11:58 US/Pacific, Pier Fumagalli wrote:
> 
>> If (for example) we, the ASF, decided to get the library and make some
>> modifications to it, or, scarier though, we _had_ to "fork" the
>> library for our own needs (imagine, the orignal author changes from
>> LGPL to something else, full GPL for example -as happened lately to
>> the MySQL JDBC drivers- or even worse, decides the library will only
>> be distributed as "commercial software"), then we would be utterly
>> f***ed.
> 
> Under the same logic, nothing prevents somebody to take any project
> from Apache and release it under their own commercial license, without
> releasing any source code at all for any change. The Apache Software
> License is of no use either in such a situation, since there is no
> provision that prevents such forks to happen.

That is correct. And we have several of those examples. Example prime being
IBM WebSphere, based entirely on Apache-HTTPd, re-stretched and re-wrote to
new extents, but distributed under a purely commercial license (or at least
that was at the beginning, I don't know if now they distribute it using the
IBM Public-Source License).

> I think the real issue is not the _license_, but the _copyright_. If
> you're the copyright holder, you can change the license at will or you
> can release the same code under different licenses. That's why a
> license change was possible in the case of MySQL's JDBC driver. It was
> not LGPL that was viral, it was the copyright holder.

Well, yes: indeed the copyright holder of any particular body of work is
allowed to change the license anytime, but, if you get back to our original
example (forking a LGPL-based library), to be able to change the library's
license, each single line of the library should have to be rewritten (with
copyright of each modified part assigned to the modifier).

Only at that point, when the copyright is entirely owned by the modifier
(and therefore every single line of code has been rewritten), the modifier
is allowed to change from LGPL.

> That's why Apache and FSF require their contributors to assign the copyrights
> to the respective foundations.

Indeed (and also for protection to each individual contributor, I want to
add). One of the ASF main tasks is also to LEGALLY PROTECT each individual
contributor... It's somewhere in our charter, but better outlined in the
Foundation FAQ: 

2.b) provide a means for individual volunteers to be sheltered from legal
 suits directed at the Foundation's projects

In layman's terms, if you mess about, you won't be directly sued, the
foundation will (goes back to the discussion on the dues and rights of being
a committer to any project).

> [One nice thing about FSF is that once you
> transfer your copyright to them, they even give you the right to
> continue distributing your original code under a restrictive license.]

You are legally allowed to do that (if I was able to scavenge the three
classes of Cocoon 2 I wrote before posting them on CVS, I can still claim
them as "mine" and fork myself, hehehehe)...

Plus, the ASF doesn't "need" to do that... Our license says "go ahead and do
whatever you want" :-) That's the beauty of it... (or how I persolanny call
it, real "freedom", you're even free to change my license!)

>> Ethically the ASF does not develops software under a "viral" license,
>> therefore, given the "partial virality" of LGPL, we wouldn't be able
>> to "fork" and maintain such a library. We wouldn't even be able to
>> change the license, all modifications would have to be LGPL, so, we
>> either would have to rewrite the whole thing, or get rid of the
>> offending bits and bobs...
> 
> This is FUD! What is the problem with your changes being LGPL? If what
> matters is the software continuing to be free software, it should be
> fine with you. The changes you make are copyrighted by you, so the
> original developer will not be able to take your improvements and
> release them under a commercial, more restrictive license without your
> consent.

Well, as you say "if what matters is the software continuing to be free
software" You see, that doesn't matter for me... I do not care if the
software I wrote continues to be free or not :-) You want it? Get it, use
it, turn'n'twist it, and then sell it "Microsoft way" :-)

All I want is my ego to be satisfied (ASF license point #3, say that we
wrote it! :-) and be a part of a community that shares my concerns...

> Linux worked just fine on exactly 

Re: [ESQL] Improvement....

[Antonio Gallardo]

Antonio Gallardo dijo:
> Torsten Curdt dijo:
>>> if (exist )
>>>LIMIT 5+1
>>> else
>>>LIMIT 5
>>>
>>> I think this is an elegant solution. What you think?
>>
>> Sure - but the problem is that we also would need to adjust the length
>> of the resultset inside the helper class. (you always want to see only
>> 5
>>  rows in your page)
>>
>> The length of the resultset inside the class would sometimes be one
>> more
>>  and sometimes *exact* - depending on whether there is a
>> 
>> tag or not. Which would be very confusing!
>
> I dont agree. The LIMIT 5+1 is just a internal issue. From the user
> view. he never knows we was asking 5+1 rows. He never can access the 5+1
> row. even if it exists.
>
> I agree with you that also can be a change into the "esqlhelper
> class" into the method that retrieve the row and get it to the user.

I also remember that the "hack" to trig the  tag is
just checking is there is the 5+1 row or not. :-), This is the test than
we need to wrap in a if statement.

Best Regards,

Antonio Gallardo




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Torsten Curdt]

I dont agree. The LIMIT 5+1 is just a internal issue. From the user view.
he never knows we was asking 5+1 rows. He never can access the 5+1 row.
even if it exists.


That is exactly what I was trying to say ;)

Keep in mind we have user -> esql -> classes -> resultset

Who should fix the +1 issue? esql or the class? And if the class (which 
can be confusing) - how...

...that's what I gonna put under my pillow tonight ;)
--
Torsten


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

ValidationTransformer

[Oskar Casquero]

Hi,

I am trying to do a ValidationTransformer that will validate an xml document
with a grammar (W3C Schema, RELAX NG, DTD). To do this I am using JARV, that
gives a validation interface which can control a validation engine (for
example, Xerces-2) through the suitable driver.

I have done the first version of the ValidationTransformer via DOM. To do
it, I modified the WriteDOMSessionTransformer, implementing ErrorHandler
interface and adding to it the code necessary to validate with W3C schemas
(another grammars can be used setting the grammar type as a parameter in the
sitemap).

setup method:

public void setup(SourceResolver resolver, Map objectModel, String source,
Parameters parameters)
throws ProcessingException, SAXException, IOException, Exception {
...
schema = parameters.getParameter(MyValidationTransformer.SCHEMA, null);
if (schema!=null) {
getLogger().debug("MyValidationTransformer: "+
MyValidationTransformer.SCHEMA + "=" + schema);
} else {
getLogger().error("MyValidationTransformer: need " +
MyValidationTransformer.SCHEMA + " parameters");
}

File schemaFile = new
File("/usr/local/jakarta-tomcat-4.0.4/webapps/cocoon/RTF/schemas/" +
schema);
VerifierFactory factory =
VerifierFactory.newInstance("http://www.w3.org/2001/XMLSchema";);
getLogger().debug("MyValidationTransformer: JARV implementation
obtained");
Schema schemaObject = factory.compileSchema(schemaFile);
getLogger().debug("MyValidationTransformer: schema compiled");
verifier = schemaObject.newVerifier();
verifier.setErrorHandler(this);
getLogger().debug("MyValidationTransformer: errorHandler configured");
} catch (Exception e) {
getLogger().debug("MyValidationTransformer: JARV error: " +
e.getMessage() + ", " + e.getCause());
}
}

endElement method:

public void endElement(String uri, String name, String raw)
throws SAXException {
if (name.equalsIgnoreCase(rootElement) && sessionAvailable) {
...
getLogger().debug("MyValidationTransformer: DOM tree is in session
object");
verifier.verify(builder.getDocument());
getLogger().debug("MyValidationTransformer: DOM tree verified");
}
...
}

error method for ErrorHandler implementation:

public void error( final SAXParseException spe )
throws SAXException
{
String message = "Error parsing " + spe.getSystemId() + " (line " +
spe.getLineNumber() + " col. " + spe.getColumnNumber() +
"): " + spe.getMessage();
getLogger().error( message, spe );
throw new SAXException( message, spe );
}

I check the transformer with the following pipeline: if I send a valid
document it must return the document without doing any transformation; if
the document is not valid, an error message must be returned by cocoon
containing ErrorHandler's exception message.
















This works well. But if I try to add  after the generator, the document is
returned to the browser, despite it is not valid. So I think that the
ValidationTransformer is not working well, but I am not totally sure,
because the error is logged in sitemap.log.

So, why is the error logged into sitemap.log, but not returned as an
exception error message to the client?

Could be because of the way in how cocoon works, because when the validation
of the DOM tree is starting or being done, the pipeline process is already
complete?

The alternative is to perform the validation via SAX, but I don't know how
to mix the verifierHandler and the contentHandler of the transformer in
order to make available incoming SAX events for the verifierHandler. I try
to do:

public void setup(SourceResolver resolver, Map objectModel, String source,
Parameters parameters)
throws ProcessingException, SAXException, IOException, Exception {
...
VerifierHandler verifierHandler = verifier.getVerifierHandler();
super.setContentHandler(verifierHandler);
...
}

so that as the transformer receives SAX events from a generator or another
transfomer, the verifierHandler will also receive them, and if the documents
is not valid and exception will be thrown by the ErrorHandler. But I don't
know why, the super.setContentHandler(verifierHandler) is not working (???)

Oskar


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Antonio Gallardo]

Torsten Curdt dijo:
> 
>
>> I dont agree. The LIMIT 5+1 is just a internal issue. From the user
>> view. he never knows we was asking 5+1 rows. He never can access the
>> 5+1 row. even if it exists.
>
> That is exactly what I was trying to say ;)
>
> Keep in mind we have user -> esql -> classes -> resultset
>
> Who should fix the +1 issue? esql or the class? And if the class (which
> can be confusing) - how...
>
> ...that's what I gonna put under my pillow tonight ;)

Lets put a good description of the hack into the code. Why we did that?
The best solution can be if there are another JBDC function that support
that. But I dont know if this function exist. Then I discarded this
option. :-(

I think that the helper class must resolve this issue. But it must know
when to hack and when not. Maybe adding a parameter to the function that
tell if we want to know if there are more results or not.

This is again hidden from the user view. The user does not work directly
with the esql helper class or with the internally processing of the
esql.xsl.

For me the solution must be clear for the developers of any of the files
the helper class and/or the esql.xsl

I think we have the 1st milestone here. An agree that this will improve
the database experience.

Now we must agree with the solution. Please wait until the solution is
done before tell if this is ugly ;-).

Best Regards,

Antonio Gallardo.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

>>> WHAT IS WRONG?
>>>
>>> In example A all is OK.
>>>
>>> In example B we are not using the power of the Database Manager.
>>>
>>> WHY?
>>>
>>> The LIMIT clause was designed to tell the database engine:
>>>
>>> "Let find just X rows", then the database engine when it got the X 
>>> rows stop searching and return the X rows. It improves the response 
>>> time, since does not to continue searching!
>>>
>>> Now think in a 10 million row table and YOU KNOW you need only 5 
>>> rows!
>>
>> whether 10 million rows or not - the current sollution will only ask 
>> for  6 - one additional row. Is that the time penalty you are talking 
>> about?
>
> Yes, because you already know that there are only 5 rows for every
register. Then the database will > search the last 6th row that no exist.
Forcing to searh in the ENTIRE table.
> 
> Maybe your 5 rows are at the beginning of the table but the non existent
6th row will force the 
> Database Engine to search for this.

Antonio, 

There is only one search for which your 5 rows will be at the start of the
table.  In general, you need an index on the table in order to find your
data with any efficiency.  If you have an index that matches your search
pattern then the search will stop after looking at 6 rows if it determines
that the 6th row does not follow sequentially in the index after the other 5
rows.  There is no difference whether there are 10 or 10 million rows in the
database.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Antonio Gallardo]

Hunsberger, Peter dijo:
 WHAT IS WRONG?

 In example A all is OK.

 In example B we are not using the power of the Database Manager.

 WHY?

 The LIMIT clause was designed to tell the database engine:

 "Let find just X rows", then the database engine when it got the X
 rows stop searching and return the X rows. It improves the response
 time, since does not to continue searching!

 Now think in a 10 million row table and YOU KNOW you need only 5
 rows!
>>>
>>> whether 10 million rows or not - the current sollution will only ask
>>> for  6 - one additional row. Is that the time penalty you are talking
>>>  about?
>>
>> Yes, because you already know that there are only 5 rows for every
> register. Then the database will > search the last 6th row that no
> exist. Forcing to searh in the ENTIRE table.
>>
>> Maybe your 5 rows are at the beginning of the table but the non
>> existent
> 6th row will force the
>> Database Engine to search for this.
>
> Antonio,
>
> There is only one search for which your 5 rows will be at the start of
> the table.  In general, you need an index on the table in order to find
> your data with any efficiency.  If you have an index that matches your
> search pattern then the search will stop after looking at 6 rows if it
> determines that the 6th row does not follow sequentially in the index
> after the other 5 rows.  There is no difference whether there are 10 or
> 10 million rows in the database.

I recently read from a Postgres guru that is not good to index a field
with too few elements in large table.

For example, suppose you have a field with a boolean value. This is not a
good idea to index this field. This is a big penalization for every DB
engine. Is better let him to do the sequence search instead of a index
search. And this sequence search is the penalization I talk about.

Also I did some benchmarks of this using postgres and really this makes a
diference for inserting, updating and deleting a row.

I think it is best to share all this info with you. please visit:

http://techdocs.postgresql.org/techdocs/pgsqladventuresep3.php

There is a better description of when index and when not. from a database
guru, not me. ;-)

Best regards,

Antonio Gallardo.








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

> This is the example I tried to explain:
> 
> I have a table that store the status of some tickets. You always know how
many status there can be. > If you said:
> 
> 1-Open
> 2-Close
> 3-Invalid
> 
> Then if you want to show the history, you will ask for LIMIT 3, but the
database will try to find 
> the 4th row after finding the only 3 that can exist.
> 
> This is why I told this is a performance issue. Not an error.

I sure hope you've normalized your database so that "status" is stored in a
separate table from the rest of the history?  If so, you should have a
proper primary key in the history table that you can index on and the search
will stop after looking at 4 records; the three that match and first one
that doesn't match (at which point it will know the search is done.)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Antonio Gallardo]

Hunsberger, Peter dijo:
>> This is the example I tried to explain:
>>
>> I have a table that store the status of some tickets. You always know
>> how
> many status there can be. > If you said:
>>
>> 1-Open
>> 2-Close
>> 3-Invalid
>>
>> Then if you want to show the history, you will ask for LIMIT 3, but
>> the
> database will try to find
>> the 4th row after finding the only 3 that can exist.
>>
>> This is why I told this is a performance issue. Not an error.
>
> I sure hope you've normalized your database so that "status" is stored
> in a separate table from the rest of the history? If so, you should
> have a proper primary key in the history table that you can index on and
> the search will stop after looking at 4 records; the three that match
> and first one that doesn't match (at which point it will know the search
> is done.)
>

I think this is not a issue of how I build my database or not. This is
more general. Maybe this improvement will does not help nothing in some
Database constructions and give too much in performance.

My point of view is: "If a user dont want to know if there are or not more
results. We must almost build the correct SQL clausule". In this case the
correct clausule is:

LIMIT X

and not LIMIT X+1

Of course if you need to know if there are more rows, then the correct SQL
clausule is:

LIMIT X+1

This is without thinking if you use Oracle, PotgreSQL or any other DB
Engine. I think that the improvement will always helps.

At the end, how much time take for a processor decide to use X or X+1 vrs.
how much time will have to search the X+1 row in a big table? I think the
second one will be always slower regarless if you index or not. Then lets
help the database Engine with better SQL clausules. Tha will helps to
build a faster Database interface for Cocoon. ;-)

Best Regards,

Antonio Gallardo.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

>> if (exist )
>>LIMIT 5+1
>> else
>>LIMIT 5
>> 
>> I think this is an elegant solution. What you think?
> 
> Sure - but the problem is that we also would need to adjust the length 
> of the resultset inside the helper class. (you always want to see only 5 
> rows in your page)
> 
> The length of the resultset inside the class would sometimes be one more 
> and sometimes *exact* - depending on whether there is a  
> tag or not. Which would be very confusing!
> 
> Give me a day to think about this...

Torsten,

You're chasing a non-existent problem.  There is never a real life case that
will have both good performance for N records and bad performance for N+1
records.  The only way you can guarantee having good performance for N
records is if you can build an index.  If you can build an index then the
search will always terminate after looking at N+1 records.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Flow problems & question

[Ugo Cei]

Gianugo Rabellino wrote:

This said, unfortunately, I'm not even getting the samples to work. I'm 
stuck in front of a

TypeError: function WebContinuation() {
[native code]
}
is not a function. 
(resource://org/apache/cocoon/components/flow/javascript/system.js; line 
29)

for the calc example, that used to work until some times ago. This has 
been tested with the embedded Jetty (./build.sh run) and a fresh CVS 
checkout.

I don't get this error in my version, but it's not the latest. Actually, 
I'm reluctant to do a cvs update just now, for fear it might break my flows.

OTOH, I gave a quick look to the object model, and found that there is 
no facility for logging. Is that on purpose? Have I heavily overlooked 
something?

There is:

log.debug('Nifty debug message');

catch(e) { log.error(e); }

Messages are logged to flow.log and also to error.log, if appropriate. 
The problem is that logging an exception does not print a stack trace, 
which would be invaluable for debugging.

	Ugo

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

>>
>> There is only one search for which your 5 rows will be at the start of 
>> the table.  In general, you need an index on the table in order to 
>> find your data with any efficiency.  If you have an index that matches 
>> your search pattern then the search will stop after looking at 6 rows 
>> if it determines that the 6th row does not follow sequentially in the 
>> index after the other 5 rows.  There is no difference whether there 
>> are 10 or 10 million rows in the database.
>
> I recently read from a Postgres guru that is not good to index a field
with too few elements in 
> large table.
>
> For example, suppose you have a field with a boolean value. This is not a
good idea to index this
> field. This is a big penalization for every DB engine. Is better let him
to do the sequence search
> instead of a index search. And this sequence search is the penalization I
talk about.
>
> Also I did some benchmarks of this using postgres and really this makes a
diference for inserting,
> updating and deleting a row.
> 
> I think it is best to share all this info with you. please visit:
> 
> http://techdocs.postgresql.org/techdocs/pgsqladventuresep3.php
> 
> There is a better description of when index and when not. from a database
guru, not me. ;-)
> 
> Best regards,

Yes, fair enough, you're shouldn't be indexing on a type column (or a
Boolean column) in order to determine whether you've found your N records or
not.  Since there are, in general, never N records in this column it won't
tell you anything.  You still need a common foreign key somewhere else in
your database that you can index on. 

If you don't have such a key but you do have a database that supports hard
coded limits on search size then yes, you could improve performance but
having the hard limit.  In such a case, the average performance would be 50%
better for the hard stop (but you've moved hard coded business logic into
your SQL query which doesn't seem like a good idea to me).  However, the
whole issue goes away with proper database design...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

>>> This is the example I tried to explain:
>>>
>>> I have a table that store the status of some tickets. You always know 
>>> how
>> many status there can be. > If you said:
>>>
>>> 1-Open
>>> 2-Close
>>> 3-Invalid
>>>
>>> Then if you want to show the history, you will ask for LIMIT 3, but 
>>> the
>> database will try to find
>>> the 4th row after finding the only 3 that can exist.
>>>
>>> This is why I told this is a performance issue. Not an error.
>>
>> I sure hope you've normalized your database so that "status" is stored 
>> in a separate table from the rest of the history? If so, you should 
>> have a proper primary key in the history table that you can index on 
>> and the search will stop after looking at 4 records; the three that 
>> match and first one that doesn't match (at which point it will know 
>> the search is done.)
>>
>
> I think this is not a issue of how I build my database or not. This is
more general. Maybe this
> improvement will does not help nothing in some Database constructions and
give too much in
> performance.

No, this is always a database design issue.

> My point of view is: "If a user dont want to know if there are or not more
results. We must almost > build the correct SQL clausule". In this case the
correct clausule is:
>
> LIMIT X
> 
> and not LIMIT X+1

In a properly designed database there should effectively be no difference
between the two clauses.

> Of course if you need to know if there are more rows, then the correct SQL
clausule is:
> 
> LIMIT X+1
> 
> This is without thinking if you use Oracle, PotgreSQL or any other DB
Engine. I think that the
> improvement will always helps.
>
> At the end, how much time take for a processor decide to use X or X+1 vrs.
how much time will have
> to search the X+1 row in a big table? I think the second one will be
always slower regarless if you
> index or not. Then lets help the database Engine with better SQL
clausules. Tha will helps to build
> a faster Database interface for Cocoon. ;-)

In a properly designed database the improvement will be too small to
measure

Now, you might argue that we should not try and force the user to have a
properly designed database.  I agree that it would be nice, however, it is
an impossible task: if you optimize for one bad design I can always find a
counter example where your optimization introduces worse performance.  In
this particular case there is however another line of attack, and that it to
look at having Cocoon use two different ways to stop the search.  Each of
these would be independent of each other and not interact.  You would choose
one or the other for any given query...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Hunsberger, Peter]

>>> if (exist )
>>>LIMIT 5+1
>>> else
>>>LIMIT 5
>>> 
>> I think this is an elegant solution. What you think?
>> 
>> Sure - but the problem is that we also would need to adjust the length
>> of the resultset inside the helper class. (you always want to see only 5 
>> rows in your page)
>> 
>> The length of the resultset inside the class would sometimes be one 
>> more
>> and sometimes *exact* - depending on whether there is a  
>> tag or not. Which would be very confusing!
>> 
>> Give me a day to think about this...
>
> Torsten,
>
> You're chasing a non-existent problem.  There is never a real life case
that will have both good 
> performance for N records and bad performance for N+1 records.  

I should have qualified this by adding "for a properly designed database"...

> The only way you can guarantee having good performance for N records is if
you can build an index.
> If you can build an index then the search will always terminate after
looking at N+1 records.

For a poorly designed database (one where you don't have a foreign key to
group by to count your N records) they you might want a hack to force the
query to stop at some count.  However, this shouldn't be the same as the
more-results check.  Instead you need a separate hard stop limit...





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

What is a Parser?

[Ugo Cei]

Once upon a time there was a org.apache.cocoon.components.parser.Parser, 
but now it's deprecated. OK, so I think I should use the Excalibur 
parser component, which has recently been split into a SAX parser and a 
DOM parser.

Looking in excalibur-xmlutil-20030122.jar, I found this class: 
org.apache.excalibur.xml.sax.Parser. Maybe I can use that. This is my 
first try:

org.apache.excalibur.xml.sax.Parser saxParser = null;
try {
  saxParser = (org.apache.excalibur.xml.sax.Parser)
manager.lookup(org.apache.excalibur.xml.sax.Parser.ROLE);
}
finally {
  if (saxParser != null) manager.release(saxParser);
}

Unfortunately, it doesn't compile, because Parser does not implement 
Component, so I resolve the problem with a cast:

  if (saxParser != null) manager.release((Component) saxParser);

I'm starting to feel a little bit confused, because I was not aware that 
in Java you could get away with that at compile time. Maybe I should 
have a look at the JLS, but since I'm lazy and my code runs, I figure 
I'd better ask cocoon-dev ;-).

Is this the kosher way of obtaining an XML parser in Cocoon 2.1?

To further complicate things, Eclipse does not like my little class 
which implements org.apache.avalon.framework.component.Component, since 
it insists that the type Component is deprecated, along with 
ComponentManager. In order to play by the rules, I've removed 
"Component" from the interfaces my class implements, but Cocoon (or is 
it Excalibur?) barfs with a "ClassCastException" when I try to put it in 
cocoon.xconf. Well, I just put back the "implements Component" 
declaration and live with Eclipse's warnings, but I cannot help feeling 
a little disoriented about all this ;-).

	Ugo



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: [ESQL] Improvement....

[Antonio Gallardo]

Hunsberger, Peter dijo:
 This is the example I tried to explain:

 I have a table that store the status of some tickets. You always
 know  how
>>> many status there can be. > If you said:

 1-Open
 2-Close
 3-Invalid

 Then if you want to show the history, you will ask for LIMIT 3, but
 the
>>> database will try to find
 the 4th row after finding the only 3 that can exist.

 This is why I told this is a performance issue. Not an error.
>>>
>>> I sure hope you've normalized your database so that "status" is
>>> stored  in a separate table from the rest of the history? If so, you
>>> should  have a proper primary key in the history table that you can
>>> index on  and the search will stop after looking at 4 records; the
>>> three that  match and first one that doesn't match (at which point it
>>> will know  the search is done.)
>>>
>>
>> I think this is not a issue of how I build my database or not. This is
> more general. Maybe this
>> improvement will does not help nothing in some Database constructions
>> and
> give too much in
>> performance.
>
> No, this is always a database design issue.
>
>> My point of view is: "If a user dont want to know if there are or not
>> more
> results. We must almost > build the correct SQL clausule". In this case
> the correct clausule is:
>>
>> LIMIT X
>>
>> and not LIMIT X+1
>
> In a properly designed database there should effectively be no
> difference between the two clauses.
>
>> Of course if you need to know if there are more rows, then the correct
>> SQL
> clausule is:
>>
>> LIMIT X+1
>>
>> This is without thinking if you use Oracle, PotgreSQL or any other DB
> Engine. I think that the
>> improvement will always helps.
>>
>> At the end, how much time take for a processor decide to use X or X+1
>> vrs.
> how much time will have
>> to search the X+1 row in a big table? I think the second one will be
> always slower regarless if you
>> index or not. Then lets help the database Engine with better SQL
> clausules. Tha will helps to build
>> a faster Database interface for Cocoon. ;-)
>
> In a properly designed database the improvement will be too small to
> measure
>
> Now, you might argue that we should not try and force the user to have a
> properly designed database.  I agree that it would be nice, however, it
> is an impossible task: if you optimize for one bad design I can always
> find a counter example where your optimization introduces worse
> performance.  In this particular case there is however another line of
> attack, and that it to look at having Cocoon use two different ways to
> stop the search.  Each of these would be independent of each other and
> not interact.  You would choose one or the other for any given query...

Yes, I agree with you. If someone need to stop the searching with a LIMIT
clausule, then better it would harcore the LIMIT clausule directly inside
the SQL query. That way we does not need to change the current code.

Thanks.

Antonio Gallardo.
>
>
> - To
> unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Remove old releases, Fwd: need some more web spaceconservatism again

[Justin Erenkrantz]

--On Saturday, January 25, 2003 2:42 PM +0100 Stefano Mazzocchi 
<[EMAIL PROTECTED]> wrote:

those are not minor releases. Those are "releases", a release is
something that you might build your stuff upon. It's a contract.
Books, for example, use these contracts for years (before a new
edition outdates another one, but that edition can still be used)


Correct.  If you look at our new mirroring guidelines 
(http://www.apache.org/dev/mirrors.html), we're attempting to 
advocate keeping releases in a stable place forever.  For example, 
cocoon 2.0.4 source should always be available at:

http://www.apache.org/dist/xml/cocoon/source/cocoon-2.0.4-src.tar.gz

I don't think *releases* are our problem right now.  I believe it is 
the nightly builds.  Those aren't official releases, and I don't 
think we have the obligation to keep those around.

Cocoon distribution is not the lastest version, is the *entire*
collection of releases.


+1


I say we do this incrementally:

1) first we remove all the betas, alphas, release candidates from
xml and jakarta

2) if the problem persists, we iterate again.

for the future, we'll think about ways to decentralize the
distribution system even from the source.


+1.

If we only have *offical releases* and we still have a space crunch, 
then we should buy more hard drive space.  That is our responsibility 
as part of the ASF.   But, as Brian has pointed out, most of that is 
in jakarta's /builds/ which contain nightly builds.  -- justin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/test/org/apache/cocoon/components/source - New directory

[stephan]

stephan 2003/01/27 11:38:34

  xml-cocoon2/src/test/org/apache/cocoon/components/source - New directory

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/test/org/apache/cocoon/transformation - New directory

[stephan]

stephan 2003/01/27 11:38:34

  xml-cocoon2/src/test/org/apache/cocoon/transformation - New directory

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/test/org/apache/cocoon/generation - New directory

[stephan]

stephan 2003/01/27 11:38:34

  xml-cocoon2/src/test/org/apache/cocoon/generation - New directory

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)

[Stefano Mazzocchi]

Ovidiu Predescu wrote:


Rewriting the code to conform to a license is a poor choice IMO.


Agreed and respected.

Although, there is a real problem: the LGPL says that you are forced to 
put changes back into the LGPL license only if you modify the library, 
but not the code that links to it.

Now, what is a java library?

The real issue with LGPL is with its imprecision: there potentially no 
limit about where the 'gpl infection' can get thru in your code.

Personally, I don't want to give the FSF the possibility to come after 
us because of that.

I designed the blocks concept also to get around legal problems because 
the xGPL works with 'redistribution', not 'installation'.

You can even install a GPL cocoon block on top of Cocoon and as long as 
we don't ship any of that inside Cocoon, we are fine and the user who 
does is fine as well.

The block concept will work as a condom around GPL virality (yes, RMS, I 
don't like your imposed freedom, I want 'metafreedom' the freedom to 
choose my flavor of it and to dislike yours, thank you)

Today, even moch classes are unsafe sex for us, because moch classes 
rewrite parts that are *included* in the library so they are part of the 
library itself, so they have to be LGPL-ed.

At the end, do not worry, we are not trying to paint the world with 
Apache licenses (like the FSF does) so we'll work to make it possible to 
make the software interoperate.

But we need blocks for that and we need a serious avalon container for 
that and we need a serious community around it... or we simply screw 
them and build our own container.

oh well...

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]

[Stefano Mazzocchi]

Nicola Ken Barozzi wrote:


Torsten Curdt wrote:


I thought contributing to Cocoon to be easier... much easier :(



I have put much time and effort in trying to make a charting solution.
I think it's bad that he is not willing at all to collaborate. He says 
he wants "his" code in cocoon.

Wings was based on my code. Then Keiron Liddle donated his stuff and we 
switched. Then JCharts became APL compatible and we switched again.
Now this guy comes up *totally irrespective* of anything that has 
happened. Look at the class. It loads tags from xml and feeds them in 
JFreeChart. And he cannot integrate with Wings. It's ridiculous.

He is not willing to collaborate in any way, and I don't like it.

As for LGPL, it's really something we should not put in our CVS.

Finally look at the patches in bugzilla. Their authors should be the 
ones saying the above.

Nicola, you crossed the line.

You are generating waves of negative emotions on this list due to code 
ownership. I cannot believe this is happening again.

From where I stand, Luca (and others) had a problem for their 
customers, solved it in the way they found better then decided that to 
say something about it here. Somebody else proposed it for inclusion in CVS.

Then, later, Luca was also honest enough to admit his ego would be proud 
of having some of his code into the codebase.

Tell me: wasn't this *exactly* the same thing that made you stick around 
 in the first place?

Software is *NOT* important around here, do you get it?

Human relationships are. Ask yourself if your comments made this 
relationship any better.

From here, with this childlish comment of yours you:

 - pissed Luca, deteriorating a possible relationship with him and his 
colleagues
 - worry other people, that might not want to donate their code because 
fearing of such treatment themselves.
 - lowered the overall respect others have in you
 - reduced the chance of collaboration with the stuff you've written

I will *NOT* tollerate any further stupid personal attack on this list. 
You have a ego problem? go over it or leave. I've said so on avalon-dev 
I'm saying the same here.

Note that this is true for *EVERYBODY*, myself included.

Moreover, I'm *very* concerned about the fact that this comment doesn't 
come from a newbie but from a vice-president of the foundation. Nicola 
is the avalon chair and Avalon suffers from these problems. Don't make 
me think there is a connection between the two.

Yes, I'm pissed.

And yes, I've used my two-email pattern, (you should have read the other 
one)

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/tools/lib xmlunit0.8.jar excalibur-testcase-1.0.jar

[stephan]

stephan 2003/01/27 12:07:16

  Modified:.build.xml
   tools/lib excalibur-testcase-1.0.jar
  Added:   src/test/org/apache/cocoon/components/source
SourceResolverAdapter.java
   src/test/org/apache/cocoon/generation
AbstractGeneratorTestCase.java
FileGeneratorTestCase.java
FileGeneratorTestCase.source.xml
FileGeneratorTestCase.xtest
   src/test/org/apache/cocoon/transformation
AbstractTransformerTestCase.java
   src/test/org/apache/cocoon/xml WhitespaceFilter.java
   tools/lib xmlunit0.8.jar
  Log:
  Add abstract test cases for generators and transformers, which
  allows to test these components outside of the cocoon
  enviroment.
  
  Revision  ChangesPath
  1.312 +3 -2  xml-cocoon2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/xml-cocoon2/build.xml,v
  retrieving revision 1.311
  retrieving revision 1.312
  diff -u -r1.311 -r1.312
  --- build.xml 25 Jan 2003 12:58:20 -  1.311
  +++ build.xml 27 Jan 2003 20:07:14 -  1.312
  @@ -2311,10 +2311,11 @@
 
 
   
  -  
  +  
 
 
 
  +  
   
 
   
  
  
  
  1.1  
xml-cocoon2/src/test/org/apache/cocoon/components/source/SourceResolverAdapter.java
  
  Index: SourceResolverAdapter.java
  ===
  /*
  
   
 The Apache Software License, Version 1.1
   
  
   Copyright (C) 1999-2002 The Apache Software Foundation. All rights reserved.
  
   Redistribution and use in source and binary forms, with or without modifica-
   tion, are permitted provided that the following conditions are met:
  
   1. Redistributions of  source code must  retain the above copyright  notice,
  this list of conditions and the following disclaimer.
  
   2. Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.
  
   3. The end-user documentation included with the redistribution, if any, must
  include  the following  acknowledgment:  "This product includes  software
  developed  by the  Apache Software Foundation  (http://www.apache.org/)."
  Alternately, this  acknowledgment may  appear in the software itself,  if
  and wherever such third-party acknowledgments normally appear.
  
   4. The names "Apache Cocoon" and  "Apache Software Foundation" must  not  be
  used to  endorse or promote  products derived from  this software without
  prior written permission. For written permission, please contact
  [EMAIL PROTECTED]
  
   5. Products  derived from this software may not  be called "Apache", nor may
  "Apache" appear  in their name,  without prior written permission  of the
  Apache Software Foundation.
  
   THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
   FITNESS  FOR A PARTICULAR  PURPOSE ARE  DISCLAIMED.  IN NO  EVENT SHALL  THE
   APACHE SOFTWARE  FOUNDATION  OR ITS CONTRIBUTORS  BE LIABLE FOR  ANY DIRECT,
   INDIRECT, INCIDENTAL, SPECIAL,  EXEMPLARY, OR CONSEQUENTIAL  DAMAGES (INCLU-
   DING, BUT NOT LIMITED TO, PROCUREMENT  OF SUBSTITUTE GOODS OR SERVICES; LOSS
   OF USE, DATA, OR  PROFITS; OR BUSINESS  INTERRUPTION)  HOWEVER CAUSED AND ON
   ANY  THEORY OF LIABILITY,  WHETHER  IN CONTRACT,  STRICT LIABILITY,  OR TORT
   (INCLUDING  NEGLIGENCE OR  OTHERWISE) ARISING IN  ANY WAY OUT OF THE  USE OF
   THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  
   This software  consists of voluntary contributions made  by many individuals
   on  behalf of the Apache Software  Foundation and was  originally created by
   Stefano Mazzocchi  <[EMAIL PROTECTED]>. For more  information on the Apache
   Software Foundation, please see .
  
  */
  
  package org.apache.cocoon.components.source;
  
  import java.io.IOException;
  import java.net.MalformedURLException;
  import java.util.Map;
  
  import org.apache.avalon.framework.component.Component;
  import org.apache.avalon.framework.component.ComponentException;
  import org.apache.avalon.framework.component.ComponentManager;
  
  import org.apache.cocoon.components.source.impl.AvalonToCocoonSource;
  import org.apache.cocoon.environment.SourceResolver;
  import org.apache.cocoon.environment.Source;
  import org.apache.cocoon.Proces

Re: cvs commit: xml-cocoon2/src/java/org/apache/cocoon/transformationEncodeURLTransformer.java

[Bernhard Huber]

hi,

[EMAIL PROTECTED] wrote:

cziegeler2003/01/26 23:43:33

  Modified:src/java/org/apache/cocoon/transformation
EncodeURLTransformer.java
  Log:
  - Fixing caching logic for encode url transformer

  - turning off caching, because you get wrong cached content, *if* the session is created during processing
  
thx for fixing the fix
bernhard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [RT] JavadocGenerator

[Bart Guijt]

Hi there,

As a result of gaining some hands-on Cocoon experience, I created a
JavadocSource and -SourceFactory which largely complies to what you are
discussing here.

Here are some feature hilights:
- uses the QDox parser;
- uses the Excalibur SourceResolver to resolve the source files;
- may be configured using multiple source root (uri's), like
 and

- creates inheritance information in the generated XML doc;
- comes with an XSLT stylesheet which creates a Class or Interface Javadoc
document (no package, overview, uses or index yet!) *exactly* like the JDK
javadoc;
- supports separately doc'ed inner classes;
- documents private members;
- the code has alpha status, but seems to works fine.


The JavadocSource is configured like this in cocoon.xconf:

  

  
  

  
  






  
  


  

  


If the following is put in the sitemap:


  
  
  



you can request live Javadoc with a URL like

http://localhost:8080/javadoc/java.util.HashMap


Would you like it as a donation to the Cocoon community?

Ciao,

Bart Guijt


- Original Message -
From: "Bernhard Huber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 8:53 AM
Subject: [RT] JavadocGeneratro , was [STATUS] qdox java generator


> hi,
>
> as we had some off line talking about a JavadocGenerator i'd like
> to discuss this further on the dev-list.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16248] - Reloading a modified page causes NPE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16248

Reloading a modified page causes NPE





--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 23:20 ---
I can confirm that the bug is for real and a major blocker.
The workaround is of course to use only NonCachingProcessingPipeline.

Btw is there anybody except CZ who understands the code in 
AbstractCachingProcessingPipeline?  The complexity is scary.  Just try to count 
the number of testcases needed to cover all possible execution paths.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Flow problems & question

[Gianugo Rabellino]

Ugo Cei wrote:

I'm stuck in front of a

TypeError: function WebContinuation() {
[native code]
}
is not a function. 
(resource://org/apache/cocoon/components/flow/javascript/system.js; 
line 29)


I don't get this error in my version, but it's not the latest. Actually, 
I'm reluctant to do a cvs update just now, for fear it might break my 
flows.

Gosh. Can you tell me what version you have so that I can try to check 
it out from CVS (and maybe try to understand what happened in between)?

OTOH, I gave a quick look to the object model, and found that there is 
no facility for logging. Is that on purpose? Have I heavily overlooked 
something?

There is:

log.debug('Nifty debug message');


OK, dumbass hat on. Thanks!

Ciao,

--
Gianugo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13541] - SAVE_UPLOAD_FILES_TO_DISK should be configurable

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13541

SAVE_UPLOAD_FILES_TO_DISK should be configurable

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 23:31 ---
xml-cocoon2/src/java/org/apache/cocoon/servlet/CocoonServlet.java

Revision 1.43 / (view) - annotate - [select for diffs] , Tue Oct 29 05:29:18 
2002 UTC (2 months, 4 weeks ago) by vgritsenko 
Branch: MAIN 
Changes since 1.42: +47 -16 lines 
Diff to previous 1.42 (colored) 
CocoonServlet upload behavior now configurable from the web.xml.
Configuration parameters are: autosave-uploads, overwrite-uploads,
upload-max-size. See web.xml for description.
Thanks to Geoff Howard.


Revision 1.19.2.14 / (view) - annotate - [select for diffs] , Tue Oct 29 
05:28:59 2002 UTC (2 months, 4 weeks ago) by vgritsenko 
Branch: cocoon_2_0_3_branch 
CVS Tags: cocoon_2_0_4 
Changes since 1.19.2.13: +47 -16 lines 
Diff to previous 1.19.2.13 (colored) to branch point 1.19 (colored) to next 
main 1.20 (colored) 
CocoonServlet upload behavior now configurable from the web.xml.
Configuration parameters are: autosave-uploads, overwrite-uploads,
upload-max-size. See web.xml for description.
Thanks to Geoff Howard.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/util/log CocoonLogFormatter.java XMLCocoonLogFormatter.java

[vgritsenko]

vgritsenko2003/01/27 17:18:33

  Modified:src/java/org/apache/cocoon/util/log CocoonLogFormatter.java
XMLCocoonLogFormatter.java
  Log:
  remove unused variable and add some javadoc
  
  Revision  ChangesPath
  1.7   +3 -4  
xml-cocoon2/src/java/org/apache/cocoon/util/log/CocoonLogFormatter.java
  
  Index: CocoonLogFormatter.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/util/log/CocoonLogFormatter.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CocoonLogFormatter.java   26 Jun 2002 22:25:56 -  1.6
  +++ CocoonLogFormatter.java   28 Jan 2003 01:18:33 -  1.7
  @@ -76,7 +76,6 @@
* @author mailto:[EMAIL PROTECTED]";>Sylvain Wallez
* @version CVS $Id$
*/
  -
   public class CocoonLogFormatter extends ExtensiblePatternFormatter
   {
   protected final static int TYPE_CLASS  = MAX_TYPE + 1;
  @@ -104,8 +103,9 @@
* stack. The element at index 0 is the class of the currently executing
* method, the element at index 1 is the class of that method's caller,
* and so on.
  + *
  + * @return current execution stack as an array of classes.
*/
  -
   public Class[] get()
   {
   return getClassContext();
  @@ -260,5 +260,4 @@
   {
   return this.dateFormatter.format(new Date());
   }
  -
   }
  
  
  
  1.7   +9 -15 
xml-cocoon2/src/java/org/apache/cocoon/util/log/XMLCocoonLogFormatter.java
  
  Index: XMLCocoonLogFormatter.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/util/log/XMLCocoonLogFormatter.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- XMLCocoonLogFormatter.java22 Feb 2002 07:03:58 -  1.6
  +++ XMLCocoonLogFormatter.java28 Jan 2003 01:18:33 -  1.7
  @@ -293,10 +293,11 @@
* Find the thread that is logged this event.
*/
   private String getThread(ContextMap ctxMap) {
  -if (ctxMap != null&& ctxMap.get("threadName") != null)
  +if (ctxMap != null && ctxMap.get("threadName") != null) {
   return (String)ctxMap.get("threadName");
  -else
  +} else {
   return "Unknown-thread";
  +}
   }
   
   /**
  @@ -342,17 +343,9 @@
   } else {
   // this is not the best implementation, but it works...
   StringTokenizer st = new StringTokenizer(typeString);
  -int i = 0;
  -while (st.hasMoreTokens()) {
  -String s = st.nextToken();
  -i++;
  -}
  -st = new StringTokenizer(typeString);
  -this.types = new int[i];
  -i = 0;
  -while (st.hasMoreTokens()) {
  +this.types = new int[st.countTokens()];
  +for (int i = 0; i < this.types.length; i++) {
   this.types[i] = this.getTypeIdFor(st.nextToken());
  -i++;
   }
   }
   }
  @@ -360,6 +353,7 @@
   /** The class that we will search for in the call stack */
   private Class loggerClass = org.apache.log.Logger.class;
   private CallStack callStack = new CallStack();
  +
   /**
* Hack to get the call stack as an array of classes. The
* SecurityManager class provides it as a protected method, so
  @@ -373,12 +367,12 @@
* stack. The element at index 0 is the class of the currently executing
* method, the element at index 1 is the class of that method's caller,
* and so on.
  + *
  + * @return current execution stack as an array of classes.
*/
  -
   public Class[] get()
   {
   return getClassContext();
   }
   }
  -
   }
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]

[Jeff Turner]

On Mon, Jan 27, 2003 at 11:47:03AM +0100, Stefano Mazzocchi wrote:

> Yes, I'm pissed.

No-one's perfect.  There's few better examples of
screw-up/apologise/move-on committers than Nicola.

--Jeff
(who frequently screws up)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: What is a Parser?

[Jeff Turner]

On Mon, Jan 27, 2003 at 07:19:05PM +0100, Ugo Cei wrote:
> Once upon a time there was a org.apache.cocoon.components.parser.Parser, 
> but now it's deprecated. OK, so I think I should use the Excalibur 
> parser component, which has recently been split into a SAX parser and a 
> DOM parser.
> 
> Looking in excalibur-xmlutil-20030122.jar, I found this class: 
> org.apache.excalibur.xml.sax.Parser.

I guess you mean o.a.e.xml.sax.SAXParser (to complement
o.a.e.xml.dom.DOMParser).

> Maybe I can use that. This is my first try:
> 
> org.apache.excalibur.xml.sax.Parser saxParser = null;
> try {
>   saxParser = (org.apache.excalibur.xml.sax.Parser)
> manager.lookup(org.apache.excalibur.xml.sax.Parser.ROLE);
> }
> finally {
>   if (saxParser != null) manager.release(saxParser);
> }
> 
> Unfortunately, it doesn't compile, because Parser does not implement 
> Component
>
> so I resolve the problem with a cast:
> 
>   if (saxParser != null) manager.release((Component) saxParser);

(cripes.. I've been happily nulling it in my code.. I'd better go fix:)

> I'm starting to feel a little bit confused, because I was not aware that 
> in Java you could get away with that at compile time.

You should get back a JaxpParser instance, which is a Component, so the
cast is valid.  I'd imagine the compiler doesn't realise this at
compile-time, and you'd get a ClassCastException if it wasn't a
Component.

> Maybe I should have a look at the JLS, but since I'm lazy and my code
> runs, I figure I'd better ask cocoon-dev ;-).
> 
> Is this the kosher way of obtaining an XML parser in Cocoon 2.1?
> 
> To further complicate things, Eclipse does not like my little class 
> which implements org.apache.avalon.framework.component.Component, since 
> it insists that the type Component is deprecated, along with 
> ComponentManager. In order to play by the rules, I've removed 
> "Component" from the interfaces my class implements, but Cocoon (or is 
> it Excalibur?) barfs with a "ClassCastException" when I try to put it in 
> cocoon.xconf. Well, I just put back the "implements Component" 
> declaration and live with Eclipse's warnings, but I cannot help feeling 
> a little disoriented about all this ;-).

Yes, those deprecation warnings are annoying and misleading, because
Component is deprecated for Avalon, not Cocoon.  Perhaps Cocoon should
have a special avalon-framework-nodepr-4.1.3.jar , without the
@deprecated?


--Jeff

>   Ugo
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [PATCH QUEUE] Summary January 28 2003

[nicolaken]

---
 This mail is generated automatically using
 Jakarta Ant. Contents are automatically
 downloaded from Apache's Bugzilla.
---
 Please do not reply to this mail.
---

***
COCOON PATCH QUEUE UPDATE
 
patches in queue:  29 
***


---
9728:[PATCH] CocoonServlet getClassPath() enhancements Tomcat4
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9728

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
11533:[PATCH] Replacement for AvalonToCocoonSource
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11533

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
11549:[PATCH] Replace LogKitManageable through LoggerManageable
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11549

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
11861:[PATCH] extend castortransformer to handle collections
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11861

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
12173:[PATCH] SQLTransformer Query object prematurely closes conne
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12173

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
12235:[PATCH] XPathTransformer
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12235

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
12993:[PATCH] New version of CastorTransformer (includes marshalli
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12993

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14117:[PATCH] AuthAction fails in sub-requests
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14117

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14144:[Patch] add CompressionFilter declaration to web.xml
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14144

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14327:[PATCH] JSPEngineImpl response charset should be specified w
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14327

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14803:[PATCH] cacheable.xsp for new AbstractServerPages
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14803

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14845:[PATCH] Patch to generate a key with new resources in XMLDBT
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14845

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
14986:[PATCH] Enables velocitygenerator to get objects from reques
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14986

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
15100:[patch]/[donation] Sample app xml form popup with sourcewrit
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15100

REVIEWER:[EMAIL PROTECTED]
RESOLUTION:  
STATUS:  NEW
---
15150:[PATCH]: HSSFSerializer Support for Gnumeric MergedRegions
---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15150

REVIEWER

Re: [ESQL] Improvement....

[Niclas Hedhman]

On Tuesday 28 January 2003 01:32, Hunsberger, Peter wrote:
> >> if (exist )
> >>LIMIT 5+1
> >> else
> >>LIMIT 5
> >>
> >> I think this is an elegant solution. What you think?
> >
> > Sure - but the problem is that we also would need to adjust the length
> > of the resultset inside the helper class. (you always want to see only 5
> > rows in your page)
> >
> > The length of the resultset inside the class would sometimes be one more
> > and sometimes *exact* - depending on whether there is a 
> > tag or not. Which would be very confusing!
> >
> > Give me a day to think about this...
>
> Torsten,
>
> You're chasing a non-existent problem.  There is never a real life case
> that will have both good performance for N records and bad performance for
> N+1 records.  The only way you can guarantee having good performance for N
> records is if you can build an index.  If you can build an index then the
> search will always terminate after looking at N+1 records.

I give you a "real world" case;

In natural language;
Give me the first COLOR (3D point) which resides not further than dE units 
from COLOR [L1, a1, b1].

In SQL database, I can only place the L, a, b columns, individually, and the 
spherical search would be;

WHERE SQRT( SQ( L - L1 ) + SQ( a - a1) + SQ( a - a2 ) ) < dE

where L1, a1, b1 and dE are parameters given at the invocation of the Select 
statement.


I could go into a long discussion how this could be optimized, both in SQL 
(multi-levelled subqueries and regeneration of indexes) and internal to the 
DB engine (3D indecies), but I won't.


If I have a well populated database, evenly and randomly spread out, I will on 
the average have a 100% penalty on LIMIT N+1, as the search will go through 
roughly the same number of records to find the "next one", which I don't care 
about.

Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [ESQL] Improvement....

[Niclas Hedhman]

On Tuesday 28 January 2003 13:02, Niclas Hedhman wrote:
>100% penalty on LIMIT N+1

Ooops, forgot "when N=1"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [RT] JavadocGenerator

[Sylvain Wallez]

Bart Guijt wrote:


Hi there,

As a result of gaining some hands-on Cocoon experience, I created a
JavadocSource and -SourceFactory which largely complies to what you are
discussing here.

Here are some feature hilights:
- uses the QDox parser;
- uses the Excalibur SourceResolver to resolve the source files;
- may be configured using multiple source root (uri's), like
 and

www/api>
- creates inheritance information in the generated XML doc;
- comes with an XSLT stylesheet which creates a Class or Interface Javadoc
document (no package, overview, uses or index yet!) *exactly* like the JDK
javadoc;
- supports separately doc'ed inner classes;
- documents private members;
- the code has alpha status, but seems to works fine.


The JavadocSource is configured like this in cocoon.xconf:

 
   
class="info.guijt.cocoon.source.JavadocSourceFactory" name="javadoc">
 
 
   
 
 
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon/src/java" />
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon-logkit/src/java" />
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon-excalibur/component/src/
java" />
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon-excalibur/sourceresolve/
src/java" />
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon-excalibur/pool/src/java"
/>
   
uri="file://D:/cvs-workspaces/apache/jakarta-avalon-excalibur/xmlutil/src/ja
va" />
 
 
   
uri="file://D:/cvs-workspaces/apache/xml-cocoon2/src/java" />
   
uri="file://D:/cvs-workspaces/apache/xml-cocoon2/src/deprecated/java" />
 
   
 


If the following is put in the sitemap:

   
 
 
 
   


you can request live Javadoc with a URL like

   http://localhost:8080/javadoc/java.util.HashMap


Would you like it as a donation to the Cocoon community?
 


This looks _really cool_, and a donation to Cocoon would be more that 
welcome !

A little question, though : does  handle URIs other than 
file, i.e. does use the SourceResolver ?

This would allow following :


Live Javadoc generation from the CVS repository. Cool, eh ?

Sylvain

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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16248] - Reloading a modified page causes NPE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16248

Reloading a modified page causes NPE

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

[cziegeler]

cziegeler2003/01/27 23:23:35

  Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
  Log:
  First fix for 16248 - need some more investigation
  
  Revision  ChangesPath
  1.23  +13 -14
xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java
  
  Index: AbstractCachingProcessingPipeline.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- AbstractCachingProcessingPipeline.java15 Jan 2003 12:28:17 -  1.22
  +++ AbstractCachingProcessingPipeline.java28 Jan 2003 07:23:35 -  1.23
  @@ -463,19 +463,6 @@
   }
   // we are not valid!
   
  -// try a shorter key
  -if (i > 0) {
  -this.fromCacheKey.removeLastKey();
  -if (!this.completeResponseIsCached) {
  -this.firstProcessedTransformerIndex--;
  -}
  -} else {
  -this.fromCacheKey = null;
  -}
  -
  -this.completeResponseIsCached = false;
  -finished = false;
  -
   if (!responseIsUsable) {
   // we could not compare, because we got no
   // validity object, so shorten pipeline key
  @@ -496,6 +483,18 @@
   // the entry is invalid, remove it
   this.cache.remove( this.fromCacheKey );
   }
  +
  +// try a shorter key
  +if (i > 0) {
  +this.fromCacheKey.removeLastKey();
  +if (!this.completeResponseIsCached) {
  +this.firstProcessedTransformerIndex--;
  +}
  +} else {
  +this.fromCacheKey = null;
  +}
  +
  +this.completeResponseIsCached = false;
   }
   } else {
   
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl AbstractCachingProcessingPipeline.java

[cziegeler]

cziegeler2003/01/27 23:34:17

  Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
  Log:
  First fix for 16248 - need some more investigation
  
  Revision  ChangesPath
  1.24  +3 -3  
xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java
  
  Index: AbstractCachingProcessingPipeline.java
  ===
  RCS file: 
/home/cvs/xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- AbstractCachingProcessingPipeline.java28 Jan 2003 07:23:35 -  1.23
  +++ AbstractCachingProcessingPipeline.java28 Jan 2003 07:34:17 -  1.24
  @@ -493,7 +493,7 @@
   } else {
   this.fromCacheKey = null;
   }
  -
  +finished = false;
   this.completeResponseIsCached = false;
   }
   } else {
  @@ -505,7 +505,7 @@
   "' using key: " +  this.fromCacheKey
   );
   }
  -
  +   
   if (!this.doSmartCaching) {
   // try a shorter key
   if (this.fromCacheKey.size() > 1) {
  
  
  

--
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail:  [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RT] JavadocGenerator

[Bertrand Delacretaz]

Bart Guijt wrote:

Hi there,

As a result of gaining some hands-on Cocoon experience, I created a
JavadocSource and -SourceFactory which largely complies to what you are
discussing here.

>...

Yes! Yes! Wow!

Obviously a donation is most welcome, we need this to implement our 
"User Reference Pages" based on javadoc tags.

I think Bernhard has been working on something too, so some merging of 
ideas/code might be good once the code is in CVS.

-Bertrand



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote:


Nicola, you crossed the line.


Sorry :-/

Luca and all cocoon-dev, please accept my sincere apologies.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

SourceResolver missing from HEAD

[Upayavira]

Dear All,

I am starting to explore the inner workings of Cocoon 2.1, and have been trying to 
compile my own components within it.

However, whilst I have been able to compile it from the command line, when I look 
at some classes in an IDE, it appears that many of them use 
org.apache.cocoon.environment.SourceResolver, which is not in the current code 
base.

I presume that this functionality has been moved to Avalon Excalibur, but some 
classes have not been refactored to take this into account.

Am I correct, or am I missing something obvious.

I found this in connection with a bug I have found in the ImageReader (it doesn't 
take the width&height into account when caching, thus won't render the same 
image at different resolutions - crucial functionality to a photo album site). If I 
can 
resolve this SourceResolver problem, I will test an extremely simple patch for the 
ImageReader and post it.

Regards,

Upayavira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: SourceResolver missing from HEAD

[Carsten Ziegeler]

Hi,

the SourceResolver is still there, it has only been moved
into the src/deprecated directory.

HTH
Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG


> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 27, 2003 11:32 PM
> To: [EMAIL PROTECTED]
> Subject: SourceResolver missing from HEAD
> 
> 
> Dear All,
> 
> I am starting to explore the inner workings of Cocoon 2.1, and 
> have been trying to 
> compile my own components within it.
> 
> However, whilst I have been able to compile it from the command 
> line, when I look 
> at some classes in an IDE, it appears that many of them use 
> org.apache.cocoon.environment.SourceResolver, which is not in the 
> current code 
> base.
> 
> I presume that this functionality has been moved to Avalon 
> Excalibur, but some 
> classes have not been refactored to take this into account.
> 
> Am I correct, or am I missing something obvious.
> 
> I found this in connection with a bug I have found in the 
> ImageReader (it doesn't 
> take the width&height into account when caching, thus won't 
> render the same 
> image at different resolutions - crucial functionality to a photo 
> album site). If I can 
> resolve this SourceResolver problem, I will test an extremely 
> simple patch for the 
> ImageReader and post it.
> 
> Regards,
> 
> Upayavira
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]