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]
