Wednesday Oct 28, 2015

Multi-tenancy Deployment


One of the key features in WLS 12.2.1 is the multi-tenancy support where a single WLS domain can contain multiple partitions which can be used by multiple tenants. The two main use cases that are supported are the SaaS use case and the consolidation use case.  In the SaaS use case, different partitions share a common set of applications and resources which are typically defined in a resource group template, and partitions reference the resource group template through their resource groups.

In the following example, application foo is defined in resource group template rgt1, and partition p1 and p2 reference the resource group template rgt1 through their resource groups rg1 and rg2.


In the consolidation use case, different partitions have their own set of the applications and resources which are defined at partition resource group level. In the following example, application bar is defined in the resource group rg3 of partition p3.


You can learn more about the concepts of partition, resource group and resource group template in Tim Quinn's blog: Domain Partitions for Multi-tenancy in WebLogic Server which provides a nice overview of the multi-tenancy feature.

The WLS deployment support has been enhanced to support the two use cases: supporting deployment of applications and resources to the resource group template for SaaS use case; and supporting deployment of applications and resources to the resource group for consolidation use case. One difference between the multi-tenancy deployment and the classic deployment (deploy to domain) that's worth noting is the different targeting model. In classic deployment, a user specifies targets explicitly for deployment operations using the targets option. In multi-tenancy deployment, a user is not allowed to specify targets, instead the targets that are associated with the specified resource group/partition will be used. You can learn more about the multi-tenancy targeting in Joe Dipol's blog: Partition Targeting and Virtual Targets in WebLogic Server 12.2.1.

Deploy to Resource Group Template

For performing deployment operation to a resource group template, a new deployment option called resource group template is introduced to specify the resource group template name. All of the existing deployment clients (weblogic.Deployer, WLST, JSR-88, JMX Deploy API etc) are supported for deployment operations to a resource group template. And the deployment operations distribute, deploy, undeploy, redeploy and update operations are supported for a resource group template. The start and stop operations are not supported for resource group template as the applications and resources are only instantiated in runtime at resource group level.

Below are some examples for performing deployment operations to a resource group template.

1. Deploy an application to a resource group template using weblogic.Deployer

java weblogic.Deployer -deploy -name foo -resourceGroupTemplate  rgt1 /usr/apps/foo.ear

2. Undeploy an application from resource group template using WLST

undeploy(appName="foo", resourceGroupTemplate="rgt1")

When a deployment operation is done to a resource group template, it has live effect on its referencing resource groups. For example, a deploy operation to the resource group template rgt1 will trigger the deployment of the application foo to the referencing partitions p1 and p2 in the earlier example.

Only a WLS system administrator can perform deployment operations to a resource group template.

When different partitions share a common set of applications and resources, often times a partition needs to customize the applications and resources for its partition. The customization of application for a partition is built on top of the existing application deployment plan feature. An application deployment plan for an application can specified for a particular partition. The resource customization are done through the resource deployment plan which is a new feature introduced in this release and talked in Tim Quinn's blog.

The following is an example of customizing application foo for partition p1 in the earlier example (use update command for dynamic changes and redeploy command for non-dynamic changes):

java weblogic.Deployer -update -name foo -plan /usr/apps/foo/plan.xml -partition p1

java weblogic.Deployer -redeploy -name foo -plan /usr/apps/foo/plan.xml -partition p1

Deploy to Resource Group

For performing deployment operations to a resource group, a new deployment option called resource group is introduced to specify the resource group name, and a new deployment option called partition is introduced to specify the partition name.  All of the existing deployment clients (weblogic.Deployer, WLST, JSR-88, JMX Deploy API etc) are supported for deployment operations to a resource group. And all of the deployment operations including start and stop (distribute, deploy, undeploy, redeploy, update, start, stop) are supported for a resource group.

Both WLS system administrator and partition administrator can perform deployment operations to partition resource group. A WLS system administrator can perform deployment operations to any partitions within the current domain when specifying the partition name. A partition administrator can only perform deployment operations to its own partition. The partition name is optional for a partition administrator as it can be derived from the partition URL which the partition administrator connects with.

The following examples show how to perform deployment operations to a resource group as WLS system administrator and partition administrator using WLST.

1. Deploy an application to partition level resource group as a system administrator:

connect('system', 'gumby1234', 't3://localhost:7001')

deploy(appName=‘bar',resourceGroup=‘rg3', partition='p3', path='/usr/apps/bar.ear')

2. Deploy application to partition level resource group as a partition administrator:


deploy(appName=‘bar',resourceGroup=‘rg3', path='/usr/apps/bar.ear')

A resource group can be defined at domain level also. Same set of deployment clients and deployment operations are supported for the domain level resource group as the partition level resource group. Domain level resource groups and domain share the same deployment scope, the global scope. Applications and resources need to be unique within a deployment scope (within a particular partition, or within the global scope).


Libraries can be deployed to resource group template and resource group just as applications and resources. Libraries are only visible to applications and resources deployed in the same deployment scope. For example, libraries deployed to a partition are only visible to applications and resources deployed to the same partition, and libraries deployed to the global scope (domain or domain level resource group) are only visible to applications and resources deployed to the global scope.

Monday Feb 28, 2011

GlassFish 3.1 and deployment

Glassfish 3.1 and deployment The GlassFish 3.1 is released today! The most important feature of this release is the clustering capability (which provides the feature parity with Glassfish v2.1)! This will allow user to use Glassfish in an enterprise environment.

Let's look at the main features provided in this release from the deployment area:

As part of overall clustering feature, user can now dynamically deploy an application to a cluster, undeploy an application from a cluster, and enable or disable an application on a cluster target. In v3, only the DAS (default server instance) target was supported.

The existing v3 set of the commands are now supported/extended in the clustering environment: create-lifecycle-module, delete-lifecycle-module, list-lifecycle-modules, deploy, undeploy, enable, disable, deploydir, redeploy, list-components, show-component-status, list-applications. And the new commands which are specific to the clustering environment are added on top of the existing set of v3 commands: create-application-ref, delete-application-ref, list-application-refs.

You can take a look at this for a simple example of how to work with the cluster target.

One enhancement we have in 3.1 over 2.1 is now we also support directory deployment with a cluster target provided the application bits are accessible by the target instances.

The next feature I want to talk about is the application versioning feature. This feature is developer by the external contributor Serli.

With the application versioning feature, the user will be able to deploy multiple versions of the application to the Glassfish. And the user can easily upgrade or rollback to one version of the application using the basic set of the commands (deploy/enable/disable). Currently only one version of the application can be enabled at one time in the runtime.

You can view this screencast to see how this feature is working.

We also enhanced the application rolling upgrade by taking advantage of the application versioning feature. With the enhancement, no cluster instance restart is needed and the dynamic reconfiguration can be left on (no need to turn it off and then on).

In this release, we also provided partial support for the WebLogic deployment descriptors (mainly in the web area). This will allow user to develop web applications with simple WebLogic extensions on Glassfish and then run on WebLogic.

The final thing I want to mention is the new names of the vendor specific deployment descriptors. In the past, we use "sun-" as the prefix for the vendor specific deployment descriptors (and dtds), for example, sun-web.xml, sun-web-app_3_0-0.dtd. From this release,  we will start to use "glassfish-" as the prefix for the vendor specific deployment descriptors (and dtds), for example, glassfish-web.xml, glassfish-web-app_3_0-1.dtd. The old sun-\* deployment descriptors (dtds) are still supported for backward compability, but if you want to use new elements introduced in the most recent dtd, you need to use glassfish-\* set of the dtds.

Thursday Dec 10, 2009

Glassfish v3 and deployment

Glassfish v3 and deployment

The Java EE 6 compatible Glassfish v3 is released today! In addition to provide v2 feature parity, the v3 deployment implements the new Java EE 6 spec requirements which include the deployment of ejb lite (EJBs packaged inside the war), the portable naming (where you can define application name and module name in the deployment descriptors and then use them in JNDI lookup) and etc.

Among many changes that went into v3 deployment, the most important piece is the new pluggable/extensible deployment framework. This pluggable deployment framework allows you to plug in new module/container types with the container SPIs (see Add-On Component Development Guide for more details). The JSR 299 (Context and Dependency Injection) RI was integrated through the framework. The Java EE standard module/container types were also re-written to retro-fit into the framework. This deployment framework also sends application lifecycle events at various points of the deployment to allow application developers to perform tasks (such as application initialization/clean up work) as needed at those points.

In v3, the code paths of the application loading during deployment and server start up have been converged to provide users more consistent behaviors (which also helps make code maintenance easier). As a result, we don't write out the generated deployment descriptors (merged version from the original deployment descriptors and the annotations) by default any more. If you need to use the generated deployment descriptors for debugging purpose, you can use the system property (-Dwriteout.xml=true) to write them out.

Monday Sep 17, 2007

glassfish v2 and deployment

Glassfish v2 is released today! Aside from providing various support for the glassfish internal components (JBI etc), the main focus for deployment in v2 has been user experience:

  • Faster deployment: We have improved deployment performance in several ways, especially in the web redeployment area.

  • More diagnostic error messages: We now provide diagnostic error messages for the most common error use cases.

One highlight in v2 on the user experience is to address the windows locking problem. In v1, one complaint we often heard about is redeployment or undeployment failing due to windows locking. And Tim has written a quite useful tool to diagnose the cause of the file locking. In v2, we have taken a significant further step to address/alleviate this type of problem from the glassfish server side and we have heard great feedback about this!

Another thing that's worth mentioning is we have provided support to integrate with MyEclipse in v2, and now users can deploy to glassfish through MyEclipse (via auto directory deployment).

Thursday Mar 16, 2006

How to connect local context to global jndi context

map local context to global jndi context How do we connect local context (logical jndi name) to global JNDI context (physical jndi name)?
This question got asked quite often and yesterday again. So I thought I'd post the question and my answer here.

I'm a little lost here. I'm trying to create an MDB, but I'm not sure how to look up the mapped resources - I have a queue and a connection factory defined, but when I use the canonical names, they never resolve. When I use netbeans to create the references, it uses a "Name" attribute, but using that name doesn't resolve either; I guess I'm just not sure how to connect local contexts to the global JNDI context.

Can anyone explain how this works in glassfish for me?

There are two ways you can map the logical jndi name (the resource reference name that you use to look up in your code, or the local jndi name your referred to) to the physical logic name (the name that you create the resource with, or the global jndi name you referred to).

1. Using the sun specific deployment descriptor files
2. Using the mappedName attribute of the Resource annotation (this is new in Sun Java System Application Server 9.0 / Glassfish)

You can look at this simple mdb test as an example:

In this example, a message connector factory "jms/ejb_ejb30_hello_mdb_QCF" (i.e. the physical jndi name) is created:
asadmin create-jms-resource --restype javax.jms.QueueConnectionFactory jms/ejb_ejb30_hello_mdb_QCF

1. And in the Client code, it uses the mappedName attribute to map the logical jndi name "FooCF" to the physical jndi name "jms/ejb_ejb30_hello_mdb_QCF"
    @Resource(name="FooCF", mappedName="jms/ejb_ejb30_hello_mdb_QCF")
    private static QueueConnectionFactory queueConFactory;

2. Alternatively, you could have this in the Client code without the mappedName attribute:
    private static QueueConnectionFactory queueConFactory;

   Then in the sun-application-client.xml, you will provide this mapping

Lastly, in the Sun Java System Application Server 9.0 / Glassfish, we have implemented some runtime defaulting mechanism for global jndi names. When the logical jndi name is the same as physical jndi name, no mapping is needed. You could get more details on this from my runtime defaults blog.

Friday Feb 10, 2006

Runtime defaults in Appserver9/Glassfish

providing runtime defaults in Glassfish     A Java EE application is a logical collection of one or more Java EE modules tied together by application deployment descriptors. In addition to the Java EE standard deployment descriptors, application server vendors use runtime deployment descriptors for configuring features specific to their server. The use of runtime deployment descriptors adds additional complexity in deploying an application to a Java EE application server, as well as making it harder for a user to port applications from one such a server to another.

    To alleviate the users from having to always provide runtime deployment descriptors, we have implemented many runtime defaults in the upcoming Sun Java System Application Server 9.0 Beta release (will be referred as appserver9 below), also available in Glassfish. This will reduce and in some cases eliminate the need for including runtime deployment descriptors in an application. For example, we are now providing defaults for the jndi names of various JNDI environment references (ejb-ref, resource-ref, resource-env-ref, message-destination-ref). In previous versions of Sun Java System Application Server, for example,  Sun Java System Application Server 8.x (will be referred as appserver 8 below), after the JNDI environment references are defined in the standard deployment descriptor, mapping of these environment references to their physical jndi names would need to be defined in the runtime deployment descriptors. This is no longer needed in appserver9 if the physical jndi name is the same as the environment reference name.

    Following is a simple example to illustrate the simplification. It uses the resource reference scenario described in the Tomcat tutorial. It inserts two employees into the Employee table and displays back the second employee.

    The AccessDBServlet use a data resource jdbc/EmployeeDB to talk to the underlying database: 

InitialContext initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup("java:comp/env");
DataSource ds = (DataSource) envCtx.lookup("jdbc/EmployeeDB");

    In the standard deployment descriptor (web.xml), it defines this resource-ref entry for the data source:
<description>Employees Database for HR Applications</description>

    To have this application work on appserver8 or port this application from Tomcat to appserver8, you would need to map the resource reference to the physical jndi name of the jdbc resource created on the server in the runtime deployment descriptor (sun-web.xml).

    But in appserver9 and Glassfish, you don't need to do any mapping. Especially if this is the only information you needed in the sun-web.xml, now you are runtime deployment descriptor free. 

    You can download the complete source of this example from here (thanks Lance for his help with database setup). There is a build.xml provided in the zip file,  you can use that to create the datasource, create the table, package and deploy the application (the build.xml is only tested on unix platforms, you will need to modify it to make it work for windows). Of course you could also choose to do the tasks manually.

    The main ant targets of the build.xml are as follows:

deploy-jdbc: create the jdbc resource jdbc/EmployeeDB on the server
create-sql: create the Employee table
build: build and package the web application
deploy: deploy the web application to the server
undeploy: undeploy the web application from the server
undeploy-jdbc: delete the jdbc resources jdbc/EmployeeDB from the server

    Before you use the build.xml, you need to edit with appropriate values. For example, you need to set appserver.home to where you installed the appserver/glassfish, and java.home to where you installed the jdk.

#set this to where you installed the appserver/glassfish
#set this to where you installed the JDK

    To run the sample, assume you have installed the appserver/glassfish at $AS_INSTALL and unzip the example at $EXAMPLE_DIR
    1. Start the appserver9/Glassfish
cd $AS_INTALL/bin
./asadmin start-domain

    2. Start the derby database in network mode (Derby database is integrated with the appserver9/glassfish)
cd $AS_INTALL/bin
./asadmin start-database

    3. Creates the datasource,  create the table, package and deploy the application
ant deploy-jdbc create-sql build deploy
    4. Point your browser at 

    5. After you are done, you could undeploy the application, delete the table, delete the resource
ant undeploy delete-sql undeploy-jdbc

    6. Stop the appserver/glassfish
cd $AS_INTALL/bin 
./asadmin stop-domain

    7. Stop the Derby database
cd $AS_INTALL/bin
./asadmin stop-database

Wednesday Jan 25, 2006

First external app-hosting application AtLeap is deployed!

First external app-hosting application is deployed     I've spent some time working on the app-hosting project after the new year and deployed its very first external application AtLeap last week.

    App-hosting project provides the J2EE community an outlet to showcase the applications the developers are working on. The applications will be deployed on Sun's SJSAS appserver which is hosted on a system by LocalWeb in Brazil. Community members are encouraged to submit the J2EE application for deployment. The actual deployment of an application is done by a small team of engineers from Sun. As a member of this team, I had the pleasure of working on the very first application.  The following is an account of my experiences.

   The whole process went pretty smooth. Andrey Grebnev, the owner of the project AtLeap, submitted us the application description. The team agreed to accept his project after some discussion. Andrey then provided us with detailed instructions on how to deploy it. I worked with Renato Weiner from LocalWeb side to configure the hosting machine. Since this is the first external project, it took us a little while to get everything set up. Once we were past that, it was very easy. The instructions that Andrey provided are very straightforward and easy to follow. The actual deployment was like a breeze.

   The AtLeap application (read more about the application) is a framework which allows Java developers to rapidly start their own Web application based on modern (Hibernate, Spring) and prevalent (Struts, XDoclet)libraries. AtLeap has its own rich tag library (more than 60 tags) to provide grid, menu, context menu functionality etc. It also includes multilingual CMS based on established solutions (Lucene, FCKEditor, TinyMCE) with full-text search (including Word, Excel, PDF, PowerPoint).




« July 2016