Basic Applets Theory : Applets are two types of varieties and they important role in the java and it contain the basic class nothing but Applet class which provides foundation for applets.The applet class contained in the java.applet package.Later java.applet also defines three interfaces.
Following Interfaces:
Following Interfaces:
- AppletContext
- AudioClip
- AppletStub Now let us discuss about the applets already we noticed there are two types and we will discuss them below
- AWT(Abstract window toolkit): It is used to provide the graphical user interface i.e(GUI) and this type of applet has been available since java was first created.
- Swing class JApplet: Swing applets use the Swing classs to provide the GUI.Swing offers a richer and often easier-to-use user interface than does the AWT.
- JApplet inherits Applet,all the features of applet are also available in JApplet,and most of the information applies to both the applets.
- Under the EJB 3.0 API, the business interface of an enterprise bean is a plain Java interface, not an
- EJBObject or EJBLocalObject interface. [2]
- Session beans and message-driven beans require a business interface. The business interface of a message-driven bean is typically defined by the messaging type used (e.g., javax.jms.MessageListener in the case of JMS). Business interfaces in the sense of this chapter are not defined for entity
- beans.
- The bean class may implement its business interface(s).[3] A bean class may have more than one business interface. The following rules apply:
- If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or
- interface or by means of the deployment descriptor.
- A bean class is permitted to have more than one interface. If a bean class has more than one
- interface—excluding the interfaces listed below—any business interface of the bean class must
- be explicitly designated as a business interface of the bean by means of the Local or Remote
- annotation on the bean class or interface or by means of the deployment descriptor.
- The following interfaces are excluded when determining whether the bean class has more than
- one interface: java.io.Serializable; java.io.Externalizable; any of the
- interfaces defined by the javax.ejb package.
- The same business interface cannot be both a local and a remote business interface of the
- bean.[4]
- [2] Usage of the earlier EJBObject and EJBLocalObject interface types continues to be supported under EJB 3.0.
- The same InvocationContext instance is passed to each interceptor method for a given business
- method interception or lifecycle event. This allows an interceptor to save information in the context data
- property of the InvocationContext that can be subsequently retrieved in other interceptors as a
- means to pass contextual data between interceptors. The contextual data is not shareable across business
- method invocations or lifecycle event callbacks. If interceptors are invoked as a result of the invocation
- on a web service endpoint, the map returned by getContextData will be the JAX-WS MessageContext [13]. The lifecycle of the InvocationContext instance is otherwise unspecified.
- The getTarget method returns the bean instance that is the target of the invocation. The getMethod method returns the method of the bean class for which the interceptor was invoked. For
- AroundInvoke methods, this is the business method on the bean class; for lifecycle callback interceptor methods, getMethod returns null. The getParameters method returns the parameters of
- the business method invocation. If setParameters has been called, getParameters returns the
- values to which the parameters have been set. The setParameters method modifies the parameters
- used for the business method invocation. Modifying the parameter values does not affect the determination of the business method that is invoked on the bean class. The parameter types must match the types
- for the business method, or the IllegalArgumentException is thrown.
- The proceed method causes the invocation of the next interceptor method in the chain, or, when
- called from the last AroundInvoke interceptor method, the business method. The proceed method
- returns the result of that method invocation. If the business method returns void, proceed returns
- null. For lifecycle callback interceptor methods, if there is no callback method defined on the bean
- class, the invocation of proceed in the last interceptor method in the chain is a no-op, and null is
No comments:
Post a Comment