You can specify the options to a LinkedHashMap so the list will be presented as the same order as creation.
You need to set attributes of the Form Bean if the value of the drop-down list is associated with the Form Bean. Or the default value such as 0 for int will be inserted into the list.
Monday, December 11, 2006
Thursday, December 07, 2006
JAXP Introduction
JAXP is very adaptable. It essentially functions as an abstraction layer between your code and different vendors' XML processor implementations.
It allows you to plug in different DOM and SAX parsers, and XSLT (Extensible Stylesheet Language Transformation) transformers, as you require without needing to change your code. This is known as a pluggablility layer. The processor can be set by changing the appropriate environment variable. Attention, it doesn't mean you can swap between DOM and SAX.
JAXP also comes with its own default parsers that implement SAX and DOM functionality.
Simple API for XML (SAX) is an API for event-based parsing of XML documents. This means a SAX parser reads the XML document from beginning to end using a data stream. Any time it encounters a new element, it throws an event to notify the application running it. The application can then handle these events as required.
SAX comes with a number of methods that you can use to recognize an event. You then respond to these events by either implementing a specific interface or extending the default handler and overriding the appropriate method. SAX does not allow you to modify the XML document, it can only read it.
The Document Object Model (DOM) API is a World Wide Web Consortium (W3C) specification for parsing XML. It builds a representation of an XML document in memory in a tree structure. You can navigate this tree to search for elements, which correspond to branches. You can also insert new elements into the tree and remove elements.
When deciding which type of parser to use you should bear in mind your needs. The SAX API is fast, as it examines the XML serially. The DOM API is much more memory-intensive and CPU-intensive, as it must load the whole document. However, the DOM API allows you to modify the XML structure and has greater flexibility. You should choose the API that provides the best tradeoff between your requirements and the limitations of your system.
JAXP also supports XSLT, a language used for transforming XML documents into other documents using stylesheets. For example, using XSLT, you could transform an XML document into HTML, or you could make an XML document based on one schema conform to another schema.
It allows you to plug in different DOM and SAX parsers, and XSLT (Extensible Stylesheet Language Transformation) transformers, as you require without needing to change your code. This is known as a pluggablility layer. The processor can be set by changing the appropriate environment variable. Attention, it doesn't mean you can swap between DOM and SAX.
JAXP also comes with its own default parsers that implement SAX and DOM functionality.
Simple API for XML (SAX) is an API for event-based parsing of XML documents. This means a SAX parser reads the XML document from beginning to end using a data stream. Any time it encounters a new element, it throws an event to notify the application running it. The application can then handle these events as required.
SAX comes with a number of methods that you can use to recognize an event. You then respond to these events by either implementing a specific interface or extending the default handler and overriding the appropriate method. SAX does not allow you to modify the XML document, it can only read it.
The Document Object Model (DOM) API is a World Wide Web Consortium (W3C) specification for parsing XML. It builds a representation of an XML document in memory in a tree structure. You can navigate this tree to search for elements, which correspond to branches. You can also insert new elements into the tree and remove elements.
When deciding which type of parser to use you should bear in mind your needs. The SAX API is fast, as it examines the XML serially. The DOM API is much more memory-intensive and CPU-intensive, as it must load the whole document. However, the DOM API allows you to modify the XML structure and has greater flexibility. You should choose the API that provides the best tradeoff between your requirements and the limitations of your system.
JAXP also supports XSLT, a language used for transforming XML documents into other documents using stylesheets. For example, using XSLT, you could transform an XML document into HTML, or you could make an XML document based on one schema conform to another schema.
Tuesday, December 05, 2006
Servlet and Web Service
When creating a servlet to act as an RPC-router for a web service, you must ensure that it performs all the necessary tasks. These include
- parsing the SOAP envelope
- validating the message format and the XML
- converting any necessary data to Java specific data types
- extracting all the necessary method call information from the SOAP message and calling the other components for the J2EE system correctly using this information.
Java API for XML
- JAXP is the Java API for XML processing. It allows you to process and transform XML documents using DOM(Document Object Mode), SAX(Simple API for XML), and XSLT(eXtensible Stylesheet Language Transformations). It also allows you to switch between implementations of these standards - for example, from one DOM parser to another - without needing to alter the code.
- JAXB stands for the Java Architecture for XML Binding. It provides a mechanism for mapping between XML elements and Java objects. It compiles your XML schema into Java classes. These generated classes can then handle and parse any XML data as well as checking that al the XML you use is compliant with your requirements. It is an alternative way of processing XML to that provided by the JAXP API.
- SAAJ is the SOAP with Attachments API for Java. It is the basic package for SOAP messaging and allows you to create and populate a SOAP message.
- JAX-RPC is the Java API for XML-based remote procedure calls. It enables you to build SOAP-based applications with RPC functionality in which the method calls are encapsulated in the SOAP messages.
- JAXM is the Java API for XML Messaging. It enables applications to send and receive document-based XML messages. It implements the SOAP 1.1 standard to allow you to focus on sending the SOAP messages rather than creating low-level XML routines. It also facilitates asynchronous communications between web services.
- JAXR is the Java API for XML Registries. It allows you to access different XML registries. Among the registries it allows you to access are those based on the UDDI and ebXML(Electronic Business XML) specifications.
Monday, December 04, 2006
Entity Bean and Exception
The exception thrown by entity beans are divided into two categories. The first is a system exception, such as SQLException, which alerts the container that there is problem with services that suport an application, therefore requiring the services of a system administrator to fix the problem. The other type of exception is an application exception, which alerts the container to an error in the business processes of a bean. Application exceptions are further divided into customized and predefined exceptions. A customized exception is an exception you have created specifically for your application.
A predefined exception is alreay part of a Java package and is provided to deal with common problems that arise within EJBs, for example, the CreateException.
A predefined exception is alreay part of a Java package and is provided to deal with common problems that arise within EJBs, for example, the CreateException.
Friday, December 01, 2006
Life Cycle of Entity Bean
There are three states in the life cycle of the entity bean, Does Not Exist, Pooled, and Ready.
When the bean is in the Does Not Exist state, no instance of the bean has been instantiated yet.
In the pooled state, several instances of the bean's implementation class are instantiated but are not associated with any EJBObject. All the bean instances in the pool are the same and are not associated with any database data or actively dealing with any client request.
Once the bean is instantiated, a reference to its javax.ejb.EntityContext is passed to it by the container using the bean's setEntityContext method.
Once the EntityContext is associated witht the bean, it can be placed in the pool. When the EJB server starts up, it will maintain a separate instance pool for each type of bean deployed by placing a number of bean instances in this pooled state.
Beans in the pooled state can be used to service ejbFindxxx requests, as these methods don't rely on the bean instance's state.
When a client requests a bean, the container creates an EJBObject for that bean, and it assigns a bean instance from any of the instances in the relevant instance pool to the EJBObject, using the appropriate data to initialize the bean.
This is done using the ejbCreate or ejbActivate method.
When a bean instance is assigned to an EJBObject, it moves to the ready state. In this state, the bean instance is associated with data and actively deals with client requests.
The bean instance can also use its EntityContext to receive information about the client that is using the instance and to receive callback methods from the container.
Initialized entity bean instances correspond to actual entries in a database, so, in the ready state, a bean instance can access a row of data from a database.
The ejbLoad and ejbStore callback methods, which the container uses to synchronize the bean's state with the database, can be called only when the bean is in the ready state.
Entity beans can move from the pooled state to the ready state in these circumstances,
To deal with this, the EJB container can passivate the bean - that is, return the bean to the pooled state - when it's not in use. It does this by invoking the ejbPassivate method.
And if a bean instance is required again, any one of the equivalent bean instances in the pooled state can be reassigned to the EJB object.
After the client request is completed with a bean instance, the bean instance can be removed and returned to the pooled state.
When the client signals that it wants to remove a bean, the container calls the ejbRemove method on the bean instance.
The life cycle of an entity bean ends when the bean instance is removed from the pool by the container to be destroyed.
If a bean is to be released, the unsetEntityContext method is called by the container to warn the bean instance that is about to be destroyed. This allows the bean instance to discharge any data it maintains before being destroyed.
When the bean is in the Does Not Exist state, no instance of the bean has been instantiated yet.
In the pooled state, several instances of the bean's implementation class are instantiated but are not associated with any EJBObject. All the bean instances in the pool are the same and are not associated with any database data or actively dealing with any client request.
Once the bean is instantiated, a reference to its javax.ejb.EntityContext is passed to it by the container using the bean's setEntityContext method.
Once the EntityContext is associated witht the bean, it can be placed in the pool. When the EJB server starts up, it will maintain a separate instance pool for each type of bean deployed by placing a number of bean instances in this pooled state.
Beans in the pooled state can be used to service ejbFindxxx requests, as these methods don't rely on the bean instance's state.
When a client requests a bean, the container creates an EJBObject for that bean, and it assigns a bean instance from any of the instances in the relevant instance pool to the EJBObject, using the appropriate data to initialize the bean.
This is done using the ejbCreate or ejbActivate method.
When a bean instance is assigned to an EJBObject, it moves to the ready state. In this state, the bean instance is associated with data and actively deals with client requests.
The bean instance can also use its EntityContext to receive information about the client that is using the instance and to receive callback methods from the container.
Initialized entity bean instances correspond to actual entries in a database, so, in the ready state, a bean instance can access a row of data from a database.
The ejbLoad and ejbStore callback methods, which the container uses to synchronize the bean's state with the database, can be called only when the bean is in the ready state.
Entity beans can move from the pooled state to the ready state in these circumstances,
- when a new entity bean instance is created using the ejbCreate method
- when the container activates a bean in response to a query using the ejbActivate method
- when the container uses ejbActivate to activate a bean that has previously been passivated.
To deal with this, the EJB container can passivate the bean - that is, return the bean to the pooled state - when it's not in use. It does this by invoking the ejbPassivate method.
And if a bean instance is required again, any one of the equivalent bean instances in the pooled state can be reassigned to the EJB object.
After the client request is completed with a bean instance, the bean instance can be removed and returned to the pooled state.
When the client signals that it wants to remove a bean, the container calls the ejbRemove method on the bean instance.
The life cycle of an entity bean ends when the bean instance is removed from the pool by the container to be destroyed.
If a bean is to be released, the unsetEntityContext method is called by the container to warn the bean instance that is about to be destroyed. This allows the bean instance to discharge any data it maintains before being destroyed.
Entity Bean and Transaction
Enterprise bean transactions can be bean managed or container managed, but entity beans can only use container-managed transactions.
In this case, the container manages the bean's transactions and is informed by the bean provider how the bean participates in a transaction. When a bean is transactional. it can be shared between multiple clients.
Session beans can be uniquely identified by an ID generated by the container. But such IDs are not enough for entity beans, since they are associated with data in a database.
Therefore, entity beans make use of the primary key class that uniquely identify the data in the database that the entity bean is associated with. So the primary key uniquely identifies both the entity bean and the underlying data in the database.
In this case, the container manages the bean's transactions and is informed by the bean provider how the bean participates in a transaction. When a bean is transactional. it can be shared between multiple clients.
Session beans can be uniquely identified by an ID generated by the container. But such IDs are not enough for entity beans, since they are associated with data in a database.
Therefore, entity beans make use of the primary key class that uniquely identify the data in the database that the entity bean is associated with. So the primary key uniquely identifies both the entity bean and the underlying data in the database.
Subscribe to:
Posts (Atom)