In many cases you might want to group the soa composites so that it is easy to identify the required composite.
The best way to do this is to create a new partition and deploy the related soa composites to this partiton.

By default , if you don't speciy the partition name, all the composites are deployed to the "default" partition.

This blog shows how to create a new partition using the oracle fusion middleware enterprise manager console.

1.  Log into the em console
2.  Expand the SOA node  on the Left hand side navigation pane.
3.  Select the "soa-infra (server name)" node .
4.  On the Righthand side select the "soa-infrastructure"  related menu and select the menu "Manage Partitions"
5.  Now Create a new partition using the "create" icon.

EJB's and Exceptions
From an EJB method, if any unchecked excpetion is thrown, then it will be encapsulated in EJBException object...All checked exceptions are propagated without getting encapsulated by any other exception..

This is true for both Stateful and Stateless EJB's

Session Beans  and Exceptions
Whenever an EJB method throws any uncheked exception, then the container invalidates the EJB instance...During this process the container does'nt call the lifecycle listener method marked with PreDestroy...
When a checked exception is thrown, then the EJB instance is not invalidated...

When we say invalidated, it can mean many things..Its exactly implementation depends on the Application Server...However, the main thing to know is that, all further EJB method calls will be dealt by a different EJB instance...Some servers, might destroy the EJB completely...while some servers, return the instance to the EJB instance pool...

For Stateful Bean also when an Unchecked exception is thrown, the EJB Bean is completely destroyed...So we cannot call any other methods of the stateful EJB bean once an Uncheked exception is thrown (In case of stateful EJB, we can continue calling EJB methods, as a new EJB instance will be assigned for each method invocation)...For Checked exception, there is no problem...just like in stateless EJB..

@PreDestroy lifecycle callback method

The @PreDestroy method may not be called in all situations...When a Bean (stateful or stateless) is invalidated  then the method marked with the annotation "PreDestroy" does'nt get called...When the session bean timesout, the server may not call this lifecycle method (You have to contact the server doc for this)..

When a stateful bean has a method that is marked with the @Remove annotation and when the client calls this method, then the method marked with the annotation @PreDestroy will be called...

NOTE: When a method is marked with @Remove and @PreDestroy, then the method will be called twice when a client invokes the method once...

An example of how to use resource-ref tag is provided at the following location..


http://onjava.com/pub/a/onjava/excerpt/jsvltjspckbk_chap01/index.html?page=2

An example of how to use resource-env-ref tag in the DD is provided at the following location...

http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html

A servlet may need to know which MIME type a file extension corresponds to , and such a mapping needs to be specified as follows..

<mime-mapping>
       <extension>txt</extension>
        <mime-type>text/html</mime-type>
</mime-mapping>

In the service/doGet/doPost methods, use the following code to determine the mimetype of the file

String mimeType=this.getServletContext().getMimeType("pathOfTheFile.txt");
response.setContentType(mimeType);

EL expressions handle null values gracefully in some cases...The following are the cases..

• If the EL expression is of the following form ${attribute.xxxxxx} or ${bean.xxxx} and if the "attribute" or "bean"  is not present in any of the scopes
• If the EL expression is of the following form ${map.key.xxxx} and if the key is not present in the map
• If the EL expression is of the following form ${list_or_array[index]} and even if the index value is out of bounds..

EL expressions throws error in the following cases..

• If the EL expresseion is of the following form ${bean.property} or ${bean["property"]} and if the "property" is not present in the bean.
  

The following document talks about the diferrent ways in which you can validate an XML file using XSD in your application.

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXPDOM8.html

If you want to understand the concepts of XML namespaces, you need to ask few questions as follows...and get answers for them

• What are namespaces
  
• Why are namespaces used
• When are namespaces used
• What is the connection between XML, XML namespace and XSD/DTD

So let me give my answers for the above questions..

What are namespaces and what do they provide?

XML namespace is a way to group elemens of an XML file, inorder to avoid element naming conflicts...
XML namespace allows the XML parsers to process elements differently even if the elements have the same name.

Why does a parser has to process elements differently when the element names are same?

To answer this question...i have to take an example..

Assume that you have a XML file with the following content...

<organization>
           <projectlead>
                      <employeeid>123</employeeid>
           </projectlead>
</organization>

Assume that you have a parser (a java program)which can read the above XML file and lists out the Employee ID's..What the parser does is, gets all the "EmployeeID" elements in the XML file and then prints the value of the text node child element.

Now after sometime, someone comes and changes the XML file as follows..assuming that the java parser which is already present, will not list the EmployeeId of the "MYProjLead" element...

<organization>
           <projectlead>
                      <employeeid>123</employeeid>
         </projectlead>

           <myprojlead>
                     <employeeid>1233</employeeid>
           </myprojlead>
</organization>


But the parser lists out even the value of the EmployeeID  element present under "MYProjLead"...But this is not what is required...We want the parser to process only the "EmployeeID" elements present in the "ProjectLead"...
This is an example where the parser has to process the same Element  differently as they are present in different context...

This context can be specified explicitly using the XML namespace...So once we specify in which context an XML element is present, parsers can process elements differently based on the context (XML Namespace)...

So How do we specify the context ?

In XML we specify the context using a namespace as follows.

<organization>
           <projectlead xmlns="http://projectLeaderContext">
                      <employeeid>123</employeeid>
         </projectlead>

           <myprojlead xmlns="http://someCustomProjectLeaderContext">
                     <employeeid>1233</employeeid>
           </myprojlead>
</organization>

The context (actually the namespace) is specified using the "xmlns" attribute..