Re: Processing Feedback: 3 alternatives for review
On 28.01.2008 20:41:22 Simon Pepping wrote: > Thanks for your extensive reply. > > On Fri, Jan 25, 2008 at 10:48:52PM +0100, Jeremias Maerki wrote: > > On 25.01.2008 21:57:46 Simon Pepping wrote: > > > Why does a user need to be able to write his own broadcaster, with his > > > own event producers, besides his own listeners? Why is it not enough > > > to let him write his own listeners? > > > > I guess you're referring to my choice to split the broadcaster into > > interface and default implementation. In the normal case, I don't expect > > anyone to implement another EventBroadcaster but maybe someone finds a > > reason to subclass DefaultEventBroadcaster, for example to do filtering. > > Indeed, the interface and the name 'Default...' made me think so. Why > do you not call them IEventBroadcaster and EventBroadcaster? Mainly because we don't usually use the "I" Pattern for naming interfaces in this project. Plus, for my taste, "EventBroadcaster" is too near to "IEventBroadcaster" and suggests to be the one and only implementation when it's really just the "default" implementation that will work for most users. > > I want to leave that possibility open. Furthermore, the interface is > > better readable than the implementation. Normally, it should be enough > > to implement a listener. Basically, I somewhat designed this whole thing > > to be reused outside the FOP domain as nothing in there is really > > FOP-specific. The naming of FopEvent somehow bugs me in this regard but > > I haven't found a better name, yet, to distinguish the event object from > > java.util.EventObject. Suggestions welcome. > > Why do you not just call it Event? The name is qualified by its > package. That's a good idea. I'll do that. Jeremias Maerki
Re: Processing Feedback: 3 alternatives for review
Thanks for your extensive reply. On Fri, Jan 25, 2008 at 10:48:52PM +0100, Jeremias Maerki wrote: > On 25.01.2008 21:57:46 Simon Pepping wrote: > > Why does a user need to be able to write his own broadcaster, with his > > own event producers, besides his own listeners? Why is it not enough > > to let him write his own listeners? > > I guess you're referring to my choice to split the broadcaster into > interface and default implementation. In the normal case, I don't expect > anyone to implement another EventBroadcaster but maybe someone finds a > reason to subclass DefaultEventBroadcaster, for example to do filtering. Indeed, the interface and the name 'Default...' made me think so. Why do you not call them IEventBroadcaster and EventBroadcaster? > I want to leave that possibility open. Furthermore, the interface is > better readable than the implementation. Normally, it should be enough > to implement a listener. Basically, I somewhat designed this whole thing > to be reused outside the FOP domain as nothing in there is really > FOP-specific. The naming of FopEvent somehow bugs me in this regard but > I haven't found a better name, yet, to distinguish the event object from > java.util.EventObject. Suggestions welcome. Why do you not just call it Event? The name is qualified by its package. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Processing Feedback: 3 alternatives for review
On 28.01.2008 11:52:23 Vincent Hennebert wrote:
> Jeremias Maerki wrote:
> > On 27.01.2008 16:15:45 Vincent Hennebert wrote:
>
>
> >>> No, the exception should always contain the cause.
> >> Then I’m missing the point of the new feedback mechanism. Why would you
> >> have to both create an event and throw an exception? All the more than
> >> the exception’s message wouldn’t be localized. And in the case of e.g.
> >> an error in the FO file we all but care about knowing at each place of
> >> the code exactly did the problem occur. Why couldn’t the broadcaster
> >> stop the process?
> >
> > Because a broadcaster (as its name says) only delivers messages.
> > Interrupting the process flow is the job of the programming language's
> > exception feature. Again, the event flow is mainly for informing the
> > user (or the technical user). He may or may not react on it. An
> > exception happens on exclusively a technical level (and in the past
> > could bubble up to the user because there was nothing else). Of course,
> > you could just swallow the last event that is generated right before the
> > exception but then you have to make sure the exception can equally be
> > localized, contains the same information as the event and you have two
> > different sources for event information (which the user has to know).
>
> Fine. I still disagree with that, but I understand your point about
> “only delivers messages”, and in the end it’s all a matter of how this
> will be implemented. So I’ll get back to you once I’ve had a look at the
> code, if I ever feel the need to. I just expect the exception to be
> caught by a higher-level object and transformed into an event like “A
> fatal error occured, aborting.”. Because, let me just repeat this,
> I don’t think the stacktrace is of any interest to the user, in case of
> a user-level error.
Ah, that's what you meant. Of course, I agree to that. Seems I
misunderstood you.
> Only when there’s a programming error in the code
> should the stacktrace be revealed, which will happen independently of
> the feedback mechanism anyway, if I’m correct.
Yes.
>
> > The main point of the feedback mechanism is to have a sequence of
> > notifications about the events in FOP (per processed document) so an
> > application can react on them and the user is informed about what's
> > going on. An exception is after all only a one time information and may
> > not happen at all (even though there may be multiple events during a
> > processing run). At the moment these events only appear in the log in an
> > unstructred, non-machine-readable way and without the benefit of keeping
> > the events appart in a multi-threaded system.
> >
> > I acknowledge that there is a certain overlap area between an exception
> > and the last event that indicates a fatal error. But sending the fatal
> > error event just before throwing the exception just makes sure we have a
> > uniform way of sending notifications to (potentially) multiple information
> > sinks. The "fatal error" will always produce an exception afterwards so
> > the integrator will know that he doesn't have to translate the exception
> > into a form that he can display it in the same spot as the events. If he
> > wants to filter the fatal exception, he can still do that, of course.
> > Again, I consider exceptions and events two completely different things
> > even if at first sight, it looks like redundancy.
> >
>
> To keep on the safe way you would
> probably have to do something like
> public BasicFOValidationEventProducer
> getBasicFOValidationEventProducer()
> and add as many methods as there are EventProducer implementations. Just
> forget that and go with the simple version.
> >>> -1 to that because
> >> Yeah, that’s precisely what I’m saying.
> >
> > Beg your pardon?
>
> See above: “Just forget that and go with the simple version”.
Ok. Anyway, just for illustration I've added such a wrapper. One can
easily see in the diff what change that causes to the client code:
http://svn.apache.org/viewvc?rev=615773&view=rev
> >>> I will import interfaces from all sorts of packages
> >>> in FOP, at least if these methods are added to DefaultEventBroadcaster.
> >>> Better would be something like:
> >>>
> >>> public class BasicFOValidationEventProducerFactory {
> >>> public static BasicFOValidationEventProducer
> >>> getBasicFOValidationEventProducer(EventBroadcaster broadcaster) {
> >>> return
> >>> (BasicFOValidationEventProducer)broadcaster.getEventProducerFor(BasicFOValidationEventProducer.class);
> >>
> >
> > No comments on the counterproposal?
>
> Since you’re asking ;-)
> I think it’s equivalent (may be wrong, though). In my version the
> generic method would be private and called by the typesafe ones:
> return (BasicFOValidationEventProducer)
> this.getEventProducerFor(BasicFOValidationEventProducer.class)
IMO, it's not equivalent. See the reason for my -1: the various im
Re: Processing Feedback: 3 alternatives for review
Hi Jeremias, Jeremias Maerki wrote: > On 27.01.2008 16:15:45 Vincent Hennebert wrote: >> But that mentioning of exceptions just makes me wondering of the >> following: what if an unrecoverable error occurs (say, too many cells on >> a table row)? I guess I’ll trigger an event of severity >> EventSeverity.ERROR and I absolutely expect that /every/ listener will >> throw an exception in such a case? Otherwise the processing will become >> hazardous. > You can always throw an exception right after the line where you > broadbast the event. That makes sure that the exception is thrown. > There's no need to rely on external behaviour. Hmmm, not very beautiful IMHO. You’ll have to do basically the same thing twice every time. And, suppose the listener doesn’t do anything particular, the exception that would be thrown afterwards would result into the same ugly stacktrace as we have currently, which would kill a bit the benefit of the new feedback mechanism, wouldn’t it? Is there anything wrong with expecting the error level (or fatal, or whatever) to somehow stop the process? Now that I’ve written that, re-read myself and was about to hit the “send message” button, I realise that processing feedback is a slightly different notion from exception handling. Still, my question above holds. >>> Please note that there is no stacktrace information with the event, only >> So? Do we care about the stacktrace ? > > In the exception case, yes, very much, in the event case, no. I was > trying to show that the two are very different beasts because you wrote: > "the exception that would be thrown afterwards would result > into the same ugly stacktrace as we have currently, which would kill > a bit the benefit of the new feedback mechanism, ..." > > IMO, the two aspects have no overlap so cannot be played one against the > other. Ok, to some extent I agree with that. >>> No, the exception should always contain the cause. >> Then I’m missing the point of the new feedback mechanism. Why would you >> have to both create an event and throw an exception? All the more than >> the exception’s message wouldn’t be localized. And in the case of e.g. >> an error in the FO file we all but care about knowing at each place of >> the code exactly did the problem occur. Why couldn’t the broadcaster >> stop the process? > > Because a broadcaster (as its name says) only delivers messages. > Interrupting the process flow is the job of the programming language's > exception feature. Again, the event flow is mainly for informing the > user (or the technical user). He may or may not react on it. An > exception happens on exclusively a technical level (and in the past > could bubble up to the user because there was nothing else). Of course, > you could just swallow the last event that is generated right before the > exception but then you have to make sure the exception can equally be > localized, contains the same information as the event and you have two > different sources for event information (which the user has to know). Fine. I still disagree with that, but I understand your point about “only delivers messages”, and in the end it’s all a matter of how this will be implemented. So I’ll get back to you once I’ve had a look at the code, if I ever feel the need to. I just expect the exception to be caught by a higher-level object and transformed into an event like “A fatal error occured, aborting.”. Because, let me just repeat this, I don’t think the stacktrace is of any interest to the user, in case of a user-level error. Only when there’s a programming error in the code should the stacktrace be revealed, which will happen independently of the feedback mechanism anyway, if I’m correct. > The main point of the feedback mechanism is to have a sequence of > notifications about the events in FOP (per processed document) so an > application can react on them and the user is informed about what's > going on. An exception is after all only a one time information and may > not happen at all (even though there may be multiple events during a > processing run). At the moment these events only appear in the log in an > unstructred, non-machine-readable way and without the benefit of keeping > the events appart in a multi-threaded system. > > I acknowledge that there is a certain overlap area between an exception > and the last event that indicates a fatal error. But sending the fatal > error event just before throwing the exception just makes sure we have a > uniform way of sending notifications to (potentially) multiple information > sinks. The "fatal error" will always produce an exception afterwards so > the integrator will know that he doesn't have to translate the exception > into a form that he can display it in the same spot as the events. If he > wants to filter the fatal exception, he can still do that, of course. > Again, I consider
Re: Processing Feedback: 3 alternatives for review
On 27.01.2008 16:15:45 Vincent Hennebert wrote: > > But that mentioning of exceptions just makes me wondering of the > following: what if an unrecoverable error occurs (say, too many cells on > a table row)? I guess I’ll trigger an event of severity > EventSeverity.ERROR and I absolutely expect that /every/ listener will > throw an exception in such a case? Otherwise the processing will become > hazardous. > >>> You can always throw an exception right after the line where you > >>> broadbast the event. That makes sure that the exception is thrown. > >>> There's no need to rely on external behaviour. > >> Hmmm, not very beautiful IMHO. You’ll have to do basically the same > >> thing twice every time. And, suppose the listener doesn’t do anything > >> particular, the exception that would be thrown afterwards would result > >> into the same ugly stacktrace as we have currently, which would kill > >> a bit the benefit of the new feedback mechanism, wouldn’t it? > >> Is there anything wrong with expecting the error level (or fatal, or > >> whatever) to somehow stop the process? > >> > >> Now that I’ve written that, re-read myself and was about to hit the > >> “send message” button, I realise that processing feedback is > >> a slightly different notion from exception handling. > >> Still, my question above holds. > > > > Please note that there is no stacktrace information with the event, only > > So? Do we care about the stacktrace ? In the exception case, yes, very much, in the event case, no. I was trying to show that the two are very different beasts because you wrote: "the exception that would be thrown afterwards would result into the same ugly stacktrace as we have currently, which would kill a bit the benefit of the new feedback mechanism, ..." IMO, the two aspects have no overlap so cannot be played one against the other. > > with the exception. The event mechanism is for clients with advanced > > requirements about getting, for example, the may want to create a list > > of all the problems which they present to the client in a special GUI > > that may even allow them to jump to the right place in the original > > document. An exception may not have this kind of information. > > > >> It’s not the listener that would have to throw the exception > > > > but it is allowed to do so (an overflow may be a reason to stop for some). > > Sure > > > >> (IIUC the whole thing is meant to allow third-party listeners to be > >> implemented in the future, like graphical progress bars?), but the > >> broadcaster (like you say below actually). > >> If for some reason this is not implemented that way, then I’d expect > >> something like the following: I would throw a FOPException, without any > >> explicit error message —this was already done via the feedback > >> mechanism— and some higher-level object would catch it, send a message > >> like “a fatal error occurred, processing stopped.” and actually stop. > >> I’m not very familiar with the API, but I guess this would be the > >> Renderer.startRenderer method, which would simply terminate normally. > > > > No, the exception should always contain the cause. > > Then I’m missing the point of the new feedback mechanism. Why would you > have to both create an event and throw an exception? All the more than > the exception’s message wouldn’t be localized. And in the case of e.g. > an error in the FO file we all but care about knowing at each place of > the code exactly did the problem occur. Why couldn’t the broadcaster > stop the process? Because a broadcaster (as its name says) only delivers messages. Interrupting the process flow is the job of the programming language's exception feature. Again, the event flow is mainly for informing the user (or the technical user). He may or may not react on it. An exception happens on exclusively a technical level (and in the past could bubble up to the user because there was nothing else). Of course, you could just swallow the last event that is generated right before the exception but then you have to make sure the exception can equally be localized, contains the same information as the event and you have two different sources for event information (which the user has to know). The main point of the feedback mechanism is to have a sequence of notifications about the events in FOP (per processed document) so an application can react on them and the user is informed about what's going on. An exception is after all only a one time information and may not happen at all (even though there may be multiple events during a processing run). At the moment these events only appear in the log in an unstructred, non-machine-readable way and without the benefit of keeping the events appart in a multi-threaded system. I acknowledge that there is a certain overlap area between an exception and the last event that indicates a fatal error. But sending the fatal error event just before throwing the exception j
Re: Processing Feedback: 3 alternatives for review
Jeremias Maerki wrote: Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback I still hadn't have time to review this, sorry. Maybe next Tuesday. J.Pietschmann
Re: Processing Feedback: 3 alternatives for review
But that mentioning of exceptions just makes me wondering of the
following: what if an unrecoverable error occurs (say, too many cells on
a table row)? I guess I’ll trigger an event of severity
EventSeverity.ERROR and I absolutely expect that /every/ listener will
throw an exception in such a case? Otherwise the processing will become
hazardous.
>>> You can always throw an exception right after the line where you
>>> broadbast the event. That makes sure that the exception is thrown.
>>> There's no need to rely on external behaviour.
>> Hmmm, not very beautiful IMHO. You’ll have to do basically the same
>> thing twice every time. And, suppose the listener doesn’t do anything
>> particular, the exception that would be thrown afterwards would result
>> into the same ugly stacktrace as we have currently, which would kill
>> a bit the benefit of the new feedback mechanism, wouldn’t it?
>> Is there anything wrong with expecting the error level (or fatal, or
>> whatever) to somehow stop the process?
>>
>> Now that I’ve written that, re-read myself and was about to hit the
>> “send message” button, I realise that processing feedback is
>> a slightly different notion from exception handling.
>> Still, my question above holds.
>
> Please note that there is no stacktrace information with the event, only
So? Do we care about the stacktrace ?
> with the exception. The event mechanism is for clients with advanced
> requirements about getting, for example, the may want to create a list
> of all the problems which they present to the client in a special GUI
> that may even allow them to jump to the right place in the original
> document. An exception may not have this kind of information.
>
>> It’s not the listener that would have to throw the exception
>
> but it is allowed to do so (an overflow may be a reason to stop for some).
Sure
>> (IIUC the whole thing is meant to allow third-party listeners to be
>> implemented in the future, like graphical progress bars?), but the
>> broadcaster (like you say below actually).
>> If for some reason this is not implemented that way, then I’d expect
>> something like the following: I would throw a FOPException, without any
>> explicit error message —this was already done via the feedback
>> mechanism— and some higher-level object would catch it, send a message
>> like “a fatal error occurred, processing stopped.” and actually stop.
>> I’m not very familiar with the API, but I guess this would be the
>> Renderer.startRenderer method, which would simply terminate normally.
>
> No, the exception should always contain the cause.
Then I’m missing the point of the new feedback mechanism. Why would you
have to both create an event and throw an exception? All the more than
the exception’s message wouldn’t be localized. And in the case of e.g.
an error in the FO file we all but care about knowing at each place of
the code exactly did the problem occur. Why couldn’t the broadcaster
stop the process?
>>> We could even add a convention that for an event with
>>> EventSeverity.FATAL the first/second/last parameter must be an Exception
>>> class. The Exception class would have to have a constructor that takes
>>> an EventObject as parameter for initializing the exception. The dynamic
>>> proxy would then throw the exception right after broadcasting the
>>> exception. Or we could change the EventProducer convention so that every
>>> method returns the generated EventObject that you can then use to
>>> initialize an exception. Probably easier and more flexible.
>>> Please tell me how I should "keep Java 1.5 in mind"? I cannot use
>> Well, nothing more than avoid designing classes to circumvent Java 1.4’s
>> lack of genericity (or typesafe enums). The following method:
>> public EventProducer getEventProducerFor(Class class)
>> isn’t safe and bad design in Java 1.4.
>
> How is this bad design? It's just generic. Your solution below is just
Precisely because it’s not typesafe. Ok, bad design is probably a bit
strong, but it’s certainly dangerous.
> the typesafe wrapper around the above. Otherwise you have to duplicate
> the code for each method which is worse.
>
>> To keep on the safe way you would
>> probably have to do something like
>> public BasicFOValidationEventProducer getBasicFOValidationEventProducer()
>> and add as many methods as there are EventProducer implementations. Just
>> forget that and go with the simple version.
>
> -1 to that because
Yeah, that’s precisely what I’m saying.
> I will import interfaces from all sorts of packages
> in FOP, at least if these methods are added to DefaultEventBroadcaster.
> Better would be something like:
>
> public class BasicFOValidationEventProducerFactory {
> public static BasicFOValidationEventProducer
> getBasicFOValidationEventProducer(EventBroadcaster broadcaster) {
> return
> (BasicFOValidationEventProducer)broadcaster.getEventProducerFor(BasicFOValidationEventProducer.class);
Vinc
Re: Processing Feedback: 3 alternatives for review
On 25.01.2008 21:57:46 Simon Pepping wrote: > Hi, > > I am not familiar with these technologies, so I have a few questions: > > Who creates the broadcaster? The user? In the user agent? Does FOP > provide the DefaultEventBroadcaster? The user agent will instantiate and provide the broadcaster (isn't implemented, yet). FOP code uses the broadcaster to send events through a single location (the broadcaster). The user registers listeners with the broadcaster in order to react to events. > Who creates the listener? The user? Registered with his > self-instantiated broadcaster? The user gets access to the FOP-instantiated broadcaster through the user agent to register his listener(s). > The FOP events are created in the FOP code, not? Are they only created > if there is a broadcaster? Events are created in FOP code, yes. The broadcaster will always be there, one per rendering run. > The wiki page is not clear because it contains contributions from > different persons, but it is not clear who wrote what. The Blammo proposal comes from Wilfred Springer, the other two below that from me. > Is there a URL for QDox? Is there only one QDox? I found two, but they > may be the same. What is ALv2? The Apache License version 2? I know of only one QDox: http://qdox.codehaus.org/ There used to be a SourceForge project but that has moved to Codehaus. ALv2 = Apache License version 2.0, yes. > I am not clear about the role of the XML file. Does the > getEventProducerFor method read the XML file and based on its content > create the producer, at runtime? Does it cache producers? Maybe the > cache is even static? The XML file is read once in the static initializer of DefaultEventBroadcaster: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_ProcessingFeedback/src/java/org/apache/fop/events/DefaultEventBroadcaster.java?view=markup Lookups at runtime are done using two get() operations to HashMaps and should be very fast. Note that the event frequency is far lower than logging calls, but the events are unconditional. No modifications will happen to the EventModel at runtime which should avoid potential multi-threading problems because of concurrent access to the same resources. The static initializer is guaranteed to be synchronized. I intend to add an optimization that will stop event broadcasting at the earliest possible point if there are no listeners. > Why does a user need to be able to write his own broadcaster, with his > own event producers, besides his own listeners? Why is it not enough > to let him write his own listeners? I guess you're referring to my choice to split the broadcaster into interface and default implementation. In the normal case, I don't expect anyone to implement another EventBroadcaster but maybe someone finds a reason to subclass DefaultEventBroadcaster, for example to do filtering. I want to leave that possibility open. Furthermore, the interface is better readable than the implementation. Normally, it should be enough to implement a listener. Basically, I somewhat designed this whole thing to be reused outside the FOP domain as nothing in there is really FOP-specific. The naming of FopEvent somehow bugs me in this regard but I haven't found a better name, yet, to distinguish the event object from java.util.EventObject. Suggestions welcome. HTH > Regards, Simon > > On Thu, Jan 24, 2008 at 03:45:59PM +0100, Jeremias Maerki wrote: > > Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback > > > > There are now 3 different approaches we could take for an event > > mechanism to better inform a user (technical or real-life) of events, > > problems and progress inside FOP, per rendering run of course. > > > > I'd be grateful for your thoughts. I'm personally preferring the > > "extended approach" even though it's the most complex one but it > > provides ease of use once it's built and contains QA measures so we > > don't accidentally forget any message templates. > > > > Of course, we could add these message templates as javadoc tags (like > > the Blammo proposal, but in all languages) but that puts everything in > > one file which I'd like to avoid. As long as there are only English it's > > fine, but if the community starts producing all sorts of translations it > > could get messy. > > > > Blammo is interesting and gave me some ideas but it's not "there". I'm > > afraid that improving Blammo would delay the whole thing too much. > > > > Jeremias Maerki > > > > -- > Simon Pepping > home page: http://www.leverkruid.eu Jeremias Maerki
Re: Processing Feedback: 3 alternatives for review
Hi, I am not familiar with these technologies, so I have a few questions: Who creates the broadcaster? The user? In the user agent? Does FOP provide the DefaultEventBroadcaster? Who creates the listener? The user? Registered with his self-instantiated broadcaster? The FOP events are created in the FOP code, not? Are they only created if there is a broadcaster? The wiki page is not clear because it contains contributions from different persons, but it is not clear who wrote what. Is there a URL for QDox? Is there only one QDox? I found two, but they may be the same. What is ALv2? The Apache License version 2? I am not clear about the role of the XML file. Does the getEventProducerFor method read the XML file and based on its content create the producer, at runtime? Does it cache producers? Maybe the cache is even static? Why does a user need to be able to write his own broadcaster, with his own event producers, besides his own listeners? Why is it not enough to let him write his own listeners? Regards, Simon On Thu, Jan 24, 2008 at 03:45:59PM +0100, Jeremias Maerki wrote: > Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback > > There are now 3 different approaches we could take for an event > mechanism to better inform a user (technical or real-life) of events, > problems and progress inside FOP, per rendering run of course. > > I'd be grateful for your thoughts. I'm personally preferring the > "extended approach" even though it's the most complex one but it > provides ease of use once it's built and contains QA measures so we > don't accidentally forget any message templates. > > Of course, we could add these message templates as javadoc tags (like > the Blammo proposal, but in all languages) but that puts everything in > one file which I'd like to avoid. As long as there are only English it's > fine, but if the community starts producing all sorts of translations it > could get messy. > > Blammo is interesting and gave me some ideas but it's not "there". I'm > afraid that improving Blammo would delay the whole thing too much. > > Jeremias Maerki > -- Simon Pepping home page: http://www.leverkruid.eu
Re: Processing Feedback: 3 alternatives for review
On 25.01.2008 17:50:44 Vincent Hennebert wrote: > Jeremias Maerki wrote: > > On 25.01.2008 12:35:50 Vincent Hennebert wrote: > >> Hi Jeremias, > >> > >> Jeremias Maerki wrote: > >>> That's actually one of the requirements, I just haven't discussed this > >>> explicitely on the Wiki page. I assumed everyone can throw any unchecked > >>> exception in the listener. Introducing a checked exception for this > >>> purpose would be horrible as it would go through all of FOP which I > >>> don't think would be useful. Does anyone see that differently? > >> No it’s ok to me if particular implementations of FopEventListener throw > >> unchecked exceptions. > >> > >> But that mentioning of exceptions just makes me wondering of the > >> following: what if an unrecoverable error occurs (say, too many cells on > >> a table row)? I guess I’ll trigger an event of severity > >> EventSeverity.ERROR and I absolutely expect that /every/ listener will > >> throw an exception in such a case? Otherwise the processing will become > >> hazardous. > > > > You can always throw an exception right after the line where you > > broadbast the event. That makes sure that the exception is thrown. > > There's no need to rely on external behaviour. > > Hmmm, not very beautiful IMHO. You’ll have to do basically the same > thing twice every time. And, suppose the listener doesn’t do anything > particular, the exception that would be thrown afterwards would result > into the same ugly stacktrace as we have currently, which would kill > a bit the benefit of the new feedback mechanism, wouldn’t it? > Is there anything wrong with expecting the error level (or fatal, or > whatever) to somehow stop the process? > > Now that I’ve written that, re-read myself and was about to hit the > “send message” button, I realise that processing feedback is a slightly > different notion from exception handling. > Still, my question above holds. Please note that there is no stacktrace information with the event, only with the exception. The event mechanism is for clients with advanced requirements about getting, for example, the may want to create a list of all the problems which they present to the client in a special GUI that may even allow them to jump to the right place in the original document. An exception may not have this kind of information. > It’s not the listener that would have to throw the exception but it is allowed to do so (an overflow may be a reason to stop for some). > (IIUC the whole thing is meant to allow third-party listeners to be > implemented in the future, like graphical progress bars?), but the > broadcaster (like you say below actually). > If for some reason this is not implemented that way, then I’d expect > something like the following: I would throw a FOPException, without any > explicit error message —this was already done via the feedback > mechanism— and some higher-level object would catch it, send a message > like “a fatal error occurred, processing stopped.” and actually stop. > I’m not very familiar with the API, but I guess this would be the > Renderer.startRenderer method, which would simply terminate normally. No, the exception should always contain the cause. > > > We could even add a convention that for an event with > > EventSeverity.FATAL the first/second/last parameter must be an Exception > > class. The Exception class would have to have a constructor that takes > > an EventObject as parameter for initializing the exception. The dynamic > > proxy would then throw the exception right after broadcasting the > > exception. Or we could change the EventProducer convention so that every > > method returns the generated EventObject that you can then use to > > initialize an exception. Probably easier and more flexible. > > > >> As to the best approach, the extended one looks good to me. May I ask > >> you to keep Java 1.5 in mind when designing your classes? It’s not far > >> away now and there are things which are likely to become much more > >> elegant with genericity. Just to take your example on the wiki page: > >> in EventBroadcaster: > >> public T getEventProducerFor(Class class) > >> > >> then I can make > >> BasicFOValidationEventProducer producer = > >> getUserAgent().getEventBroadcaster().getEventProducerFor( > >> BasicFOValidationEventProducer.class); > >> Exit the hazardous cast and potential run-time exception :-) > > > > Please tell me how I should "keep Java 1.5 in mind"? I cannot use > > Well, nothing more than avoid designing classes to circumvent Java 1.4’s > lack of genericity (or typesafe enums). The following method: > public EventProducer getEventProducerFor(Class class) > isn’t safe and bad design in Java 1.4. How is this bad design? It's just generic. Your solution below is just the typesafe wrapper around the above. Otherwise you have to duplicate the code for each method which is worse. > To keep on the safe way you would
Re: Processing Feedback: 3 alternatives for review
Jeremias Maerki wrote: > On 25.01.2008 12:35:50 Vincent Hennebert wrote: >> Hi Jeremias, >> >> Jeremias Maerki wrote: >>> That's actually one of the requirements, I just haven't discussed this >>> explicitely on the Wiki page. I assumed everyone can throw any unchecked >>> exception in the listener. Introducing a checked exception for this >>> purpose would be horrible as it would go through all of FOP which I >>> don't think would be useful. Does anyone see that differently? >> No it’s ok to me if particular implementations of FopEventListener throw >> unchecked exceptions. >> >> But that mentioning of exceptions just makes me wondering of the >> following: what if an unrecoverable error occurs (say, too many cells on >> a table row)? I guess I’ll trigger an event of severity >> EventSeverity.ERROR and I absolutely expect that /every/ listener will >> throw an exception in such a case? Otherwise the processing will become >> hazardous. > > You can always throw an exception right after the line where you > broadbast the event. That makes sure that the exception is thrown. > There's no need to rely on external behaviour. Hmmm, not very beautiful IMHO. You’ll have to do basically the same thing twice every time. And, suppose the listener doesn’t do anything particular, the exception that would be thrown afterwards would result into the same ugly stacktrace as we have currently, which would kill a bit the benefit of the new feedback mechanism, wouldn’t it? Is there anything wrong with expecting the error level (or fatal, or whatever) to somehow stop the process? Now that I’ve written that, re-read myself and was about to hit the “send message” button, I realise that processing feedback is a slightly different notion from exception handling. Still, my question above holds. It’s not the listener that would have to throw the exception (IIUC the whole thing is meant to allow third-party listeners to be implemented in the future, like graphical progress bars?), but the broadcaster (like you say below actually). If for some reason this is not implemented that way, then I’d expect something like the following: I would throw a FOPException, without any explicit error message —this was already done via the feedback mechanism— and some higher-level object would catch it, send a message like “a fatal error occurred, processing stopped.” and actually stop. I’m not very familiar with the API, but I guess this would be the Renderer.startRenderer method, which would simply terminate normally. > We could even add a convention that for an event with > EventSeverity.FATAL the first/second/last parameter must be an Exception > class. The Exception class would have to have a constructor that takes > an EventObject as parameter for initializing the exception. The dynamic > proxy would then throw the exception right after broadcasting the > exception. Or we could change the EventProducer convention so that every > method returns the generated EventObject that you can then use to > initialize an exception. Probably easier and more flexible. > >> As to the best approach, the extended one looks good to me. May I ask >> you to keep Java 1.5 in mind when designing your classes? It’s not far >> away now and there are things which are likely to become much more >> elegant with genericity. Just to take your example on the wiki page: >> in EventBroadcaster: >> public T getEventProducerFor(Class class) >> >> then I can make >> BasicFOValidationEventProducer producer = >> getUserAgent().getEventBroadcaster().getEventProducerFor( >> BasicFOValidationEventProducer.class); >> Exit the hazardous cast and potential run-time exception :-) > > Please tell me how I should "keep Java 1.5 in mind"? I cannot use Well, nothing more than avoid designing classes to circumvent Java 1.4’s lack of genericity (or typesafe enums). The following method: public EventProducer getEventProducerFor(Class class) isn’t safe and bad design in Java 1.4. To keep on the safe way you would probably have to do something like public BasicFOValidationEventProducer getBasicFOValidationEventProducer() and add as many methods as there are EventProducer implementations. Just forget that and go with the simple version. In fact I’m asking you for keeping your life simple :-) Vincent -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Processing Feedback: 3 alternatives for review
On 25.01.2008 12:35:50 Vincent Hennebert wrote: > Hi Jeremias, > > Jeremias Maerki wrote: > > That's actually one of the requirements, I just haven't discussed this > > explicitely on the Wiki page. I assumed everyone can throw any unchecked > > exception in the listener. Introducing a checked exception for this > > purpose would be horrible as it would go through all of FOP which I > > don't think would be useful. Does anyone see that differently? > > No it’s ok to me if particular implementations of FopEventListener throw > unchecked exceptions. > > But that mentioning of exceptions just makes me wondering of the > following: what if an unrecoverable error occurs (say, too many cells on > a table row)? I guess I’ll trigger an event of severity > EventSeverity.ERROR and I absolutely expect that /every/ listener will > throw an exception in such a case? Otherwise the processing will become > hazardous. You can always throw an exception right after the line where you broadbast the event. That makes sure that the exception is thrown. There's no need to rely on external behaviour. We could even add a convention that for an event with EventSeverity.FATAL the first/second/last parameter must be an Exception class. The Exception class would have to have a constructor that takes an EventObject as parameter for initializing the exception. The dynamic proxy would then throw the exception right after broadcasting the exception. Or we could change the EventProducer convention so that every method returns the generated EventObject that you can then use to initialize an exception. Probably easier and more flexible. > As to the best approach, the extended one looks good to me. May I ask > you to keep Java 1.5 in mind when designing your classes? It’s not far > away now and there are things which are likely to become much more > elegant with genericity. Just to take your example on the wiki page: > in EventBroadcaster: > public T getEventProducerFor(Class class) > > then I can make > BasicFOValidationEventProducer producer = > getUserAgent().getEventBroadcaster().getEventProducerFor( > BasicFOValidationEventProducer.class); > Exit the hazardous cast and potential run-time exception :-) Please tell me how I should "keep Java 1.5 in mind"? I cannot use generics anywhere now. Or do you mean only on the Wiki? That would only make the whole thing confusing and a potential source for misunderstandings. Jeremias Maerki
Re: Processing Feedback: 3 alternatives for review
Hi Jeremias, Jeremias Maerki wrote: > That's actually one of the requirements, I just haven't discussed this > explicitely on the Wiki page. I assumed everyone can throw any unchecked > exception in the listener. Introducing a checked exception for this > purpose would be horrible as it would go through all of FOP which I > don't think would be useful. Does anyone see that differently? No it’s ok to me if particular implementations of FopEventListener throw unchecked exceptions. But that mentioning of exceptions just makes me wondering of the following: what if an unrecoverable error occurs (say, too many cells on a table row)? I guess I’ll trigger an event of severity EventSeverity.ERROR and I absolutely expect that /every/ listener will throw an exception in such a case? Otherwise the processing will become hazardous. As to the best approach, the extended one looks good to me. May I ask you to keep Java 1.5 in mind when designing your classes? It’s not far away now and there are things which are likely to become much more elegant with genericity. Just to take your example on the wiki page: in EventBroadcaster: public T getEventProducerFor(Class class) then I can make BasicFOValidationEventProducer producer = getUserAgent().getEventBroadcaster().getEventProducerFor( BasicFOValidationEventProducer.class); Exit the hazardous cast and potential run-time exception :-) Vincent > On 24.01.2008 16:33:23 Max Berger wrote: >> Jeremias, >> >> on the message consumer side it would be nice if message handlers could >> throw exceptions - this would allow "strict" handlers to immediately >> cancel processing of a fo file, a more lenient handlers could just emit >> warnings (similar to sax handlers), and a batch system could ignore it. >> >> However, this would require every function which uses logging to throw a >> common exception (FopFeedbackException, or something like that). >> >> Max -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
Re: Processing Feedback: 3 alternatives for review
On 24.01.2008 23:15:09 Andreas Delmelle wrote: > > Of course, we could add these message templates as javadoc tags (like > > the Blammo proposal, but in all languages) but that puts everything in > > one file which I'd like to avoid. As long as there are only English > > it's > > fine, but if the community starts producing all sorts of > > translations it > > could get messy. > > Agreed, although, OTOH we should precisely encourage the community to > bundle their efforts in providing FOP with default messages for the > different languages. I guess this is what you mean by "An existing > translation file is merged automatically so existing translations > aren't lost." Sometimes, I'm too minimalistic. :-) What I mean by that is: The translation files will live in some directory in SVN (i.e. not under build/something). Suppose you have: translations.xml trans1: blah trans2: blah blah trans3: blah blah blah ...and you now add a new event method to one of the EventProducer interfaces. This adds a new translation to the XML file: translations.xml trans1: blah trans2: blah blah trans3: blah blah blah trans4: SVN will notice the file has changed and you will notice in the diff before committing that you have to add a missing translation. If you still forget it, you'll get an error message first time FOP is run and the translations are loaded. I do want to encourage that the community contributes translation files. It's a very easy way to contribute with no need for Java knowledge. Of course, as the stuff grows we will not always immediately have a translation for all new events which makes the fallback to English important. > In time we could also serve standard sets of FOP > resource JARs containing pre-generated XMLs that users can add to > their environment. Keep English as the only 'bootstrapped' language, > and offer the rest as optional (?) That's a possibility and easy to do but I'd really like to keep the translations in FOP's codebase. The thing with hyphenation is suboptimal enough. Jeremias Maerki
Re: Processing Feedback: 3 alternatives for review
On Jan 24, 2008, at 15:45, Jeremias Maerki wrote: Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback There are now 3 different approaches we could take for an event mechanism to better inform a user (technical or real-life) of events, problems and progress inside FOP, per rendering run of course. I'd be grateful for your thoughts. I'm personally preferring the "extended approach" even though it's the most complex one but it provides ease of use once it's built and contains QA measures so we don't accidentally forget any message templates. Your proposed extended approach also looks like *the* way to go to me, even if more complex to implement. I had some ideas of my own in that area, and they looked very much like what you're describing. The only thing I was still missing was the bridge, as it were, that you propose in the form of the build-time generated XML. Pretty ingenious. :-) Of course, we could add these message templates as javadoc tags (like the Blammo proposal, but in all languages) but that puts everything in one file which I'd like to avoid. As long as there are only English it's fine, but if the community starts producing all sorts of translations it could get messy. Agreed, although, OTOH we should precisely encourage the community to bundle their efforts in providing FOP with default messages for the different languages. I guess this is what you mean by "An existing translation file is merged automatically so existing translations aren't lost." In time we could also serve standard sets of FOP resource JARs containing pre-generated XMLs that users can add to their environment. Keep English as the only 'bootstrapped' language, and offer the rest as optional (?) Cheers Andreas
Re: Processing Feedback: 3 alternatives for review
That's actually one of the requirements, I just haven't discussed this explicitely on the Wiki page. I assumed everyone can throw any unchecked exception in the listener. Introducing a checked exception for this purpose would be horrible as it would go through all of FOP which I don't think would be useful. Does anyone see that differently? On 24.01.2008 16:33:23 Max Berger wrote: > Jeremias, > > on the message consumer side it would be nice if message handlers could > throw exceptions - this would allow "strict" handlers to immediately > cancel processing of a fo file, a more lenient handlers could just emit > warnings (similar to sax handlers), and a batch system could ignore it. > > However, this would require every function which uses logging to throw a > common exception (FopFeedbackException, or something like that). > > Max > > > On Don, 2008-01-24 at 15:45 +0100, Jeremias Maerki wrote: > > Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback > > > > There are now 3 different approaches we could take for an event > > mechanism to better inform a user (technical or real-life) of events, > > problems and progress inside FOP, per rendering run of course. > > > > I'd be grateful for your thoughts. I'm personally preferring the > > "extended approach" even though it's the most complex one but it > > provides ease of use once it's built and contains QA measures so we > > don't accidentally forget any message templates. > > > > Of course, we could add these message templates as javadoc tags (like > > the Blammo proposal, but in all languages) but that puts everything in > > one file which I'd like to avoid. As long as there are only English it's > > fine, but if the community starts producing all sorts of translations it > > could get messy. > > > > Blammo is interesting and gave me some ideas but it's not "there". I'm > > afraid that improving Blammo would delay the whole thing too much. > > > > Jeremias Maerki > > Jeremias Maerki
Re: Processing Feedback: 3 alternatives for review
Jeremias, on the message consumer side it would be nice if message handlers could throw exceptions - this would allow "strict" handlers to immediately cancel processing of a fo file, a more lenient handlers could just emit warnings (similar to sax handlers), and a batch system could ignore it. However, this would require every function which uses logging to throw a common exception (FopFeedbackException, or something like that). Max On Don, 2008-01-24 at 15:45 +0100, Jeremias Maerki wrote: > Please see: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback > > There are now 3 different approaches we could take for an event > mechanism to better inform a user (technical or real-life) of events, > problems and progress inside FOP, per rendering run of course. > > I'd be grateful for your thoughts. I'm personally preferring the > "extended approach" even though it's the most complex one but it > provides ease of use once it's built and contains QA measures so we > don't accidentally forget any message templates. > > Of course, we could add these message templates as javadoc tags (like > the Blammo proposal, but in all languages) but that puts everything in > one file which I'd like to avoid. As long as there are only English it's > fine, but if the community starts producing all sorts of translations it > could get messy. > > Blammo is interesting and gave me some ideas but it's not "there". I'm > afraid that improving Blammo would delay the whole thing too much. > > Jeremias Maerki >
