date:20040416

2004-04-16 Thread Hamilton Verissimo de Oliveira (Engenharia - SPO)

Joerg Heinicke wrote:

On 16.04.2004 16:47, Ugo Cei wrote:

The conventional wisdom is that it's better to have the compiler 
remind you that you have to catch most exceptions, because that's part 
of the contract. My opinion, instead, is that checked exceptions are a 
very bad way of enforcing contracts between callers and callees.
This is where I don't follow you.
It's a question of where to handle the exceptions.  Many projects have a
way of handling arbitrary exceptions that slip through the cracks.
Checked exceptions encourage handling the exception as close to the
cause as possible.  Unchecked exceptions encourage global exception
handling.
In many situations, allowing exceptions to be propagated to the sitemap
would actually be preferred.  Most examples in the cocoon codebase seem
to support that notion.  There are times where it does make sense to
handle close to the cause of the exception, but that is usually only
when you have an alternative way to get the information.
What I hate in Java are untyped collections, that force me to cast when 
retrieving an object out of them, and long vs. Long (was it called 
auto-boxing?). Both will be fixed in Java 1.5 IIRC.
Be careful with this.  In my initial testing with Java 1.5, it is still
quite easy to circumvent typed collections.  I highly recommend using
the "-Xlint:all" command line argument for the javac compiler.  It will
warn you if you cast a typed collection to an untyped collection.
It does clean up a lot of cruft in your code that makes it really nice.
Not to mention the new java.lang.StringBuilder will also provide more
optimization.  The only difference between StringBuilder and
StringBuffer is that the StringBuilder is unsynchronized--it is finally
offered because most usages of StringBuffer are all within the same
thread.  Lower thread contention means faster runtime.

Re: Avalon Logkit 1.2.2 - myth or reality?


Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
> >It's reality - the next version will be 2.0 (if any).
> >
> >Look here:
> >
> >http://www.apache.org/dist/avalon/logkit/jars/
> >
> >
>
> I took
> http://www.apache.org/dist/avalon/logkit/source/logkit-1.2.2-src.zip and
> found 1.2.2-*dev* inside!
>
> And, where is the source (I mean, CVS)? I don't see a tag.


The source is in the brand new avalon-logkit module.

http://cvs.apache.org/viewcvs.cgi/avalon-logkit/


Cheers,
hammett

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Joerg Heinicke

On 16.04.2004 16:47, Ugo Cei wrote:

The compiler forces you to catch them.
Of course, but only exactly once at the end. How are the exceptions made
available to handle-errors at the moment? I guess somewhere in the tree
processor. So where is the problem letting it catch the exception? I 
still don't
see the need for the re-parenting.
No. Assuming there are several layers, currently the compiler forces you 
to catch the exception at every layer or declare it in the throws clause 
(which might be impossible if you're implementing an interface).

On the contrary, if PE extends RuntimeCascadingException, you have the 
freedom to catch it only in the outermost layer, that would probably be 
the sitemap processor. Or you can catch it wherever you like.

The conventional wisdom is that it's better to have the compiler remind 
you that you have to catch most exceptions, because that's part of the 
contract. My opinion, instead, is that checked exceptions are a very bad 
way of enforcing contracts between callers and callees.
This is where I don't follow you.

The conventional wisdom is also that strong type checking helps in 
enforcing contracts. Judging from the recent flourishing of untpyed or 
weakly-typed languages like Python, Ruby, Groovy or Javascript [1], I'd 
be inclined to doubt that wisdom too.
Same here. Do you remember this one: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107901388024464&w=4 ?? 
If I change the implementation to a Set the statement will fail. I need 
many more tests than with strong-typing. But the same way I do not want 
to care about request and form handling - I use an abstracting framework 
for it, and care only about business logic - I do not want to care about 
testing correct types. The only tests I want to write are about business 
logic.

What I hate in Java are untyped collections, that force me to cast when 
retrieving an object out of them, and long vs. Long (was it called 
auto-boxing?). Both will be fixed in Java 1.5 IIRC.

Joerg

[1] :

function myflow() {
  var obj = cocoon.getComponent(id);
  obj.someMethodThrowingCheckedException();
  // What? No cast? No try-catch? Where's the compiler??? ;-)
}

Re: Avalon Logkit 1.2.2 - myth or reality?

Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
> >It's reality - the next version will be 2.0 (if any).
> >
> >Look here:
> >
> >http://www.apache.org/dist/avalon/logkit/jars/
> >
> >
>
> I took
> http://www.apache.org/dist/avalon/logkit/source/logkit-1.2.2-src.zip and
> found 1.2.2-*dev* inside!
>
> And, where is the source (I mean, CVS)? I don't see a tag.
>
Oh, not every project has a release manager like Cocoon has :)
I think it got forgotten and wasn't checked properly. I fear the only
chance you have is to look when it was released (find the announcement
mail) and take the code from that day from CVS. LogKit hasn't changed
in that time. After the 1.2.2 all deprecated code has been removed and
the version had been changed to 2.0. Rumours are that a 2.0 release
will be out soon, but that depends on some people at Avalon doing it.

Carsten

Re: Avalon Logkit 1.2.2 - myth or reality?

2004-04-16 Thread Vadim Gritsenko

Carsten Ziegeler wrote:

It's reality - the next version will be 2.0 (if any).

Look here:

http://www.apache.org/dist/avalon/logkit/jars/
 

I took 
http://www.apache.org/dist/avalon/logkit/source/logkit-1.2.2-src.zip and 
found 1.2.2-*dev* inside!

And, where is the source (I mean, CVS)? I don't see a tag.

Vadim

Re: Avalon Logkit 1.2.2 - myth or reality?

2004-04-16 Thread Jörg Schaible

Vadim Gritsenko wrote:

> Hi guys,
> 
>  From http://www.apache.org/dist/avalon/avalon-logkit/distributions/ (or
> http://archive.apache.org/dist/avalon/avalon-logkit/distributions/):
> ---
> Index of /dist/avalon/avalon-logkit/distributions
> 
>  Name   Last modified  Size  Description
> Parent Directory-
>  avalon-logkit-2.0.dev-0-src.tar.gz 11-Apr-2004 09:14   58K
>  avalon-logkit-2.0.dev-0-src.zip11-Apr-2004 09:14  127K
>  avalon-logkit-2.0.dev-0.tar.gz 11-Apr-2004 09:14  309K
>  avalon-logkit-2.0.dev-0.zip11-Apr-2004 09:14  611K
> 
> Apache/2.0.49-dev (Unix) Server at www.apache.org Port 80
> ---

http://www.apache.org/dist/avalon/logkit/jars/

Logkit was renamed to Avalon-Logkit recently to reflect the package's home.

Regards,
Jörg

Re: Avalon Logkit 1.2.2 - myth or reality?

It's reality - the next version will be 2.0 (if any).

Look here:

http://www.apache.org/dist/avalon/logkit/jars/


Carsten

"Vadim Gritsenko" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
> Hi guys,
>
>  From http://www.apache.org/dist/avalon/avalon-logkit/distributions/ (or
> http://archive.apache.org/dist/avalon/avalon-logkit/distributions/):
> ---
> Index of /dist/avalon/avalon-logkit/distributions
>
>  Name   Last modified  Size  Description
> Parent Directory-
>  avalon-logkit-2.0.dev-0-src.tar.gz 11-Apr-2004 09:14   58K
>  avalon-logkit-2.0.dev-0-src.zip11-Apr-2004 09:14  127K
>  avalon-logkit-2.0.dev-0.tar.gz 11-Apr-2004 09:14  309K
>  avalon-logkit-2.0.dev-0.zip11-Apr-2004 09:14  611K
>
> Apache/2.0.49-dev (Unix) Server at www.apache.org Port 80
> ---
>
>
>  From http://cvs.apache.org/viewcvs.cgi/avalon-logkit/ :
> ---
>
> LOGKIT_2_0_RC2
> LOGKIT_2_0_RC1
> LOGKIT_1_3_RC1
> LogKit_1_2b7
>
> <>LOGKIT_1_2_FINAL
> LogKit_1_1
> LogKit_1_0_Final
> LogKit_1_0_1
> LogKit-1_0b5
> LogKit-1_0b4
> LogKit-1_0b3
> LogKit-1_0b2
> LogKit-1_0b1
> HEAD
> <>---
>
>
> Now the question -- where logkit-1.2.2.jar which I see in Cocoon CVS is
> coming from???
>
>
> PS Actually, all I want to know is why  id="console">System.out does not
> format date in readable format... But I need source to find this out.
>
> Vadim
>
>

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Guido Casper wrote:
Ugo Cei wrote:

WebDAVRepository.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error saving dom to: " + this.repoBaseUrl 
+ uri, pe);
  }

WebDAVRepositoryPropertyHelper.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error serializing node " + value, pe);
  }


Ehm, I didn't follow all the discussions very closely, but if you want
to remove something please be aware that these Exceptions are not just
swallowed (don't know about the others) since after the catch clause
follows a "return false;"
Indeed, we should carefully check every one of the samples I have 
pasted, before changing them. Particularly those that don't rethrow an 
exception.

At the very least, we can say that the usage of exceptions in this case 
looks suspiciously like an instance of controlling the flow of the 
application with exceptions.

The problem is that the call that mandated the use of the "catch" might 
fail and throw a runtime exception (say, a NPE) instead. If you want the 
call to setProperty to always fail graciously, you'd better 
catch(Exception) instead, don't you agree?

	Ugo

DO NOT REPLY [Bug 28424] - [PATCH] Allow applications access to the start and end of a request

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://issues.apache.org/bugzilla/show_bug.cgi?id=28424

[PATCH] Allow applications access to the start and end of a request

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 16:59 ---
*** Bug 28279 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 28279] - [PATCH] Logging all requests

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://issues.apache.org/bugzilla/show_bug.cgi?id=28279

[PATCH] Logging all requests

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 16:59 ---
See the more generic approach in bug #28424.

*** This bug has been marked as a duplicate of 28424 ***

[cforms] Weird behaviour of flow and fb:javascript binding

2004-04-16 Thread Gianugo Rabellino

We are currently building a cforms based application with fairly decent 
complexity level. Our (rather convoluted but, take my word for that, 
legit) business logic requires the usage of an Avalon component during 
the binding phase, so we thought to use the fb:javascript binding 
method, hoping to find (even if not explicitely documented) the good old 
FOM, together with the cocoon object.

That was indeed the case, and we were cheerfully using logic like the 
one in the following snippet:


   var validation = cocoon.getComponent("bindinghelper");
   var today = new Packages.java.util.GregorianCalendar();
   var executionDate = validation.getValidExecutionDate(today);
   widget.setValue(executionDate.getTime());

At a certain point, though, we mangled the form *definition* and 
modified a selection list so that it was taking its data from a cocoon:/ 
pipeline instead than from a static file (which we used during 
prototyping). Such pipeline, in turns, calls the flow which sendPage()s 
to a JXTG (data are in a business object we need to stream):





  
  
  

(now, talking about tangled web of pipelines calling flow calling 
pipelines... but anyway)

Here is where crap happens. In our binding phase the cocoon object isn't 
there anymore:

"file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/resources/forms/italian-transfer-bind-bean.xml", 
line 5: uncaught JavaScript exception:
at insertItalianTransfer 
(file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/flow/italianTransfer.js, 
Line 42)
at  (resource://org/apache/cocoon/forms/flow/javascript/v2/Form.js, Line 
158):
ReferenceError: "cocoon" is not defined. 
(file:/Users/gianugo/dev/src/newcorporate/src/build/webapp/italiantransfer/resources/forms/italian-transfer-bind-bean.xml; 
line 5)

and we are unable to run our binding code. Debugging 
o.a.c.f.util.JavascriptHelper, it turns out that the parent scope in our 
first scenario is a FOM, while the insertion in the definition of the 
dynamic list, (apparently) causing another flow call to happen, leaves 
an empty NativeObject in place of the FOM.

OK, I hope you're still with me until now. :-) Questions follow:

1. is this an expected behaviour?

2. would it be possible/make sense to ensure that even javascript 
bindings get a FOM object?

3. if not, what is the alternative? Writing a custom binding? Really? :-/

Thanks for your time on this. I'm really banging my head against this 
issue and can't quite see a way out as of now.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)

DO NOT REPLY [Bug 28424] - [PATCH] Allow applications access to the start and end of a request

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://issues.apache.org/bugzilla/show_bug.cgi?id=28424

[PATCH] Allow applications access to the start and end of a request





--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 16:56 ---
I also prefer the solution of having one Listener which is a ListenerManager and
delegates the calls to the Listeners. The implementation is completely up to the
user, e.g. for conditional IP-based calls.

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Guido Casper

Ugo Cei wrote:
WebDAVRepository.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error saving dom to: " + this.repoBaseUrl + 
uri, pe);
  }

WebDAVRepositoryPropertyHelper.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error serializing node " + value, pe);
  }
Ehm, I didn't follow all the discussions very closely, but if you want
to remove something please be aware that these Exceptions are not just
swallowed (don't know about the others) since after the catch clause
follows a "return false;"
Guido

--
Guido Casper
-
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5mailto:[EMAIL PROTECTED]
D-33100 Paderborn   http://www.s-und-n.de
-

Re: Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

Ugo Cei wrote:

a more serious issue.  You cannot go by the type of exception alone.  
By allowing the ProcessingException to have this additional 
information embedded, the Sitemap can better handle creating more 
accurate error pages.


I'm confused here. Doesn't it already have it embedded?
only by exception heirarchy.  For instance, the 
ResourceNotFoundException is a Processing exception, which provides the 
hint that it is a 404 error.

Now it would be just as easy to allow the embedding of an error code so 
that we can handle any arbitrary issue.  Another example is the 403 
authorization error.  I don't think we have a specific exception for that.

According to what I see:

http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/java/org/apache/cocoon/ProcessingException.java?view=markup

There is no get/set error code for the exception.  Adding one is 
backwards compatible, and then using the error code is something that 
can be done in the sitemap.

Our exception inheritance structure would allow automatic setting of the 
appropriate error code for that exception type so you don't loose the 
convenience, but you can still handle error codes that aren't 
specifically handled right now.

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Nicola Ken Barozzi wrote:
Since you know that we have dozens of places in the code with this 
thing, do you care posting a dozen of them here?
AbstractCommandLineEnvironment.java:

  } catch (ProcessingException pe) {
throw new CascadingIOException("ProcessingException: " + pe, pe);
  }
HTMLTransformer.java (this is wicked!):

  } catch (ProcessingException e) {
e.printStackTrace();
  }
XMidiSerializer.java (does it twice):

  } catch (ProcessingException e) {
throw new SAXException(e);
  } catch (IOException e) {
AuthenticationContext.java (at least we rethrow a runtime exception here):

  } catch (ProcessingException pe) {
throw new CascadingRuntimeException("Unable to create simple 
context.", pe);
  }

DefaultHandlerManager.java:

  } catch (ProcessingException se) {
throw new ConfigurationException("Exception during configuration of 
handler: " + name, se);
  }

PipelineAuthenticator.java (might be legit here, but if it is, should 
use "warn", shouldn't it?):

  } catch (ProcessingException local) {
this.getLogger().error("authenticator: " + local.getMessage(), local);
exceptionMsg = local.getMessage();
  }
XMLDBSource.java:

  } catch (ProcessingException pe) {
throw new SAXException("ProcessingException", pe);
  }
SQLTransformer.java (does it twice):

  } catch (ProcessingException pe) {
throw new SAXException(pe);
  }
CachingSource.java (does it three times):

  catch(ProcessingException e) {
throw new CascadingIOException("Failure storing response.", e);
  }
BookmarkAction.java:

  } catch (ProcessingException se) {
throw new ParameterException("Unable to read configuration from " + 
configurationFile, se);
  } catch (SAXException se) {

ApplicationCopletAdapter.java (swallowed twice):

  catch (ProcessingException ex) {
getLogger().error("Could not create new coplet instance", ex);
  }
  ...
  catch (ProcessingException pe) {
getLogger().error(
  "Error while getting portal application configuration for coplet "
+ coplet.getId(),
pe);
  }
DefaultLayoutFactory.java:

  } catch (ProcessingException pe) {
throw new CascadingRuntimeException("Exception during removal.", pe);
  }
BasketLayoutManagerImpl.java (swallowed three times, logged once):

  } catch (ProcessingException pe) {
this.getLogger().warn("Unable to create new instance.", pe);
  } catch (ServiceException se) {
DASLTransformer.java:

  } catch (ProcessingException e) {
throw new SAXException("Unable to fetch the query data:", e);
  }
WebDAVRepository.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error saving dom to: " + this.repoBaseUrl + 
uri, pe);
  }

WebDAVRepositoryPropertyHelper.java (swallowed):

  } catch (ProcessingException pe) {
this.getLogger().error("Error serializing node " + value, pe);
  }
That's 23, then I stopped pasting. But considering all the catch clauses 
for ProcessingException and its subclasses we have:

ProcessingException: 64 occurences
ConnectionResetException: 4 occurences
ResourceNotFoundException: 10 occurrences
But ProcessingException is just one example. Avalon's CascadingException 
 has 14 children exception classes. For instance, 
org.apache.avalon.framework.configuration.ConfigurationException, which 
is heavily used by CForms for doing things like:

  throw new ConfigurationException("Convertor defined in plain 
attribute unavailable.", e);

Now, don't tell me that distributing an incorrect configuration file is 
not a programming error. Do contracts also cover the case of programming 
errors? I suspect this should be a runtime exception. Better yet, when 
we have Java 1.4 as a requirement, this should be:

	assert false, "Convertor defined in plain attribute unavailable.";

	Ugo

Avalon Logkit 1.2.2 - myth or reality?

2004-04-16 Thread Vadim Gritsenko

Hi guys,

From http://www.apache.org/dist/avalon/avalon-logkit/distributions/ (or 
http://archive.apache.org/dist/avalon/avalon-logkit/distributions/):
---
Index of /dist/avalon/avalon-logkit/distributions

Name   Last modified  Size  Description 
Parent Directory-  
avalon-logkit-2.0.dev-0-src.tar.gz 11-Apr-2004 09:14   58K 
avalon-logkit-2.0.dev-0-src.zip11-Apr-2004 09:14  127K 
avalon-logkit-2.0.dev-0.tar.gz 11-Apr-2004 09:14  309K 
avalon-logkit-2.0.dev-0.zip11-Apr-2004 09:14  611K 

Apache/2.0.49-dev (Unix) Server at www.apache.org Port 80
---
From http://cvs.apache.org/viewcvs.cgi/avalon-logkit/ :
---
LOGKIT_2_0_RC2
LOGKIT_2_0_RC1
LOGKIT_1_3_RC1
LogKit_1_2b7
<>LOGKIT_1_2_FINAL
LogKit_1_1
LogKit_1_0_Final
LogKit_1_0_1
LogKit-1_0b5
LogKit-1_0b4
LogKit-1_0b3
LogKit-1_0b2
LogKit-1_0b1
HEAD
<>---
Now the question -- where logkit-1.2.2.jar which I see in Cocoon CVS is 
coming from???

PS Actually, all I want to know is why System.out does not 
format date in readable format... But I need source to find this out.

Vadim

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Nicola Ken Barozzi wrote:
You are forced by a contract, just as you are forced by other types.
Personally, I don't buy this "design by contract" thing, I much prefer 
"design by testing", or "Test Driven Design", if you prefer :-).

He should blame the fact that he does not have ProcessingException in 
*it's* throws cause even if he cannot cope with it.
Since he's implementing an interface that doesn't declare it in its 
"throws" clause, he has no choice.

I never remove code smell. If it works, don't touch it, even if it 
smells. If it doesn't work, fix it. Code beauty and lack of odor only 
creates nice empty boxes, and I know something about it unfortunately.
I see we have widely divergent opinions on this. I believe that code 
rots unless you continuously refactor it. I believe that you should fix 
broken windows, even if you live in Barbados, before the whole house 
starts crumbling down.

If you don't agree, then what is your proposal?
   catch (ProcessingException e) {

 //see if I *really* need to rethrow it

 throw new *Exception(*, e);
   }
Do you plan to go over our codebase and, for every such case, evaluate 
if we *really* need to rethrow it?

Get it right with 2.2 by defining the contract with the container, IE 
what the component.
Hmmm, maybe you truncated the sentence a little too early here: "what 
the component ..."?

Anyway, my take on this is that trying to enumerate in a contract 
everything that might possibly go wrong is impossible. But, as I said, 
we have plenty of time to discuss this before 2.2. This call for votes 
is for 2.1.

Since you know that we have dozens of places in the code with this 
thing, do you care posting a dozen of them here?
OK, stay tuned.

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Geoff Howard

Ugo Cei wrote:

Geoff Howard wrote:

If the end-result of this is users seeing more stacktraces, or plain 
404 or 500 errors, I go -1.  
Users should see *shorter* and more meaningful stacktraces.
No, that was my point.  Developers should see shorter more meaningful 
stacktraces.  Users should never see a stack trace in my opinion.  I know this 
is a semantic difference between "users" of the cocoon framework, and users of 
the applications they build.  I thought what you are proposing is not in 
conflict with this, but I didn't have time to figure that out myself, hence my 
comment.

If the end result is developers can still "catch" errors in the 
sitemap and display custom "oops" pages instead (as currently) then I 
go to +0. 
There is no plan to remove "catch" clauses from the sitemap processor, 
so the usual  should still work as usual.
There you go.  Sorry you had to spell it out explicitly.

If, however, this means backwards incompatibility or behavior change 
with existing components (external too, not only in our cvs) then I go 
back to -1 no matter what.
Removing a checked exception from the "throws" clause of a method 
declaration is a backward-compatible change.

However, if we later on decide that this was not a good idea after all, 
readding a checked exception is backward-incompatible. This would only 
affect people who wrote code, calling this method without a try-catch 
block, in the interval between the two changes. I think that this is 
quite improbable and easily caught.

Hope this clears your doubts.
I think this is probably OK risk.  I'm on +0 now.

Geoff

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Joerg Heinicke wrote:
The compiler forces you to catch them.
Of course, but only exactly once at the end. How are the exceptions made
available to handle-errors at the moment? I guess somewhere in the tree
processor. So where is the problem letting it catch the exception? I still don't
see the need for the re-parenting.
No. Assuming there are several layers, currently the compiler forces you 
to catch the exception at every layer or declare it in the throws clause 
(which might be impossible if you're implementing an interface).

On the contrary, if PE extends RuntimeCascadingException, you have the 
freedom to catch it only in the outermost layer, that would probably be 
the sitemap processor. Or you can catch it wherever you like.

The conventional wisdom is that it's better to have the compiler remind 
you that you have to catch most exceptions, because that's part of the 
contract. My opinion, instead, is that checked exceptions are a very bad 
way of enforcing contracts between callers and callees.

The conventional wisdom is also that strong type checking helps in 
enforcing contracts. Judging from the recent flourishing of untpyed or 
weakly-typed languages like Python, Ruby, Groovy or Javascript [1], I'd 
be inclined to doubt that wisdom too.

	Ugo

[1] :

function myflow() {
  var obj = cocoon.getComponent(id);
  obj.someMethodThrowingCheckedException();
  // What? No cast? No try-catch? Where's the compiler??? ;-)
}

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:

Nicola Ken Barozzi wrote:

Ugo Cei wrote:

For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can 
count on exception chaining) I will propose to define a 
Cocoon-specific hierarchy of exceptions, whose root is 
java.lang.RuntimeException. And 3rd party exception classes like 
SAXException will have to be wrapped inside Cocoon-specific runtime 
exceptions.
Gaaak! Why so? I just don't get it, you don't like wrapping but are 
going to do it nevertheless?
 
I'm going to wrap only if I'm forced to or it adds value, i.e. 
information. 
It should usually never add information. If it has more information than 
the base, it can usually handle it completely.

Not just because I am forced by a "throws" clause in a 
method signature.
You are forced by a contract, just as you are forced by other types.

If there's no "throws", I get to decide whether to wrap or not.
Or you don't decide at all.
How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.


First of all, why are you logging? Useless.
Me? This is not code I wrote, it's in our CVS.
I know, man. What I say is that the fact that it gets logged has 
*nothing* to do with unchecked exceptions. It seems that for you one has 
unchecked exceptions or the thing that you have written above. Stop 
polluting the discussion with these things as they are not involved.

I'm not into pshychic reading, but it seems to me quite evident that 
whoever wrote that code was feeling somewhat helpless or even guilty: "I 
don't know what to do with this ProcessingException that I'm *forced* to 
catch by the compiler, so I'm going to log it to share the burden of my 
guilt". But the author should not blame himself of feel guilty. He 
should blame the fact that ProcessingException is checked.
He should blame the fact that he does not have ProcessingException in 
*it's* throws cause even if he cannot cope with it.

Do you know what this is? This is a _code_ _smell_ and I want to remove it.
I never remove code smell. If it works, don't touch it, even if it 
smells. If it doesn't work, fix it. Code beauty and lack of odor only 
creates nice empty boxes, and I know something about it unfortunately.

Obviously, you appreciate checked exceptions more than I do, and there's 
nothing wrong with that. You are in Gosling's camp, and probably the 
majority of programmers is with you. I'm not going to change your mind 
and make you switch over to Eckel's camp in the space of a maling list 
thread.

But let's be pragmatic. We have an *evident* code smell (I hope you at 
least agree with me on this point) and want to remove it. My pragmatic 
approach is: make ProcessingException extend CascadingRuntimeException, 
find all the lines of code that match this template:

  catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
  }
and simply remove them. *POOF* away goes the smell.
Yeah, great, let's just remove the code.

If you don't agree, then what is your proposal?
   catch (ProcessingException e) {

 //see if I *really* need to rethrow it

 throw new *Exception(*, e);
   }
or simply let it be rethrown if possible. I would prefer a lot to rather 
add ProcessingException to the throws cause of these components, as this 
is how it should have been done if the contract actually needs it.

PLUS

Get it right with 2.2 by defining the contract with the container, IE 
what the component.

Since you know that we have dozens of places in the code with this 
thing, do you care posting a dozen of them here?

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

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Joerg Heinicke

Ugo Cei  cbim.it> writes:

> > But the proposal cries IMHO for unforeseen
> > effects like not caught exceptions where they should have been caught.
> 
> If all you do is log (maybe) and rethrow, this is a clear indication of 
> the fact that the exception should NOT have been caught in the first place.

Agreed.

> > And for the specific case of ProcessingExceptions: Does not almost every of
> > our components have the ProcessingException in its throws clause? So where is
> > the need for catching/wrapping/rethrowing them?? Only current bad usage is
> > not a reason for changing it IMO.
> 
> The compiler forces you to catch them.

Of course, but only exactly once at the end. How are the exceptions made
available to handle-errors at the moment? I guess somewhere in the tree
processor. So where is the problem letting it catch the exception? I still don't
see the need for the re-parenting.

Joerg

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:
...
And for the specific case of ProcessingExceptions: Does not almost 
every of our
components have the ProcessingException in its throws clause? So where 
is the
need for catching/wrapping/rethrowing them?? Only current bad usage is 
not a reason for changing it IMO.
The compiler forces you to catch them.
It does because it's part of the contract. We can agree that the current 
contract is bad, but this does not mean that it must be thus completely 
removed.

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

Re: Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

Berin Loritsch wrote:
The core problem that the proposed vote was trying to solve was to 
remove the need to catch a ProcessingException if we are merely going to 
log and rethrow it.
Yes.

Does the ProcessingException allow you to store any clues as to the type 
of error handling we need (i.e. HTTP 500 error message, HTTP 404 error 
message)?  The answer is no.  It does provide some extra code to output 
a better error message though.
The answer is (theoretically) yes. The ProcessingException probably 
wraps the original exception, so you can retrieve it. However, if the PE 
is wrapped in a SAXException, which maybe is wrapped in something else, 
then it all becomes more difficult.

So what is the best approach?  If we remove the ProcessingException,
then we now have a backwards incompatible change.  The old components 
compiled against old interfaces won't load because there is no 
ProcessingException in the classpath.  That is clearly not the best 
approach.
Of course, not.

If we make ProcessingException a RuntimeException, then we 
maintain backwards compatibility, and the need to declare the exception. 
 Old precompiled code will still work, but if you recompile against the 
new interfaces with no declared ProcessingException then you will have 
an upgrade problem.
This if you remove the "throws ProcessingException" clause, but we won't 
necessarily.

a more serious issue.  You cannot go by the type of exception alone.  By 
allowing the ProcessingException to have this additional information 
embedded, the Sitemap can better handle creating more accurate error pages.
I'm confused here. Doesn't it already have it embedded?

	Ugo

DO NOT REPLY [Bug 28424] - [PATCH] Allow applications access to the start and end of a request

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://issues.apache.org/bugzilla/show_bug.cgi?id=28424

[PATCH] Allow applications access to the start and end of a request





--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 14:13 ---
I certainly don't have a problem with having multiple listeners.  With multiple
listeners it would be important to spell out what the contract is - i.e. they
should be passive and not modify anything or if they can modify the response
(not my intention of a listener but its possible) then they should be guaranteed
they are called in the order they are configured, etc.

With the current code one could implement a RequestListenerManager that
implements RequestListener. It could be configured with RequestListeners and
call them and it could specify what the contract is.

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Joerg Heinicke wrote:
Ugo Cei  cbim.it> writes:


  catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
  }


I'm not very experienced with designing Java class models and even less with
checked vs. unchecked exceptions. But the proposal cries IMHO for unforeseen
effects like not caught exceptions where they should have been caught.
If all you do is log (maybe) and rethrow, this is a clear indication of 
the fact that the exception should NOT have been caught in the first place.

And for the specific case of ProcessingExceptions: Does not almost every of our
components have the ProcessingException in its throws clause? So where is the
need for catching/wrapping/rethrowing them?? Only current bad usage is not a
reason for changing it IMO.
The compiler forces you to catch them.

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Geoff Howard wrote:
If the end-result of this is users seeing 
more stacktraces, or plain 404 or 500 errors, I go -1.  
Users should see *shorter* and more meaningful stacktraces.

If the end 
result is developers can still "catch" errors in the sitemap and display 
custom "oops" pages instead (as currently) then I go to +0. 
There is no plan to remove "catch" clauses from the sitemap processor, 
so the usual  should still work as usual.

If, 
however, this means backwards incompatibility or behavior change with 
existing components (external too, not only in our cvs) then I go back 
to -1 no matter what.
Removing a checked exception from the "throws" clause of a method 
declaration is a backward-compatible change.

However, if we later on decide that this was not a good idea after all, 
readding a checked exception is backward-incompatible. This would only 
affect people who wrote code, calling this method without a try-catch 
block, in the interval between the two changes. I think that this is 
quite improbable and easily caught.

Hope this clears your doubts.

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Le 16 avr. 04, à 15:28, Marc Portier a écrit :
...I'm not currently not convinced there could be anything else then 
careful consideration on each point in the code, sorry if this is bad 
news
I tend to agree.

I don't have time currently to seriously follow the discussion, but a 
quick random thought: would interfaces help in deciding what must be 
caught and what not?

for example:
class SitemapParsingProblemException
  extends ProcessingException
  implements XmlParsingException, SitemapSyntaxException
WDYT?

-Bertrand

Restating the Exception Problem (was Re: [VOTE] Make ProcessingException extend CascadingRuntimeException)

I am a little confused, it seemed like the direction of the discussion 
on checked vs. unchecked exceptions was leading us down the path of this 
vote.  I realize that there are valid points on both sides of the issue, 
so for my benefit and the benefit of everyone, I am going to try and 
restate the problems trying to be solved so that we at least have a 
common understanding.  (I'm not there yet so it is probably more for my 
benefit).

The core problem that the proposed vote was trying to solve was to 
remove the need to catch a ProcessingException if we are merely going to 
log and rethrow it.

The core problem that Nicola is concerned about is letting Cocoon
automatically handle the specific types of issues that it might need--in 
essence removing the need for any type of Cocoon specific exception.

The goals are the same: to make it easier to write the components and 
blocks and clean up the code.

Looking at the core components (Generator, Transformer, Serializer),
they declare a set of exception types that can be thrown:
Generator->IOException, SAXException, ProcessingException
Transformer->SAXException, IOException, ProcessingException
Serializer->IOException, ProcessingException
All of these can throw whatever exceptions are necessary.  If any 
exception is thrown, then the sitemap needs to handle it appropriately.
The next question is what is done differently in all these cases?
Does the ProcessingException allow you to store any clues as to the type 
of error handling we need (i.e. HTTP 500 error message, HTTP 404 error 
message)?  The answer is no.  It does provide some extra code to output 
a better error message though.

So what is the best approach?  If we remove the ProcessingException,
then we now have a backwards incompatible change.  The old components 
compiled against old interfaces won't load because there is no 
ProcessingException in the classpath.  That is clearly not the best 
approach.  If we make ProcessingException a RuntimeException, then we 
maintain backwards compatibility, and the need to declare the exception. 
 Old precompiled code will still work, but if you recompile against the 
new interfaces with no declared ProcessingException then you will have 
an upgrade problem.

Of course there is another solution which is to add some information to 
the ProcessingException that would give a better semantic clue to the 
Sitemap the true nature of the problem and how best to translate that 
into the error message pages.  For example, a SQLException and an 
IOException might signal that a resource is not found, or that there is 
a more serious issue.  You cannot go by the type of exception alone.  By 
allowing the ProcessingException to have this additional information 
embedded, the Sitemap can better handle creating more accurate error pages.

Of course, if we declare all these exception types in the interfaces,
we should not have to catch them in the sitemap components.  They should 
be able to be handled in other ways.

If we declare a general throws clause of any Exception type, then we can 
minimize the number of necessary catches completely.

If changing the ProcessingException to a RuntimeException will help 
initially down this road, then I am all for it.

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException



Ugo Cei wrote:

Nicola Ken Barozzi wrote:

Ugo Cei wrote:

For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can 
count on exception chaining) I will propose to define a 
Cocoon-specific hierarchy of exceptions, whose root is 
java.lang.RuntimeException. And 3rd party exception classes like 
SAXException will have to be wrapped inside Cocoon-specific runtime 
exceptions.
Gaaak! Why so? I just don't get it, you don't like wrapping but are 
going to do it nevertheless?


I'm going to wrap only if I'm forced to or it adds value, i.e. 
information. Not just because I am forced by a "throws" clause in a 
method signature.

If there's no "throws", I get to decide whether to wrap or not.

which sounds like more arbitrary decissions and thus 'surprise-code'

I will be left to wonder why you suddenly wrap it now?

and the answer will be only in the fact that somebody further up your 
call-stack has a special handling case for this?

How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.


First of all, why are you logging? Useless.


Me? This is not code I wrote, it's in our CVS.

I'm not into pshychic reading, but it seems to me quite evident that 
whoever wrote that code was feeling somewhat helpless or even guilty: "I 
don't know what to do with this ProcessingException that I'm *forced* to 
catch by the compiler, so I'm going to log it to share the burden of my 
guilt". But the author should not blame himself of feel guilty. He 
should blame the fact that ProcessingException is checked.
hm, slightly exagerated? IMHO there is an equal drive to do this logging 
coming from the fact that the class was LogEnabled :-)

Do you know what this is? This is a _code_ _smell_ and I want to remove it.

Obviously, you appreciate checked exceptions more than I do, and there's 
nothing wrong with that. You are in Gosling's camp, and probably the 
majority of programmers is with you. I'm not going to change your mind 
and make you switch over to Eckel's camp in the space of a maling list 
thread.

Ugo, I don't think this is about camps, at least not in my head, I 
really found the Eckel's view and enteresting read and a pure 
revelation: I find it to broaden my view on the issue (in general)

As I tried to mention before: general views can help us see, but we have 
to look into our project-details ourselves.

But let's be pragmatic. We have an *evident* code smell (I hope you at 
least agree with me on this point) and want to remove it. My pragmatic 
approach is: make ProcessingException extend CascadingRuntimeException, 
find all the lines of code that match this template:

  catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
  }
and simply remove them. *POOF* away goes the smell.

hehe, this makes me think about a humor-radio-program we had years ago 
on belgian radio, people were asked to invent a perfect 'perfume'

turns out that was shaped like: [two plugs you put into your own nose]

removing the smell is admirable, making it smell good is better

If you don't agree, then what is your proposal?

sigh, making it smell good is hard work, that's what I hinted at when 
saying there is no easy answer...

I'm not currently not convinced there could be anything else then 
careful consideration on each point in the code, sorry if this is bad news.

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Joerg Heinicke

Ugo Cei  cbim.it> writes:

>catch (ProcessingException e) {
>  getLogger().*(*);
>  throw new *Exception(*, e);
>}

I'm not very experienced with designing Java class models and even less with
checked vs. unchecked exceptions. But the proposal cries IMHO for unforeseen
effects like not caught exceptions where they should have been caught.

And for the specific case of ProcessingExceptions: Does not almost every of our
components have the ProcessingException in its throws clause? So where is the
need for catching/wrapping/rethrowing them?? Only current bad usage is not a
reason for changing it IMO.

Joerg

RE: [VOTE] Make ProcessingException extend CascadingRuntimeException

I'm not a committer, but +1 from me.

The ProcessingException isn't supposed to be caught by the immediate 
client, but propagated all the way up the stack. It therefore seems
unneccessary to burden the intermediate layers with having to declare
"throws ProcessingException".

/LS

> From: Unico Hommes [mailto:[EMAIL PROTECTED]

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Geoff Howard

Ugo Cei wrote:

I think everyone interested has had the option of venting his opinion on 
the subject of checked vs. unchecked exceptions. For the record, here 
[1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. Tests 
fail, but they failed also before the change :-(.

So, please cast your votes.

Ugo

[1] http://marc.theaimsgroup.com/?t=10818860842&r=1&w=2
I have next to no time to follow the discussion, or comment fully, but I lean to 
 -.5 because I have a feeling that the thought process is too geared to how 
developers want to see errors, not how developers should want users to see 
errors.  If the end-result of this is users seeing more stacktraces, or plain 
404 or 500 errors, I go -1.  If the end result is developers can still "catch" 
errors in the sitemap and display custom "oops" pages instead (as currently) 
then I go to +0.  If, however, this means backwards incompatibility or behavior 
change with existing components (external too, not only in our cvs) then I go 
back to -1 no matter what.

Geoff

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Stephan Michels

Am Fr, den 16.04.2004 schrieb Ugo Cei um 0:02:
> In order to move forward, I propose to reparent the 
> org.apache.cocoon.ProcessingException to extend 
> org.apache.avalon.framework.CascadingRuntimeException instead of 
> CascadingException.

> So, please cast your votes.

+1

Stephan.

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

2004-04-16 Thread Unico Hommes

Nicola Ken Barozzi wrote:

Ugo Cei wrote:

Nicola Ken Barozzi wrote:

In any case (and note that this is a vote, not a veto) the main 
reason is that in doing this we risk to throw out the baby with the 
water: I prefer a lot to remove ProcessingExceptions comptely and 
have the Cocoon components throw all the exceptions that the 
container can and will handle. IOW, I don't want to have an implicit 
contract but a more detailed and explicit one. In any case, generic 
ProcessingExceptions are evil, and this is a fact that we have known 
for a long time.


We have something worse than generic ProcessingExceptions being 
thrown, we have components throwing CascadingException. Which not 
only force clients to check them, but create an unnecessary 
dependence on Avalon.


Whaich I agree with, but still it's not about checked VS unchecked.

And I'm not going to throw out any baby. I'm going to throw out lots 
of totally useless "catch" clauses that do nothing but litter the code.


You don't need to use unchecked exceptions to do that. I don't see the 
connection.

The connection is fairly obvious to me. If you want to throw out the 
useless catch clauses (which really are useless, I don't think you are 
challenging that?) then there are two options. Either declare all 
possible exception types in the method declaration (which in practice 
means declaring throws Exception in the interface) or convert checked 
exceptions to unchecked ones. Since the semantic value of the former is 
nearly nil I personally see that option not adding a lot of value, just 
more clog.

+1 for Ugo's proposal from me.

--
Unico

Re: Documentation TOC started

Le 16 avr. 04, à 14:40, [EMAIL PROTECTED] a écrit :

...Ultimately you're right and the ToC should be generated, but for 
now I want
to use it as an inventory for what's available, what's missing and in 
short:
how much work is ahead. :-)
Fine, thanks for the clarification!
-Bertrand

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:

I think everyone interested has had the option of venting his opinion on 
the subject of checked vs. unchecked exceptions. For the record, here 
[1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. Tests 
fail, but they failed also before the change :-(.

So, please cast your votes.
+1 from me.

Re: [cforms] fixed early field validation. But when should it occur?



Sylvain Wallez wrote:

Hi all,

Trying to catch up some late reading (yep, nearly one week!), I found 
some questions related to early validation of widget values. Firstly, I 
I explicitely let this message wait until I had some time and focus to 
get into it, too bad it took much more time to organize that then I 
expected myself, sorry for that

fixed the problem (introduced just before 2.1.4 was released): 
validation occured at each and every readFromRequest(), which was 
obviously not the expected behaviour! From now on, we're back to 
validation being done only when validate() is called, and also on 
getValue().

I'm the one who introduced this validation on getValue(), but maybe not 
the way it should be. So let me explain where it came from and let's 
discuss it.

Type safety is an important feature of CForms: the application doesn't 
have to deal with strings sent in the request, but only with object 
types such as date and integers.

yep

Now what about "value safety"? When writing some application code that 
relies on the form values (event listeners, binding, etc), widgets 
should return only correct values, i.e. values that are not only 
syntactically correct (according to the converter), but also 
semantically correct (according to the validators). Or else, we have the 
risk for the application to fail badly simply because it used incorrect 
values.

yep, I even think the same holds for the aspect of event-handling: the 
programmatically set value could possibly be triggering widget-effects 
local to the form

Now how do we solve this? A solution is that widget.getValue() not only 
does the parsing, but also the validation, and therefore returns a 
non-null value if and only if the input value is successfully parsed and 
validated.

above assumes that returning 'null' yields a valid state, no?

failing as fast as possible I would suggest there is a setValue version 
that tells the binding something's rotten, this would allow the binding 
to handle it

This is what is done in Field, with the side effect that calling 
getValue() may set a validation error on the widget even if validate() 
wasn't explicitely called. This side effect is interesting: for example, 
if an event listener couldn't do its job because of a wrong input, the 
offending input is automatically shown to the user. This is examplified 
in the "number fields" section in the "flow1.form" sample.

yep, good example

Now this behaviour can also lead to premature flagging of widgets that 
may not be wanted. An example of this is in the carselector sample (see 
event listeners in the form definition) where we must reset the "make" 
widget value to null because a "getValue" can set a validation error if 
the user chose the null value.

So, although validation _must_ occur when getValue() is called, we may 
I'm still doubthing... I'm tending towards a view where the value wasn't 
_set_ until validation happened.

maybe a split between the 'unvalidatedValue' and the 'value' (much like 
between enteredValue and value today) offers us a better base to react 
on all requirements (don't see yet how... I'm still trying to understand)

want getValidationError() to return null until validate() has actually 
been called.

So the two possible behaviours are:
- as of today (with the fix), have validation errors as the side effect 
of getting the value.
which sounds odd from a distance?

- raise the validation error only if validate() was called, even if 
getValue() does the actual call to the validators.

to me it's still a surprise that getValue does that

That second solution will require event-listeners to manually call 
validate() if ever they want to show errors on the widgets they act upon 
to the user.

as would be the case for the binding?

we seem to state that value-setting should be distinct from triggering 
validation-error-raising, but it seems odd that the end-user of the 
interface should (even could) decide for this explicitely?

wild thought: maybe there should be a specific accessor object passed 
rather then the widget itself

What do you think?

not sure yet, I'm currently trying to get all angles of the issue in one 
view, lacking that here and now deprives me from the comfortable feeling 
that would allow me to make any statements

I see more and more how our widgets are often 'pretending' to be in a 
different state then they declare through the getting of their 
properties, resulting in different semantics behind the same properties 
depending on who's asking at what time.  I any specific case it's often 
quite visible why this is, it just doesn't help clarity in general

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

RE: Documentation TOC started

2004-04-16 Thread H . vanderLinden

Hi,

> I dont' want to stop or slow down your most welcome 
> initiative, but how 
> about *generating* the TOC from metadata (that would need to be added 
> to the docs, see [1]), instead of having a static TOC?

Ultimately you're right and the ToC should be generated, but for now I want
to use it as an inventory for what's available, what's missing and in short:
how much work is ahead. :-)

Bye, Helma

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Marc Portier wrote:
What I'm buying here is clarity at the price of verbosity. A good deal 
over reduced kLOCs at the price of obscurity...
IMHO: there are tools that help out with verbosity, for obscurity you're 
on your own :-(
This is fine, in theory. In practice, our codebase is full of rethrows 
that add nothing to clarity.

-marc= (doubthing there is an easy answer to this)
If there were, we'd all be programming in Eiffel ;-).

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Nicola Ken Barozzi wrote:
Ugo Cei wrote:
For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can 
count on exception chaining) I will propose to define a 
Cocoon-specific hierarchy of exceptions, whose root is 
java.lang.RuntimeException. And 3rd party exception classes like 
SAXException will have to be wrapped inside Cocoon-specific runtime 
exceptions.
Gaaak! Why so? I just don't get it, you don't like wrapping but are 
going to do it nevertheless?
I'm going to wrap only if I'm forced to or it adds value, i.e. 
information. Not just because I am forced by a "throws" clause in a 
method signature.

If there's no "throws", I get to decide whether to wrap or not.

How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.
First of all, why are you logging? Useless.
Me? This is not code I wrote, it's in our CVS.

I'm not into pshychic reading, but it seems to me quite evident that 
whoever wrote that code was feeling somewhat helpless or even guilty: "I 
don't know what to do with this ProcessingException that I'm *forced* to 
catch by the compiler, so I'm going to log it to share the burden of my 
guilt". But the author should not blame himself of feel guilty. He 
should blame the fact that ProcessingException is checked.

Do you know what this is? This is a _code_ _smell_ and I want to remove it.

Obviously, you appreciate checked exceptions more than I do, and there's 
nothing wrong with that. You are in Gosling's camp, and probably the 
majority of programmers is with you. I'm not going to change your mind 
and make you switch over to Eckel's camp in the space of a maling list 
thread.

But let's be pragmatic. We have an *evident* code smell (I hope you at 
least agree with me on this point) and want to remove it. My pragmatic 
approach is: make ProcessingException extend CascadingRuntimeException, 
find all the lines of code that match this template:

  catch (ProcessingException e) {
getLogger().*(*);
throw new *Exception(*, e);
  }
and simply remove them. *POOF* away goes the smell.

If you don't agree, then what is your proposal?

	Ugo

RE: CocoonComponentManager



> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
> 
> Now, I personally think, if we change this, we should first 
> use the improved code from the 2.2 base as it has less static 
> methods and is in some respects cleaner and then see what we 
> can do with the remaining stuff. But that's just my opinion.

The 2.2 branch will probably be very different from the existing
code, with blocks etc., so perhaps this will be a non-issue
by then.

/LS

Re: Documentation TOC started

Le 16 avr. 04, à 13:11, [EMAIL PROTECTED] a écrit :
...Yes I noticed on the wiki, my idea exactly to merge them, although 
my plans
with the ToC are more "grand". As explained in another message, my 
goal is
to get to an ebook kind of documentation
I dont' want to stop or slow down your most welcome initiative, but how 
about *generating* the TOC from metadata (that would need to be added 
to the docs, see [1]), instead of having a static TOC?

-Bertrand

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108057364416305&w=2

RE: Documentation TOC started

2004-04-16 Thread H . vanderLinden

Hi Bertrand,

> Sorry about that. I guess some of us are in a more or less burnout 
> state about the docs (I am).

Hmm, it's more difficult to write good documentation than write good code.

> There have been many discussions about how to improve the docs, many 
> real good ideas flying around (moving everything to the wiki, 
> generating reference docs from code, generating table of 
> contents from 
> keywords in docs, etc), but until now not much has been done in terms 
> of restructuring / making the docs more accessible. Many talks, not 
> much action (I'm as guilty as anyone, not pointing fingers).

Well, in my opinion a ToC is about the only thing that can be "generated"
when talking about documentation. All the rest is more craftmanship from a
writers POV than from a developers POV.

Sure, javadoc in the code surely helps, but it's often too limited.

> So yes, your TOC initiative is very welcome!

Thanks.

> A while ago I started writing "documentation tracks" [1]. Would a 
> merging of the two concepts (your TOC and these tracks) be useful? I 
> think it's about the same idea: provide a roadmap into the docs.

Yes I noticed on the wiki, my idea exactly to merge them, although my plans
with the ToC are more "grand". As explained in another message, my goal is
to get to an ebook kind of documentation.
At first, I'll include the pages in the ToC (or you can do that yourself if
you feel like), in later steps I suppose we have to integrate them into the
documentation. The idea is great though.

Bye, Helma

RE: CocoonComponentManager

Leo Sutic wrote:
> 
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> >
> > This would give everyone access to the info (ok, the current static 
> > methods are accessible as well) and imho makes it more visible.
> 
> I think it'd make it less visible. For example, you can pass 
> the CocoonContext only to specific components, while the 
> statics are available everywhere.
> 
> > Just curious, why do want to do this? Do you just want to use the 
> > TreeProcessor as a processor for a custom XML? Or are you using the 
> > TreeProcessor to process a sitemap in a different 
> environment? Now, I 
> > think, if the TreeProcessor is used for custom XML, then 
> you could use 
> > the TreeBuilder I think (I'm not that sure). If you want to 
> process a 
> > sitemap, you need the dependency to the cocoon stuff anyway.
> 
> I will process a reduced sitemap. Just generators, actions, 
> transformers and serializers. Nothing more. In theory I could 
> define my own pipeline language, write my own components, and 
> so on, but I figured I'd try to re-use as much of Cocoon as possible. 
> 
> Specifically, I will not be using flow, continuations or subsitemaps.
> 
Thanks for the info. Hmm, there are several places - not just the
TreeProcessor - that use these static methods, so this would require
more changes then just these two places. On the other hand I see
your need. 
Now, I personally think, if we change this, we should first use the
improved code from the 2.2 base as it has less static methods and
is in some respects cleaner and then see what we can do with the
remaining stuff. But that's just my opinion.

Carsten

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:

Marc Portier wrote:

Ugo Cei wrote:

How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.

why so?

because SAXExceptions must be related to XML and it might be that this 
ProcessingException was related to e.g. sql operations?  And this 
breaks with the 'IS A' test?

I'm not sure: I think this depends on your understanding of what is 
the meaning of a SAXException.  Its purpose of existence is not to 
communicate XML related errors, its purpose is to communicate to XML 
processing components that they should stop doing so since 
wellformedness of the communicated data (somewhere along the pipe) is 
not ensured?

I might agree with this. But if I were to agree completely, I would make 
SAXException unchecked, since, if XML processing components should stop 
processing, they might as well be interrupted by a runtime exception. 
How are they expected to recover from a malformed SAX stream?

oh, did I say they should stop?

I agree that the recovery component that would try to re-ensure XML 
welformdness is highly hypothetical to the level of plain useless

but in more general terms: recovering from malformed sax stream could be 
really easy: I'm reading in a configuration file through sax, if that is 
bogus I switch to defaults... (I surely don't need to break completely, 
and I'm quite glad the system reminded me of the fact that when dealing 
with XML this issue is not to be totally overlooked)

Well, in some cases you could, if you *really* must, but in practice 
very few components would need to. But now they are forced to deal with 
it by logging, wrapping and rethrowing.

but who are we to measure this awkwardness in our project in relation to 
all other uses of SAX out there?

But suppose we aren't given the luxury of catching a ProcessingException 
that we can ignore if we make it unchecked. Suppose we have to catch an 
SQLException, which we cannot change. Then, that's what I would do (if I 
 were to agree with your reasoning above):

  catch (SQLException sqle) {
throw new org.apache.cocoon.RuntimeSAXException
("While doing this and that:", sqle);
  }
But since I'm not sure I completely agree with that reasoning, more 
probably I would do:

  catch (SQLException sqle) {
throw new org.apache.cocoon.DataAccessException
("While doing this and that:", sqle);
  }
which fails to indicate that most likely the XML processing should be 
stopped

I agree to do it like this if the above most likely does not stand, in 
all other cases this will ensure a higher coupling up the call stack:

since someone up there will need to (and out of the blue) couple the 
occurance of a DataAccessException to notyfing the SAX aware components

The DataAccessException (unchecked) would have enough knowledge of 
SQLException to extract meaningful information from it, like SQL error 
codes and maybe even proprietary error codes (think Oracle, for 
instance). It would also have knowledge of other methods for accessing 
databases: JDO, Hibernate, etc. Thus, if you wanted to deal with data 
access exceptions in a persistence-layer-independent way, you could do:

   catch (DataAccessException dae) {
   // Extract enough information, if available, and see if we
   // can recover or not.
   }
agree, but higher up the chain is someone that doesn't know there are 
databases involved, and doesn't want to: the only thing he knows is 
SAXevents (and SAXexceptions) (he's not going to elegantly handle 
database related things)

so why would that class ever provide this catch?

and if he catches RuntimeException instead, then what is the semantical 
meaning of that?

and if he doesn't: how to just continue with the default config?

would this be your alternative then:
have a SAXWrappingProcessingException subclass that can only wrap a 
SAXException that should be plainly unwrapped and rethrown in the case 
that the context allows for it?

   } catch (SAXWrappingProcessingException e) {
 throw e.getWrappedSAXException();
   }
   // not catching the ProsessingException will just let it propagate
 >
 > -marc= (still enthousiastically trying to be enthousiast)
My alternative in this particulare instance is just to delete the three 
lines of code above. Aren't you enthusiastic about the prospect of 
removing unnecessary code? I usually am ;-).

hehe, me too, but I still fail to attach the label 'unnecessary'

specially if the price we pay is the introduction of higher-surprise 
occurance of other code (i.e. when the DataAccessException occurs in a 
spot that doesn't know about databases, but needs this clause to signal 
the XML aware components so they can safely recover...)

What I'm buying here is clarity at the price of verbosity. A good deal 
over reduced kLOCs at the price of obscurity...
IMHO: there are tools that help out with verbosity, for obscurity you're

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:
Nicola Ken Barozzi wrote:

Ugo Cei wrote:

We have something worse than generic ProcessingExceptions being 
thrown, we have components throwing CascadingException. Which not 
only force clients to check them, but create an unnecessary 
dependence on Avalon.
Whaich I agree with, but still it's not about checked VS unchecked.
It's a different issue, yes. I mentioned it just because I noticed that 
it should be fixed while reparenting ProcessingException.

It would be better if CascadingException were abstract, and 
ProcessingException too, so that throwers would be forced to reuse or 
define a more specific exception class, instead of being lazy.

For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can count 
on exception chaining) I will propose to define a Cocoon-specific 
hierarchy of exceptions, whose root is java.lang.RuntimeException. And 
3rd party exception classes like SAXException will have to be wrapped 
inside Cocoon-specific runtime exceptions.
Gaaak! Why so? I just don't get it, you don't like wrapping but are 
going to do it nevertheless?

This is the approach taken by Spring, and I know that many of you don't 
like it, but ideas change with time, and we will have plenty of time to 
discuss and change the minds of people. Even mine, maybe ;-).

And I'm not going to throw out any baby. I'm going to throw out lots 
of totally useless "catch" clauses that do nothing but litter the code.
You don't need to use unchecked exceptions to do that. I don't see the 
connection.
How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.
First of all, why are you logging? Useless.
Second, why are you rethrowing the exception? There is a meaning to it.
   try{
here the IO makes an error;
   } catch (ProcessingException e) {
 //a ProcessingException  occurred.
 //what can I do about it? should I retry?
 //I was not able to process something, but
 //now I have to honor my contract.
 //Can I end the xml? Yes... so let's do it:
 end.the.xml();

 //I'm not throwing, as for SAX I'm ok, the SAX stream is ok
 //throw new SAXException(e);
   }
IOW, the fact that there is an exception mismatch between what I catch 
and what I throw should make me think about what impact the caught 
exception has on me and on the possibility or not of finishing the work. 
If I cannot finish what I can do - and note that the exceptions I throw 
define what my parent can or cannot fix - shall I eventually tell my parent.

If you use Runtime exceptions all this goes away and instead of 
rethrowing you will see exceptions being gobbled up.

Not only we will have the opposite problem, ie not catching instead of 
rethrowing everything, but we will be unable to go through the code 
searching for rethrowing and asking ourselves if it's correct or not.

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

RE: CocoonComponentManager



> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
>
> This would give everyone access to the info (ok, the current 
> static methods are accessible as well) and imho makes it more 
> visible.

I think it'd make it less visible. For example, you can pass the
CocoonContext only to specific components, while the statics
are available everywhere.

> Just curious, why do want to do this? Do you just want to use 
> the TreeProcessor as a processor for a custom XML? Or are you 
> using the TreeProcessor to process a sitemap in a different 
> environment? Now, I think, if the TreeProcessor is used for 
> custom XML, then you could use the TreeBuilder I think (I'm 
> not that sure). If you want to process a sitemap, you need 
> the dependency to the cocoon stuff anyway.

I will process a reduced sitemap. Just generators, actions,
transformers and serializers. Nothing more. In theory I
could define my own pipeline language, write my own components,
and so on, but I figured I'd try to re-use as much of Cocoon
as possible. 

Specifically, I will not be using flow, continuations or 
subsitemaps.

/LS

RE: CocoonComponentManager

Leo Sutic wrote:
> 
> I've recently started thinking about embedding Cocoon in 
> another application.
> 
> One of the issues that I have is the CocoonComponentManager - 
> since I use another component manager in the application, I'd 
> like to just host the TreeProcessor in that manager.
> 
> The issue I have is that CocoonComponentManager exposes a 
> number of static methods that makes it imposible to replace. I.e.
> you have components (TreeProcessor) that really do care about 
> what container they are in.
> 
> I can't subclass the CocoonComponentManager, since 
> TreeProcessor refers to the class by name.
> 
> But what I could do is this (and this is what I propose to do):
> 
> Move the static methods out from CocoonComponentManager and
> put them in the Context.
> 
> The CocoonComponentManager could then expose those methods 
> via a custom InternalCocoonContext interface that extends the 
> Context interface.
> 
This would give everyone access to the info (ok, the current static
methods are accessible as well) and imho makes it more visible.
For 2.2 I rewrote the whole handling and moved all methods out
of the manager into a separate class (the methods are still static)
and we don't need an own component manager anymore.

Just curious, why do want to do this? Do you just want to use the
TreeProcessor as a processor for a custom XML? Or are you
using the TreeProcessor to process a sitemap in a different
environment?
Now, I think, if the TreeProcessor is used for custom XML, then
you could use the TreeBuilder I think (I'm not that sure).
If you want to process a sitemap, you need the dependency to
the cocoon stuff anyway.

Carsten

Re: [RT] Future of the Slide Source

2004-04-16 Thread Gianugo Rabellino

Stefano Mazzocchi wrote:

I believe that sources have strongly polluted the design of the cocoon
sitemap by making generators obsolete

I even heard people mentioning things like a xquery: source where you
would encode the xquery in your URI. This has to end.

Sources *are* useful, don't get me wrong, but they are easy to abuse
because they represent higher abstractions and like pretty murmaids
seduce you with their portability and reusability.

They good sources are the one that you can think about putting in your
browser address textbox: file: http: https: ftp: cocoon: everytime there
is a src="" attribute you need to get the source. it's a transport
mechanism, it indicates *how* you get those bits to you... it should not
be doing anything more than this.

The SourceRepository that Gianugo wrote shows pretty evidently how you
can abuse this to a point where it doesn't even make sense anymore and
it's totally useless.
Oh well, thanks so much... :-)

I must confess I'm not with you this time. I'm convinced that sources
are one of the strongest features of Cocoon, and I don't quite give a
damn about them having obsoleted a few generators (not _all_ of them
though: the idea is virtualizing a transport - only generators that need
to do more than just bytestream->SAX conversion have been obsoleted.
Keep in mind that sources are a transport virtualization *AND* an API
(and a good one IMO, where composition shows its power and flexibility).

the repository *is* the place where you save, it shouldn't be *you* to
specify where and how to save it.

This is what Gianugo did with the SourceRepository and I *do* think it's
terrible design. [no offense, of course, I appreciate the attempts,
especially when they teach you where not to go]
No offense taken, exp. since you're the one to blame as well. :-) The
SourceRepository was more or less a find&replace exercise over your
original one which has exactly the same problem, only limited to a local
file (you pass it an absolute path anyways, what changes in the
SourceRepository is that you're passing a ModifiableSource altogether,
which, agreed, is bad). What changes between the two is just

var home = "/some/path"

var home = "proto://host/some/path"

no big deal. :-)

I found the partition of work - reading operations via Sources (which
BTW is their original intention) and modifying operation via
Repository - quite useful.

I doesn't think that we should delegate similar aspects into different
code parts.

Agreed. We need a repository API and a generator that uses that API to
connect to the repository and streams SAX events out of it.
I still don't see what is your problem with Sources. I can foresee some
security issues since there might be an unexpected direct access instead
than going just through the APIs, but this is something that might
happen anyways and you protect yourself in other ways.

And, speaking about disagreement between me and you, I really have a
problem with your plan:

I think that flow changed the picture so much that we now have to rethink where those sitemap artifacts really still make sense or not.

And I mean:

1) actions (I guess everybody agrees on this now)
2) sources (getting there)
3) input/output modules (next target)
I have the impression that this agenda is going to break the most
fundamental design of Cocoon: everything moved to flow breaks horribly
the pyramid of contracts, impairs sitemap readability and overall makes
maintaining complex applications a nightmare. The beauty of Cocoon is
having everything under control in one file (or a set of files with a
coherent layout/syntax) geared to non-necessarily overtechies. Everytime
you move non-pure-controller functionality to flow, a black hole opens
in your sitemap, and you're not under control anymore.

I noticed this in our last large projects and, well, you have to see to
believe. It's incredibly easy to build tangled webs of pipelines calling
flows calling pipelines calling flows, where sorting out what happens to
a given request is a job for a very skilled developers who have to sort
out what happens in a programming language with a procedural approach.

While I'm with you with actions (pure controller logic), I really have a
problem with input/output modules disappearing and with sources being
under trial. Whatever moves outside of the sitemap not pure controller
logic is dead wrong, IMO.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)

CocoonComponentManager

I've recently started thinking about embedding Cocoon 
in another application.

One of the issues that I have is the CocoonComponentManager - 
since I use another component manager in the application, I'd
like to just host the TreeProcessor in that manager.

The issue I have is that CocoonComponentManager exposes a number
of static methods that makes it imposible to replace. I.e.
you have components (TreeProcessor) that really do care about what
container they are in.

I can't subclass the CocoonComponentManager, since TreeProcessor
refers to the class by name.

But what I could do is this (and this is what I propose to do):

Move the static methods out from CocoonComponentManager and
put them in the Context.

The CocoonComponentManager could then expose those methods via
a custom InternalCocoonContext interface that extends the
Context interface.

This would remove all static methods, and I'd be able to host
a TreeProcessor in many other containers.

/LS

Re: AW: Custom generators and configuration parameters

2004-04-16 Thread Tuomo L

Thanks a lot! I'll give it a try.

-Tuomo

On Fri, 16 Apr 2004, Marco Rolappe wrote:

> hi tuomo,
>
> implement avalon's Configurable interface. you'll then be provided with a
> Configuration object.
>
> in your example you'd get some-parameter's value like this:
>
> ...
>   someParam = config.getChild("some-parameter").getValue();
> ...
>
>
> > -Ursprungliche Nachricht-
> > Von: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Auftrag
> > von Tuomo L
> > Gesendet: Freitag, 16. April 2004 11:49
> > An: [EMAIL PROTECTED]
> > Betreff: Custom generators and configuration parameters
> >
> >
> > Hi all,
> >
> > Is it possible to provide configuration parameters in sitemap for
> > generators? Like this:
> >
> > 
> >   foobar
> > 
> >
> > This is possible for at least transformers and actions.
> >
> > If so, how do I read those parameters in the code?
> >
> > -Tuomo
> >
>
>

AW: Custom generators and configuration parameters

2004-04-16 Thread Marco Rolappe

hi tuomo,

implement avalon's Configurable interface. you'll then be provided with a
Configuration object.

in your example you'd get some-parameter's value like this:

...
someParam = config.getChild("some-parameter").getValue();
...


> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Auftrag
> von Tuomo L
> Gesendet: Freitag, 16. April 2004 11:49
> An: [EMAIL PROTECTED]
> Betreff: Custom generators and configuration parameters
>
>
> Hi all,
>
> Is it possible to provide configuration parameters in sitemap for
> generators? Like this:
>
> 
>   foobar
> 
>
> This is possible for at least transformers and actions.
>
> If so, how do I read those parameters in the code?
>
> -Tuomo
>

Re: Documentation TOC started

Hi Helma,

...AHA. That explains the "complete radio silence" when it comes to 
updating
the documentation. :-) ...
Sorry about that. I guess some of us are in a more or less burnout 
state about the docs (I am).

There have been many discussions about how to improve the docs, many 
real good ideas flying around (moving everything to the wiki, 
generating reference docs from code, generating table of contents from 
keywords in docs, etc), but until now not much has been done in terms 
of restructuring / making the docs more accessible. Many talks, not 
much action (I'm as guilty as anyone, not pointing fingers).

So yes, your TOC initiative is very welcome!

A while ago I started writing "documentation tracks" [1]. Would a 
merging of the two concepts (your TOC and these tracks) be useful? I 
think it's about the same idea: provide a roadmap into the docs.

-Bertrand

[1] http://cocoon.apache.org/2.1/tracks/index.html

Custom generators and configuration parameters

2004-04-16 Thread Tuomo L

Hi all,

Is it possible to provide configuration parameters in sitemap for
generators? Like this:


  foobar


This is possible for at least transformers and actions.

If so, how do I read those parameters in the code?

-Tuomo

Re: Java Continuation problem

2004-04-16 Thread Stephan Michels

Am Mi, den 14.04.2004 schrieb Peter Mortier um 17:19:
> Hello,
> 
> I'm trying out the new Java continuations stuff seperately from Cocoon.
> However, I have run into a problem. The instrumented bytecode throws a 
> ClassCastException In the case where I am trying to resume a Continuation 
> from a Continuable which delegates to another Continuable.

I added your test files to the CVS to indentify your problem. The
problem, which do you have, is that the Continuation stores one more
object to the continuation than needed. This object is the origin of
the call graph.

I know that the implementation should hide such details. Christopher
Oliver already made some suggestions. Until that you can easly pop this
reference by

if (continuation.isCapturing())
continuation.getStack().popReference();

after the method call.

RE: Documentation TOC started

2004-04-16 Thread H . vanderLinden

Hi David,

> > section. My ultimate goal is an ebook kind of documentation.
> 
> Great idea. This is then orthogonal to the total 
> restructuring of the xdocs, which was shelved until 2.2 
> because it would otherwise break our URL space.

AHA. That explains the "complete radio silence" when it comes to updating
the documentation. :-)

> I would certainly like to see this ToC cater for the 
> anticipated "Reference documentation" (cannot find old dev@ 
> or old docs@ discussion yet).

What exactly do you mean by "reference documentation"? To me it's a mixture
of JavaDocs + extra explanation + textual examples and maybe even a live
working example in the "samples" section.

> > Part of the documentation in my view is also a section on 
> "Cocoon info 
> > in the rest of the world", although this might very well be a wiki 
> > page.
> 
> Well i think that we should start that now, then keep
> this page clean.

Ok.

> One thing that we had discussed about Cocoon core xdocs 
> documentation was that it should not appear to sanctify any 
> external documentation, because there is some stuff out there 
> that we may not be happy with and where do we draw the line. 

Hmm, maybe it's simply my understanding of English, but I don't really
understand what you mean here. Do you mean that "no" external reference
should be included or "all"?

I was thinking along this line:
- references to external URLs that explain "add-ins" for Cocoon, e.g. the
flowscript debugger, the Sunbow plugins for Eclipse etc.
- references to blog entries which explain some otherwise hard to find info.
- references to mail archives.
- references to articles on Cocoon (e.g. the TSS article lately)
- anything else I've forgotten

The latter 2 are stuff for the Wiki page.
For the first 3 I'm thinking of getting in touch with the original authors
and ask permission to include/rewrite the information and include it in the
Cocoon xdoc itself. When components are involved, links are included to the
authors pages for more info and downloads.
This would be my option, because I've experienced myself numerous times
where I "searched myself colorblind" to find information on a certain topic,
only to stumble across it in a totally unrelated description or after much
mailing back and forth on the mailing list.
For me a good product has 2 main aspects: 1. It works more or less out of
the box and works as expected, 2. If not, there is a good manual where I can
look (most) things up. From my POV Cocoon has (1), but lacks (2) in the sens
that the information is probably "somewhere", but it cannot be found easily.

> Also we do not want to get into URL management and dead 
> links. So yes, a separate Wiki page sounds better.

My idea.

> There is one aspect that i am still not clear about. Do you 
> envisage that this ToC itself would become an xdoc? I hope 

Yes. Every book needs a ToC, an ebook even more so. In fact, it would also
need an index. (sigh, even more work :-) ).

> so. If so, then that is why i would like it to be free from 
> references to external cocoon-related stuff.

Ok, I'll start a new Wiki page.

Bye, Helma

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Marc Portier wrote:
Ugo Cei wrote:

How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.
why so?

because SAXExceptions must be related to XML and it might be that this 
ProcessingException was related to e.g. sql operations?  And this breaks 
with the 'IS A' test?

I'm not sure: I think this depends on your understanding of what is the 
meaning of a SAXException.  Its purpose of existence is not to 
communicate XML related errors, its purpose is to communicate to XML 
processing components that they should stop doing so since 
wellformedness of the communicated data (somewhere along the pipe) is 
not ensured?
I might agree with this. But if I were to agree completely, I would make 
SAXException unchecked, since, if XML processing components should stop 
processing, they might as well be interrupted by a runtime exception. 
How are they expected to recover from a malformed SAX stream?

Well, in some cases you could, if you *really* must, but in practice 
very few components would need to. But now they are forced to deal with 
it by logging, wrapping and rethrowing.

But suppose we aren't given the luxury of catching a ProcessingException 
that we can ignore if we make it unchecked. Suppose we have to catch an 
SQLException, which we cannot change. Then, that's what I would do (if I 
 were to agree with your reasoning above):

  catch (SQLException sqle) {
throw new org.apache.cocoon.RuntimeSAXException
("While doing this and that:", sqle);
  }
But since I'm not sure I completely agree with that reasoning, more 
probably I would do:

  catch (SQLException sqle) {
throw new org.apache.cocoon.DataAccessException
("While doing this and that:", sqle);
  }
The DataAccessException (unchecked) would have enough knowledge of 
SQLException to extract meaningful information from it, like SQL error 
codes and maybe even proprietary error codes (think Oracle, for 
instance). It would also have knowledge of other methods for accessing 
databases: JDO, Hibernate, etc. Thus, if you wanted to deal with data 
access exceptions in a persistence-layer-independent way, you could do:

   catch (DataAccessException dae) {
   // Extract enough information, if available, and see if we
   // can recover or not.
   }
would this be your alternative then:
have a SAXWrappingProcessingException subclass that can only wrap a 
SAXException that should be plainly unwrapped and rethrown in the case 
that the context allows for it?

   } catch (SAXWrappingProcessingException e) {
 throw e.getWrappedSAXException();
   }
   // not catching the ProsessingException will just let it propagate
>
> -marc= (still enthousiastically trying to be enthousiast)
My alternative in this particulare instance is just to delete the three 
lines of code above. Aren't you enthusiastic about the prospect of 
removing unnecessary code? I usually am ;-).

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException



Ugo Cei wrote:


How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.

why so?

because SAXExceptions must be related to XML and it might be that this 
ProcessingException was related to e.g. sql operations?  And this breaks 
with the 'IS A' test?

I'm not sure: I think this depends on your understanding of what is the 
meaning of a SAXException.  Its purpose of existence is not to 
communicate XML related errors, its purpose is to communicate to XML 
processing components that they should stop doing so since 
wellformedness of the communicated data (somewhere along the pipe) is 
not ensured?

would this be your alternative then:
have a SAXWrappingProcessingException subclass that can only wrap a 
SAXException that should be plainly unwrapped and rethrown in the case 
that the context allows for it?

   } catch (SAXWrappingProcessingException e) {
 throw e.getWrappedSAXException();
   }
   // not catching the ProsessingException will just let it propagate
-marc= (still enthousiastically trying to be enthousiast)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: GroovyMarkup syntax works!

Le 16 avr. 04, à 03:41, Antonio Gallardo a écrit :
...Yes. I agreed, but there are still some issues to solve first in 
this
parentesis oriented grammar. For example, try to write something like:

Hello, bold text 

and you will see the true
You're right, the current state about mixed markup is unclear to me as 
well. I've asked  on the groovy list, stay tuned...

-Bertrand

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Nicola Ken Barozzi wrote:
Ugo Cei wrote:
We have something worse than generic ProcessingExceptions being 
thrown, we have components throwing CascadingException. Which not only 
force clients to check them, but create an unnecessary dependence on 
Avalon.
Whaich I agree with, but still it's not about checked VS unchecked.
It's a different issue, yes. I mentioned it just because I noticed that 
it should be fixed while reparenting ProcessingException.

It would be better if CascadingException were abstract, and 
ProcessingException too, so that throwers would be forced to reuse or 
define a more specific exception class, instead of being lazy.

For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can count 
on exception chaining) I will propose to define a Cocoon-specific 
hierarchy of exceptions, whose root is java.lang.RuntimeException. And 
3rd party exception classes like SAXException will have to be wrapped 
inside Cocoon-specific runtime exceptions.

This is the approach taken by Spring, and I know that many of you don't 
like it, but ideas change with time, and we will have plenty of time to 
discuss and change the minds of people. Even mine, maybe ;-).

And I'm not going to throw out any baby. I'm going to throw out lots 
of totally useless "catch" clauses that do nothing but litter the code.
You don't need to use unchecked exceptions to do that. I don't see the 
connection.
How about this?

  } catch (ProcessingException e) {
getLogger().debug("Rethrowing exception", e);
throw new SAXException(e);
  }
This is not only useless, it's plain wrong.

	Ugo

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Ugo Cei wrote:

Nicola Ken Barozzi wrote:

In any case (and note that this is a vote, not a veto) the main reason 
is that in doing this we risk to throw out the baby with the water: I 
prefer a lot to remove ProcessingExceptions comptely and have the 
Cocoon components throw all the exceptions that the container can and 
will handle. IOW, I don't want to have an implicit contract but a more 
detailed and explicit one. In any case, generic ProcessingExceptions 
are evil, and this is a fact that we have known for a long time.
We have something worse than generic ProcessingExceptions being thrown, 
we have components throwing CascadingException. Which not only force 
clients to check them, but create an unnecessary dependence on Avalon.
Whaich I agree with, but still it's not about checked VS unchecked.

And I'm not going to throw out any baby. I'm going to throw out lots of 
totally useless "catch" clauses that do nothing but litter the code.
You don't need to use unchecked exceptions to do that. I don't see the 
connection.

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

RE: Documentation TOC started

2004-04-16 Thread David Crossley

H.vanderLinden wrote:
> David Crossley wrote:
> > Good idea and i admire your enthusiasm. 
> 
> Thanks.
> 
> > You will see my additions to that page were i tried to ensure
> 
> Yes I noticed.
> 
> > that it only links to local Cocoon documentation. Already i see
> > that people are not heeding that, and linking off to all sorts of
> > remote stuff. It may end up just being a jump page to everything.
> 
> Well, at first I like this page to be a kind of inventory to available and
> missing documentation. After that I think it needs to be structured, with
> some pages possibly rewritten and end up in the xdoc section. My ultimate
> goal is an ebook kind of documentation.

Great idea. This is then orthogonal to the total restructuring
of the xdocs, which was shelved until 2.2 because it would otherwise
break our URL space.

I would certainly like to see this ToC cater for the anticipated
"Reference documentation" (cannot find old dev@ or old docs@
discussion yet).

> Part of the documentation in my view is also a section on "Cocoon info in
> the rest of the world", although this might very well be a wiki page.

Well i think that we should start that now, then keep
this page clean.

One thing that we had discussed about Cocoon core xdocs
documentation was that it should not appear to sanctify any
external documentation, because there is some stuff out there
that we may not be happy with and where do we draw the line.
Also we do not want to get into URL management and dead links.
So yes, a separate Wiki page sounds better.

> > Please also scan the dev@ and the old docs@ archives.
> > This TOC topic has been discussed and commenced many times.
> 
> :-) I'm sure it has, I'll have a look.
> 
> > I think that such pages will need very clear intentions and
> > monitoring to keep on track.
> 
> Is the above clear enough?

That helps a lot thanks.

There is one aspect that i am still not clear about. Do you
envisage that this ToC itself would become an xdoc? I hope so.
If so, then that is why i would like it to be free from
references to external cocoon-related stuff.

--David

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException



Reinhard Pötz wrote:

Nicola Ken Barozzi wrote:

Ugo Cei wrote:

I think everyone interested has had the option of venting his opinion 
on the subject of checked vs. unchecked exceptions. For the record, 
here [1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can 
be reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. 
Tests fail, but they failed also before the change :-(.

So, please cast your votes.


-1

Nicola, could you summarize the reasons for your -1?
(... I haven't followed the previous discussion on exceptions very 
closely, so pls forgive if you already pointed out your concerns)



Nicola can speak for himself I suppose...

however, reading his answer again in the previous thread:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108196560613519&w=2
...I find some recognisable motivation for my personal under-enthousiasm 
on this topic

What I personally catched from the previous thread was (besides some 
fond memories of C++) some tendency towards a more nuanced view saying 
we should be cautious with checked exceptions and carefully decide when 
and where to introduce them. (by considering both sides of the contract 
that defines them?)

I grade my personal under-enthousiasm to the level of "indifference", 
leading me to a neutral 0-vote: a free ticket to those that are 
enthousiast :-)

For sure a set of more balanced considerations on the interfaces at hand 
(rather then a generalizing reaction triggered by some modern 
reactionary movement) would of have easily catched my enthousiasm...

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

Nicola Ken Barozzi wrote:
In any case (and note that this is a vote, not a veto) the main reason 
is that in doing this we risk to throw out the baby with the water: I 
prefer a lot to remove ProcessingExceptions comptely and have the Cocoon 
components throw all the exceptions that the container can and will 
handle. IOW, I don't want to have an implicit contract but a more 
detailed and explicit one. In any case, generic ProcessingExceptions are 
evil, and this is a fact that we have known for a long time.
We have something worse than generic ProcessingExceptions being thrown, 
we have components throwing CascadingException. Which not only force 
clients to check them, but create an unnecessary dependence on Avalon.

And I'm not going to throw out any baby. I'm going to throw out lots of 
totally useless "catch" clauses that do nothing but litter the code.

When we have done that, we'll have a cleaner baby, and we can send him 
to school so that he can learn to behave himself properly. But this is 
going to take time.

So, the options are: start small, remove useless code and do "continuous 
design", like Berin advocated. Or discuss for months, come up with a 
renewed exception hierarchy and take some more months to implement it.

	As always, IMHO

		Ugo

DO NOT REPLY [Bug 28424] - [PATCH] Allow applications access to the start and end of a request

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://issues.apache.org/bugzilla/show_bug.cgi?id=28424

[PATCH] Allow applications access to the start and end of a request





--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 07:29 ---
I see the value of a request listener, but I would prefer a solution where I 
can add more than one request listener. WDYT?

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException