Shalom Rivka, > -----Ursprüngliche Nachricht----- > Von: Rivka Shisman [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 20. Juli 2005 18:50 > An: Struts Users Mailing List; Ed Griebel > Betreff: RE: ApplicationException sample > > > Hi Ed > > I don't have a delegate layer because I see no point in > duplicating my EJB interface (actually my business interface) > by creating a delegate layer. Another layer is time consuming > in development and in maintainance - it seems too much for > just wrapping exceptions.
Heh, you are using EJB and complaining about time consuming layers? :-) A delegate layer will probably cost 10% of the time you need to EJBize your business logic (the more effort of writing ejbs instead of POJOs). It will probably save you enough days in one year, when you refactor your application to remove ejb dependencies, so you can get a week more off :-) The ultimate solution would be to use/write a generator, which generates you an abstraction layer on top of ejb from java interfaces or xml. If you decide to get rid of the ejbs, simply change the generator to generate whatever you want, and be fine :-) Regards Leon > > You wrote: > >A quick and dirty fix to your problem would be to declare > the execute() > >method in your action to also throw a RemoteException > > There no need for that - RemoteException is a subclass of > Exception and decleratively adding it to the > <global-exceptions> section works fine (no need to change the > methods signature). > > Thanks > Rivka > > -----Original Message----- > From: Ed Griebel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 20, 2005 3:19 PM > To: Struts Users Mailing List > Subject: Re: ApplicationException sample > > Rivka- > > Since you're developing from scratch, you might want to put a > layer in-between your EJBs and Struts. Some will call it > business logic, data access object (DAO), or Helper classes. > This allows you to separate the struts-related concerns from > business-related concerns. > It also solves the issue you mentioned about where to catch > RemoteExceptions. Also, these helper classes can be used in > more than one action which could be a benefit. > > A quick and dirty fix to your problem would be to declare the > execute() method in your action to also throw a > RemoteException, and then declaratively handle the exception > in your Struts config inside <global-exceptions>. I'd only > use this if there's no way for you to recover the transaction > when a remoteException occurs. It's an old article, but take > a look at > http://www.onjava.com/pub/a/onjava/2002/10/30/jakarta.html. > These sites are good for starting out in struts too: > http://husted.com/struts/ and http://www.reumann.net/struts/main.do > > Good luck, > -ed > > On 7/20/05, Rivka Shisman <[EMAIL PROTECTED]> wrote: > > > > Erik, Glen, Laurie - Thanks for your help > > > > After doing some more homework about exception handling - I have > another > > question: > > > > If my Sturts Action calls directly to EJB methods (with no delegate > > Layer) - then I have to catch RemoteException for all runtime > > exceptions? Or is there a better way to work? > > > > Thanks > > Rivka > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ************************************************************** > ************************************ > The contents of this email and any attachments are confidential. > They are intended for the named recipient(s) only. > If you have received this email in error please notify the > system manager or the sender immediately and do not disclose > the contents to anyone or make copies. > > ** eSafe scanned this email for viruses, vandals and > malicious content. ** > ************************************************************** > ************************************ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
