I have following questions, could somebody help me? 1.The spec says to always narrow when get remote homeinterface, beacause you might get back an IIOP stub that do not implement homeinterace.my question is why the IIOP stub that do not implement homeinterace, this maybe a question about IIOP 2.You can declare your own application exception in component interface, but they must NOT be runtime exception. this is rule of bean law, but I want to know stuff(why we can not declare runtime exception in component interface.Have more deep reason?) At least in java law declaring a runtime exception in interface is legal.
Sun(java)-SCJA SCJP SCWCD SCBCD SCDJWS SCEA<br />Sun(solaris)-SCSA SCSN<br />IBM-486 Object-Oriented Analysis and Design with UML Test <br />IBM Certified System Administrator - WebSphere Application Server Network Deployment V6.0<br />Oracle-OCA
Yes, it really is a question about IIOP. To the best of my knowledge though: IIOP will actually download and give you a separate (distinct) stub when you do the PortableRemoteObject.narrow invocation. Basically, who knows what IIOP will do. If you're using EJB over JRMP or whatever the regular Java way is, then technically you don't have to narrow anything and you <<could>> just cast the result of your JNDI lookup, but be nice and proper and narrow it anyways. As for the exceptions question, in the EJB spec, a RemoteException is considered an runtime exception (since it denotes an unexpected result). You can throw any RuntimeException-derived exception you want, and you don't have any need to declare it. What you cannot do is declare that a RemoteException-derived exception be thrown from any of your component interface methods. For the regular RuntimeException go ahead and throw them wherever the heck you want -- the container will handle them exactly like all the other ones that are thrown - either wrapping them in an EJBException or a RemoteException depending on who's calling.
2.You can declare your own application exception in component interface, but they must NOT be runtime exception. this is rule of bean law, but I want to know stuff(why we can not declare runtime exception in component interface.Have more deep reason?) At least in java law declaring a runtime exception in interface is legal.
One of the constraints on anybody working on a spec is that when you add up all the various sections, the meaning of the spec should be consistent. In other words, you can't have one part of the spec that says "A must be true" and another part that says "A must be false" and have both parts be feasible at the same time. (At least) one part of the EJB spec talks about how transactions are handled. That part says RuntimeException = rollback, ApplicationException = no rollback. If another part of the spec said 'business methods can have application exceptions declared, and application exceptions can be runtime exceptions" then both the container vendor and the bean developer would be in trouble. The container vendor wouldn't know how they should treat transaction rollbacks on a "runtime application exception". They'd be wandering around like geeky Hamlets chanting "to rollback, or not to rollback, that is the question". On the other hand, bean developers trying to support multiple containers wouldn't know when one container would cause a rollback and another wouldn't. They'd be wandering around grousing "a consistent rule, a consistent rule, my kingdom for a consistent rule". [Ok, Willy is rolling in his grave... so shoot me ]
Reid - SCJP2 (April 2002)
What are you doing? You are supposed to be reading this tiny ad!