hammant 02/01/01 15:25:56 Modified: armi PROPOSAL Log: Event API and connection recovery Revision Changes Path 1.5 +14 -2 jakarta-commons-sandbox/armi/PROPOSAL Index: PROPOSAL =================================================================== RCS file: /home/cvs/jakarta-commons-sandbox/armi/PROPOSAL,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- PROPOSAL 31 Dec 2001 13:13:13 -0000 1.4 +++ PROPOSAL 1 Jan 2002 23:25:56 -0000 1.5 @@ -35,7 +35,8 @@ 4) Interface/Impl separated design. - ARMI can be build easily into any application or application framework. - Individual aspects can be reimplemented (overridden) as the need arises. + Individual aspects can be reimplemented (or overridden) as the need + arises. 5) Choice of location of generated Proxy class. @@ -51,6 +52,17 @@ trys the requets again. A server could cycle through suspended and back to resumed will not affect the client except for the a delay. +7) Recovering transport + + - ARMI tries to recover its transports should they fail. + +8) Event API + + - For suspensions, abnormal ends of connection etc, there is a listener + that can be set that will allow actions to be taken. Abnormally + terminated connections will by default try to be reconnected, the + listener can decide if, how many, and how often the retries occur. + Limitations: 1) Pass by value only. @@ -59,7 +71,7 @@ an argument or return type were another ARMI published service, then it could not currently be handled by ARMI. (to fix). -2) Uee in EJB +2) Use in EJB - This is not of any use for EJB Home/Remote interfaces. The container maker chooses the transport for use that container, not the bean coder.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>