Exception thrown in OGNL evaluation.
Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too. This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -Original Message- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exception thrown in OGNL evaluation.
Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too. This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -Original Message- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exception thrown in OGNL evaluation.
Hi Guys, I'm going to chime in in support of Ruimo Uno here. We have had problems with this too. This is not a design issue. At the end of the day, the view is calling a method and what that method does is largely irrelevant. It may throw an exception, even if you have carefully designed your application to make that unlikely. I agree that you do not want exception handling code in your views, but that isn't what we are talking about here. If a unexpected problem occurs that prevents the view from rendering properly, I don't want it handled, I want an exception thrown, eventually resulting in a 500 error. The problem is that the exception IS handled (by swallowing it). IMNSHO reacting to an exception by quietly failing to render a part of the view, and continuing on, is simply broken. cheers Perryn -Original Message- From: Ruimo Uno [mailto:[EMAIL PROTECTED] Sent: Monday, 20 August 2007 1:57 PM To: Struts Developers List Subject: Re: Exception thrown in OGNL evaluation. Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception thrown in OGNL evaluation.
Hi, Rene, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > > You won't get NPE in this scenario. Ognl automatically create instance > > for you. I believe you know about this feature. > > > > Not when trying to read the property, only when applying values. The first > invocation with null foo object will cause OGNL to try to read the > property of the foo.name property and fail silently - no object will be > created. This will happen when then parameters interceptor tries to apply > values to the model (when invoking the save view) Hmm, I am not sure I fully understand what you mean but I also talking about applying the http request parameters into the model object. The automatic instance creation is done inside the OGNL and the code chage that I proposed in my first mail is not for OGNL but for XWork. You can still happily use this convenient feature even with my code change. > > Closing the session should be fixed as a design bug. I agree with you > > at this point. But in this case, the system should show an user > > friendly 'sorry page' so that the user can perform appropriate action. > > As we cannot take all bugs out of our system, need a sfety net. If > > there is a network problem between ap server and db server, lazy > > loading will fail by system error. > > but how could the fooService.getById(this.id), executed by the prepare or > action method succeed and the lazy reference getter fail just a few > millies later, when the session is still open??? Yes, it should be a rare case but there IS a possibility and also there may be bugs around there and they may throw the RuntimeException, such as NPE. > Yes, but your display logic should not handle errors coming from business > logic. That should always be done in the controller stack (action / > interceptors), or even underlying layers if apply. This simply means > moving error prone calls of the underlying layers to the controller, not > the view. While JPA / Hibernate gives you the opportunity of doing lazy > fetching of references (which is good, but very unique to ORM, but not to > other service providers), it is not always the best pattern have the > _view_ initialize the fetches you _know_ you will need... I understand your design preference. It is sometimes preferable to take easier design pattern such as dto pattern that never access db while view rendering. The code may become a bit more redundant but it should simplify the problem determination. But I still wonder why XWork swallows the system error/runtime excpetion if there is no meanig to do so. As I stated above, the automatic instance creation won't be destroyed. Any other concers to rethrow the system error/runtime exception to the upper layer? -- Ruimo Uno (Shisei Hanai) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception thrown in OGNL evaluation.
Am Fr, 17.08.2007, 11:28, schrieb Ruimo Uno: > Rane, > > 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: >> Ruimo, >> >> see below >> >> Ruimo Uno schrieb: >> > Hi, thanks for your comment. >> > >> > 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: >> >> It's no bug, it's a feature... >> >> >> >> The policy for model access (e.g. property calls) via expression >> >> evaluation is fail silent. It would cause tons of exceptions if ognl >> >> expression evaluation / property access would not swallow them. >> > >> > I feel it is overkill. The property getters in action classes may >> > throw RuntimeException because of programming bugs. Even in this case, >> > the current implementation just ignore the exception and the shown >> > page will be just corrupted. We cannot show user friendly 'sorry page' >> > because the Struts exception handler cannot get exception. >> > >> >> You would not be able to use the most common use patterns without having >> to do exepction handling on the JSP page then! Think of a model object >> foo with a getter getFoo() in your a FooCrudAction. You have an >> editFoo.jsp. If you want to create a new foo entry, the sequence would >> be >> - invoke edit/create action, triggering execute() in FooCrudAction >> - render editFoo.jsp >> - submit form >> - invoke save action, triggering save() in FooCrudAction >> - on success, render editFoo.jsp >> >> if ognl would not swallow the exceptions, then placing simple tag like >> >> would fail with NPE in first rendering if you did not provide a >> (unnecessary) this.foo=new Foo() in your execute() method, or a lazy >> getter. Just a simple example. But if you would change this behaviour, >> the showcase app code would need approximately an additional 10-15% more >> code just for doing unneeded initializations and exception handling. > > You won't get NPE in this scenario. Ognl automatically create instance > for you. I believe you know about this feature. > Not when trying to read the property, only when applying values. The first invocation with null foo object will cause OGNL to try to read the property of the foo.name property and fail silently - no object will be created. This will happen when then parameters interceptor tries to apply values to the model (when invoking the save view) >> What if the execption is thrown? It will be thrown within JSP page >> handling, and swallowed there! Your OpenSessionInView Interceptor or any >> higher level layer would take no notice of the exception. Instead you >> would have to use the anti-pattern of exception handliing with in JSP >> code to present useful information. > > In the API specification for PageContext.handleException() states the > following: > > --- > If no error page is defined in the page, the exception should be > rethrown so that the standard servlet error handling takes over. > --- > > If my understanding is correct, the exception should be rethrown and > the servlet layer can handle it. > good point, my fault. But nevertheless, your controller should be responsible for deciding what to present, and where to dispatch to. This is commonly done with either having your action method return results other than "success" (eg. "error" then) or having your interceptor change the result after dealing with the exception. >> >> Most likely, you are doing business logic calls in your model access >> >> domain and you should think of moving any call with the possibility >> to get >> >> service relevant exceptions to the described business logic domain >> access >> >> methods. >> > >> > No, it is not 'business logc'. In 'open session in view' pattern, the >> > db transaction is kept open until the view rendering finishies. If you >> > call the property access method of the acction class, it calls the >> > getter method of tne entity class. It triggers O/R mapping layer >> > invocation and lazily accesses the database. As a result, some kind of >> > system exception (such as SQLException) may be thrown while view >> > rendering. >> > >> >> This pattern is widely used, I'm using it myself in many applications. >> But where do you expect the exception? If you make sure that you have a >> foo object loaded from persistence layer, the the foo.getBars() call to >> a a lazy initialized collection of referenced objects should never fail >> due to _runtime_ problems you have to deal with. If, for example, for >> some reason your session is closed, you have to look for a design time >> problem - most commonly people forget about holding the session open >> (luckily we have OpenSessionInView). > > Closing the session should be fixed as a design bug. I agree with you > at this point. But in this case, the system should show an user > friendly 'sorry page' so that the user can perform appropriate action. > As we cannot take all bugs out of our system, need a sfety net. If > there is a network problem between ap server and db server, lazy > loading will fail by system error. > but how could the fooService.getById(
Re: Exception thrown in OGNL evaluation.
Rane, 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > Ruimo, > > see below > > Ruimo Uno schrieb: > > Hi, thanks for your comment. > > > > 2007/8/17, Rene Gielen <[EMAIL PROTECTED]>: > >> It's no bug, it's a feature... > >> > >> The policy for model access (e.g. property calls) via expression > >> evaluation is fail silent. It would cause tons of exceptions if ognl > >> expression evaluation / property access would not swallow them. > > > > I feel it is overkill. The property getters in action classes may > > throw RuntimeException because of programming bugs. Even in this case, > > the current implementation just ignore the exception and the shown > > page will be just corrupted. We cannot show user friendly 'sorry page' > > because the Struts exception handler cannot get exception. > > > > You would not be able to use the most common use patterns without having > to do exepction handling on the JSP page then! Think of a model object > foo with a getter getFoo() in your a FooCrudAction. You have an > editFoo.jsp. If you want to create a new foo entry, the sequence would be > - invoke edit/create action, triggering execute() in FooCrudAction > - render editFoo.jsp > - submit form > - invoke save action, triggering save() in FooCrudAction > - on success, render editFoo.jsp > > if ognl would not swallow the exceptions, then placing simple tag like > > would fail with NPE in first rendering if you did not provide a > (unnecessary) this.foo=new Foo() in your execute() method, or a lazy > getter. Just a simple example. But if you would change this behaviour, > the showcase app code would need approximately an additional 10-15% more > code just for doing unneeded initializations and exception handling. You won't get NPE in this scenario. Ognl automatically create instance for you. I believe you know about this feature. > What if the execption is thrown? It will be thrown within JSP page > handling, and swallowed there! Your OpenSessionInView Interceptor or any > higher level layer would take no notice of the exception. Instead you > would have to use the anti-pattern of exception handliing with in JSP > code to present useful information. In the API specification for PageContext.handleException() states the following: --- If no error page is defined in the page, the exception should be rethrown so that the standard servlet error handling takes over. --- If my understanding is correct, the exception should be rethrown and the servlet layer can handle it. > >> Most likely, you are doing business logic calls in your model access > >> domain and you should think of moving any call with the possibility to get > >> service relevant exceptions to the described business logic domain access > >> methods. > > > > No, it is not 'business logc'. In 'open session in view' pattern, the > > db transaction is kept open until the view rendering finishies. If you > > call the property access method of the acction class, it calls the > > getter method of tne entity class. It triggers O/R mapping layer > > invocation and lazily accesses the database. As a result, some kind of > > system exception (such as SQLException) may be thrown while view > > rendering. > > > > This pattern is widely used, I'm using it myself in many applications. > But where do you expect the exception? If you make sure that you have a > foo object loaded from persistence layer, the the foo.getBars() call to > a a lazy initialized collection of referenced objects should never fail > due to _runtime_ problems you have to deal with. If, for example, for > some reason your session is closed, you have to look for a design time > problem - most commonly people forget about holding the session open > (luckily we have OpenSessionInView). Closing the session should be fixed as a design bug. I agree with you at this point. But in this case, the system should show an user friendly 'sorry page' so that the user can perform appropriate action. As we cannot take all bugs out of our system, need a sfety net. If there is a network problem between ap server and db server, lazy loading will fail by system error. > The best practice pattern for a displaying a foo object looks like this: > > - invoke showFoo.action?id=1 > - prepare() method of your action: this.foo = fooService.getById(this.id) > - handle any exception you like, or let it pop to the upper layers > - on success, render showFoo.jsp > - iterate over foo.bars in view - will be lazy initialized, but should > not throw any exception is your design was proper My previous example may be poor to explain this issue. Sorry for that. But as I stated above, you still need to care about system exception and RuntimeException (thrown by programming bug). I am not talking about application exception. You can hardly avoid system error and programming bug by implementing logics in your code. > but if there was an exception, and OGNL would pop it, you still would > _never_ get it in your Interceptor - your container will
Re: Exception thrown in OGNL evaluation.
Ruimo,
see below
Ruimo Uno schrieb:
Hi, thanks for your comment.
2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
It's no bug, it's a feature...
The policy for model access (e.g. property calls) via expression
evaluation is fail silent. It would cause tons of exceptions if ognl
expression evaluation / property access would not swallow them.
I feel it is overkill. The property getters in action classes may
throw RuntimeException because of programming bugs. Even in this case,
the current implementation just ignore the exception and the shown
page will be just corrupted. We cannot show user friendly 'sorry page'
because the Struts exception handler cannot get exception.
You would not be able to use the most common use patterns without having
to do exepction handling on the JSP page then! Think of a model object
foo with a getter getFoo() in your a FooCrudAction. You have an
editFoo.jsp. If you want to create a new foo entry, the sequence would be
- invoke edit/create action, triggering execute() in FooCrudAction
- render editFoo.jsp
- submit form
- invoke save action, triggering save() in FooCrudAction
- on success, render editFoo.jsp
if ognl would not swallow the exceptions, then placing simple tag like
would fail with NPE in first rendering if you did not provide a
(unnecessary) this.foo=new Foo() in your execute() method, or a lazy
getter. Just a simple example. But if you would change this behaviour,
the showcase app code would need approximately an additional 10-15% more
code just for doing unneeded initializations and exception handling.
What if the execption is thrown? It will be thrown within JSP page
handling, and swallowed there! Your OpenSessionInView Interceptor or any
higher level layer would take no notice of the exception. Instead you
would have to use the anti-pattern of exception handliing with in JSP
code to present useful information.
Most likely, you are doing business logic calls in your model access
domain and you should think of moving any call with the possibility to get
service relevant exceptions to the described business logic domain access
methods.
No, it is not 'business logc'. In 'open session in view' pattern, the
db transaction is kept open until the view rendering finishies. If you
call the property access method of the acction class, it calls the
getter method of tne entity class. It triggers O/R mapping layer
invocation and lazily accesses the database. As a result, some kind of
system exception (such as SQLException) may be thrown while view
rendering.
This pattern is widely used, I'm using it myself in many applications.
But where do you expect the exception? If you make sure that you have a
foo object loaded from persistence layer, the the foo.getBars() call to
a a lazy initialized collection of referenced objects should never fail
due to _runtime_ problems you have to deal with. If, for example, for
some reason your session is closed, you have to look for a design time
problem - most commonly people forget about holding the session open
(luckily we have OpenSessionInView).
The best practice pattern for a displaying a foo object looks like this:
- invoke showFoo.action?id=1
- prepare() method of your action: this.foo = fooService.getById(this.id)
- handle any exception you like, or let it pop to the upper layers
- on success, render showFoo.jsp
- iterate over foo.bars in view - will be lazy initialized, but should
not throw any exception is your design was proper
but if there was an exception, and OGNL would pop it, you still would
_never_ get it in your Interceptor - your container will swallow it when
rendering the JSP.
it's the same for saving etc as well.
Did you check out these?:
http://cwiki.apache.org/confluence/display/WW/CRUD+Demo+I
http://appfuse.org/display/APF/Demos+and+Videos
Regards,
Rene
Am Do, 16.08.2007, 17:01, schrieb Ruimo Uno:
Hi,
I have submitted this to user list a few hours ago but finally, I
found the root cause of this issue. So, here I report it to dev list.
If an exception is thrown while OGNL expression evaluation such as in
the following scenario:
XXXAction
public String getMessage() {
throw new NullPointerException();
}
XXX.jsp
The exception is wrapped in an OgnlException and re-thrown. It is
caught in com.opensymphony.xwork2.util.CompoundRootAccessor.getProperty()
and wrapped in a XWorkException() and re-thrown.
} catch (OgnlException e) {
if (e.getReason() != null) {
final String msg = "Caught an Ognl exception while getting
property " + name;
throw new XWorkException(msg, e);
}
} catch (IntrospectionException e) {
Finally, it is caught in
com.opensymphony.xwork2.util.OgnlValueStack.findValue(String, Class)
and swallowed.
} catch (Exception e) {
logLookupFailure(expr, e);
return findInContext(expr);
} finally {
As a result, the upper layer does not receive any exception. So
Re: Exception thrown in OGNL evaluation.
Hi, thanks for your comment.
2007/8/17, Rene Gielen <[EMAIL PROTECTED]>:
> It's no bug, it's a feature...
>
> The policy for model access (e.g. property calls) via expression
> evaluation is fail silent. It would cause tons of exceptions if ognl
> expression evaluation / property access would not swallow them.
I feel it is overkill. The property getters in action classes may
throw RuntimeException because of programming bugs. Even in this case,
the current implementation just ignore the exception and the shown
page will be just corrupted. We cannot show user friendly 'sorry page'
because the Struts exception handler cannot get exception.
> Most likely, you are doing business logic calls in your model access
> domain and you should think of moving any call with the possibility to get
> service relevant exceptions to the described business logic domain access
> methods.
No, it is not 'business logc'. In 'open session in view' pattern, the
db transaction is kept open until the view rendering finishies. If you
call the property access method of the acction class, it calls the
getter method of tne entity class. It triggers O/R mapping layer
invocation and lazily accesses the database. As a result, some kind of
system exception (such as SQLException) may be thrown while view
rendering.
> Am Do, 16.08.2007, 17:01, schrieb Ruimo Uno:
> > Hi,
> >
> > I have submitted this to user list a few hours ago but finally, I
> > found the root cause of this issue. So, here I report it to dev list.
> > If an exception is thrown while OGNL expression evaluation such as in
> > the following scenario:
> >
> > XXXAction
> > public String getMessage() {
> > throw new NullPointerException();
> > }
> >
> > XXX.jsp
> >
> >
> > The exception is wrapped in an OgnlException and re-thrown. It is
> > caught in com.opensymphony.xwork2.util.CompoundRootAccessor.getProperty()
> > and wrapped in a XWorkException() and re-thrown.
> >
> > } catch (OgnlException e) {
> > if (e.getReason() != null) {
> > final String msg = "Caught an Ognl exception while getting
> > property " + name;
> > throw new XWorkException(msg, e);
> > }
> > } catch (IntrospectionException e) {
> >
> > Finally, it is caught in
> > com.opensymphony.xwork2.util.OgnlValueStack.findValue(String, Class)
> > and swallowed.
> >
> > } catch (Exception e) {
> > logLookupFailure(expr, e);
> >
> > return findInContext(expr);
> > } finally {
> >
> > As a result, the upper layer does not receive any exception. So, no
> > exception handler is invoked even if it is registered. Moreover, in
> > 'open session in view' pattern, since the upper layer are not notified
> > any error, the transaction is wrongly committed and it causes serious
> > problem.
> >
> > I tried to add a catch clause for RuntimeException:
> >
> > } catch (RuntimeException e) {
> > logLookupFailure(expr, e);
> > throw e;
> > } catch (Exception e) {
> > logLookupFailure(expr, e);
> >
> > return findInContext(expr);
> > } finally {
> >
> > Yes, the exception is successfully thrown to the upper layer with this
> > code change. However, Struts shows 'java.io.IOException: Stream
> > closed:' on the browser. This message seems a bit confusing. and
> > difficult to realize what is actually happening (NPE is thrown). Does
> > anybody have better solution on this?
> >
> > Thanks,
> >
> > --
> > Ruimo Uno
> > (Shisei Hanai)
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Rene Gielen | http://it-neering.net/
> Aachen | PGP-ID: BECB785A
> Germany | gielen at it-neering.net
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Ruimo Uno
(Shisei Hanai)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception thrown in OGNL evaluation.
It's no bug, it's a feature...
The policy for model access (e.g. property calls) via expression
evaluation is fail silent. It would cause tons of exceptions if ognl
expression evaluation / property access would not swallow them.
The business logic access methods of your action, such as prepare(),
execute(), save(), delete()... _do_ pop any unhadled exception to the
upper layer, which is perfectly suitable for transaction handling.
Most likely, you are doing business logic calls in your model access
domain and you should think of moving any call with the possibility to get
service relevant exceptions to the described business logic domain access
methods.
Regards,
Rene
Am Do, 16.08.2007, 17:01, schrieb Ruimo Uno:
> Hi,
>
> I have submitted this to user list a few hours ago but finally, I
> found the root cause of this issue. So, here I report it to dev list.
> If an exception is thrown while OGNL expression evaluation such as in
> the following scenario:
>
> XXXAction
> public String getMessage() {
> throw new NullPointerException();
> }
>
> XXX.jsp
>
>
> The exception is wrapped in an OgnlException and re-thrown. It is
> caught in com.opensymphony.xwork2.util.CompoundRootAccessor.getProperty()
> and wrapped in a XWorkException() and re-thrown.
>
> } catch (OgnlException e) {
> if (e.getReason() != null) {
> final String msg = "Caught an Ognl exception while getting
> property " + name;
> throw new XWorkException(msg, e);
> }
> } catch (IntrospectionException e) {
>
> Finally, it is caught in
> com.opensymphony.xwork2.util.OgnlValueStack.findValue(String, Class)
> and swallowed.
>
> } catch (Exception e) {
> logLookupFailure(expr, e);
>
> return findInContext(expr);
> } finally {
>
> As a result, the upper layer does not receive any exception. So, no
> exception handler is invoked even if it is registered. Moreover, in
> 'open session in view' pattern, since the upper layer are not notified
> any error, the transaction is wrongly committed and it causes serious
> problem.
>
> I tried to add a catch clause for RuntimeException:
>
> } catch (RuntimeException e) {
> logLookupFailure(expr, e);
> throw e;
> } catch (Exception e) {
> logLookupFailure(expr, e);
>
> return findInContext(expr);
> } finally {
>
> Yes, the exception is successfully thrown to the upper layer with this
> code change. However, Struts shows 'java.io.IOException: Stream
> closed:' on the browser. This message seems a bit confusing. and
> difficult to realize what is actually happening (NPE is thrown). Does
> anybody have better solution on this?
>
> Thanks,
>
> --
> Ruimo Uno
> (Shisei Hanai)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Rene Gielen | http://it-neering.net/
Aachen | PGP-ID: BECB785A
Germany | gielen at it-neering.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Exception thrown in OGNL evaluation.
Hi,
I have submitted this to user list a few hours ago but finally, I
found the root cause of this issue. So, here I report it to dev list.
If an exception is thrown while OGNL expression evaluation such as in
the following scenario:
XXXAction
public String getMessage() {
throw new NullPointerException();
}
XXX.jsp
The exception is wrapped in an OgnlException and re-thrown. It is
caught in com.opensymphony.xwork2.util.CompoundRootAccessor.getProperty()
and wrapped in a XWorkException() and re-thrown.
} catch (OgnlException e) {
if (e.getReason() != null) {
final String msg = "Caught an Ognl exception while getting
property " + name;
throw new XWorkException(msg, e);
}
} catch (IntrospectionException e) {
Finally, it is caught in
com.opensymphony.xwork2.util.OgnlValueStack.findValue(String, Class)
and swallowed.
} catch (Exception e) {
logLookupFailure(expr, e);
return findInContext(expr);
} finally {
As a result, the upper layer does not receive any exception. So, no
exception handler is invoked even if it is registered. Moreover, in
'open session in view' pattern, since the upper layer are not notified
any error, the transaction is wrongly committed and it causes serious
problem.
I tried to add a catch clause for RuntimeException:
} catch (RuntimeException e) {
logLookupFailure(expr, e);
throw e;
} catch (Exception e) {
logLookupFailure(expr, e);
return findInContext(expr);
} finally {
Yes, the exception is successfully thrown to the upper layer with this
code change. However, Struts shows 'java.io.IOException: Stream
closed:' on the browser. This message seems a bit confusing. and
difficult to realize what is actually happening (NPE is thrown). Does
anybody have better solution on this?
Thanks,
--
Ruimo Uno
(Shisei Hanai)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
