PrimeFaces UI 0.9.3 is released/IPhone App Development with JSF

(From http://www.theserverside.com/news/thread.tss?thread_id=58131)
UI Components 0.9.3 features the TouchFaces mobile UI kit, 5 new components, improved portlet support, enhanced datatable and various improvements.

* TouchFaces - UI Development kit for mobile devices mainly iphone
* New component : FileUpload (Reimplemented)
* New component : Tooltip (Reimplemented)
* New component : PickList
* New component : HotKey
* New component : Virtual Keyboard
* Easy row selection, ajax pagination, data filtering and lazy loading enhancements to DataTable
* Significantly improved portal support for JSR168 and JSR268 portlets.
* Pojo and Converter support for AutoComplete


(From http://www.theserverside.com/news/thread.tss?thread_id=57877)
TouchFaces is a new subproject of PrimeFaces targeting the mobile
devices mainly iphone. Applications created with TouchFaces have the native look and feel of an IPhone applications and still benefit from the Java/JSF infrastructure. In addition TouchFaces depends on the PrimeFaces UI so ajax is built-in.

There's a 10 minute getting started screencast available online.


Website: http://primefaces.prime.com.tr/en/

User specified error message

(From http://www.dbmotive.com/oracle_error_codes.php?errcode=20001)

Error messages starting from -20000 until -20999 are user specified error messages.

Oracle provides these range of codes so applications can raise an application specific error, which will be displayed after the chosen code.
This is done using the raise_application_error pl/sql function.

You'll have to contact the application provider should you want to have more detail about the error message.
Unless the error message is of an Oracle application or functionality, it is useless to contact Oracle for these errors.

Imagine I have a procedure which takes an argument. This arguments needs to be between 0 and 100:

create or replace procedure add_salary(pRaise number) is begin   if pRaise not between 0 and 100 then     raise_application_error(-20000, 'Raise need to be between 0 and 100');   end if;   -- do further processing end; / Procedure created.  SQL> 

Now we test the procedure with a valid argument:

SQL> exec add_salary(0);  PL/SQL procedure successfully completed. 

And now with an invalid argument:

SQL> exec add_salary(110); BEGIN add_salary(110); END;  * ERROR at line 1: ORA-20000: Raise need to be between 0 and 100 ORA-06512: at "DEV01.ADD_SALARY", line 4 ORA-06512: at line 1 

As one can see, we raised a custom error -20000 with a user defined error message.
The same thing happened with you, if you receive this error with one of our applications, you need to contact us in order to solve this problem.

So the only one who can help is the application vendor or service provider.

Handle Oracle PL/SQL Exception.

Few use the Oracle stored procedure in Java application. Today, I have to learn it as there is a modification in stored procedure. By the searching, got a link from Oracle website. It is a official help and pretty good. But I really hate to use them in application if not very very necessary. Anyway, just put here for a reference.

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/errors.htm#i1863

GMaps4JSF 1.1.2 release

GMaps4JSF 1.1.2 release: "GMaps4JSF 1.1.2 release"

JSF is really a good framework and this feature is truely help us.

Ubuntu下如何安装Cisco VPN client - Rainman的专栏 - CSDN博客

This is a installation guide for VPN on Ubuntu.

Ubuntu下如何安装Cisco VPN client - Rainman的专栏 - CSDN博客: "Ubuntu下如何安装Cisco VPN client"


我的环境是Ubuntu 8.04, VPN Client的版本是vpnclient-linux-x86_64-4.8.01.0640-k9。

1. 下载Cisco VPN client 的压缩包vpnclient-linux-x86_64-4.8.01.0640-k9.tar.gz, 可以直接在google输入这个文件名下载。

2. 下载以后打开命令窗口执行 tar zxvf vpnclient-linux-x86_64-4.8.01.0640-k9.tar.gz解压，目录下会出现vpnclient的文件夹。

3. 下载vpnclient的patch文件, 对应这个版本的patch是vpnclient-linux-2.6.24.diff，用其他的版本应该不会成功。这个文件也可以直接在google输入文件名下载。

4. 把下载下来的vpnclient-linux-2.6.24.diff放到刚才解压的vpnclient文件夹内。

5. 把目录切换到vpnclient文件夹下。

6. 执行$ patch < vpnclient-linux-2.6.24-final.diff

7. 执行$ sudo ./vpn_install 根据提示选择安装的路径或者直接按回车按照默认路径安装

8. 执行 sudo /etc/init.d/vpnclient_init start 输入密码，如果提示Starting /opt/cisco-vpnclient/bin/vpnclient: Done就表示安装成功了。

9. 把你的pcf文件放到etc/opt/cisco-vpnclient/Profiles/ 文件夹下，比如是mypcf.pcf。

10. 执行$vpnclient connect mypcf按照提示输入你的用户名密码等等就可以开始vpn之旅了。



本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jinhuiyu/archive/2009/01/18/3821246.aspx

How to generate Hibernate POJO and mapping files from a db schema

Howto generate Hibernate POJO and mapping files using ant from a db schema FactoryPattern.com

How to Generate Hibernate Pojo Classes from DB Tables

Hibernate schema generation using Middlegen with SQL Anywhere

OSGi and Spring: Part 2: Build and deploy OSGi as Spring bundles using Felix

OSGi and Spring: Part 2: Build and deploy OSGi as Spring bundles using Felix: "OSGi and Spring: Part 2: Build and deploy OSGi as Spring bundles using Felix"

OSGi and Spring, Part 1: Build and deploy OSGi bundles using Apache Felix

OSGi and Spring, Part 1: Build and deploy OSGi bundles using Apache Felix: "OSGi and Spring, Part 1: Build and deploy OSGi bundles using Apache Felix"

Understanding Java's "Perm Gen" (MaxPermSize, heap space, etc.)

(http://mark.kolich.com/2009/01/understanding-javas-perm-gen-maxpermsize-heap-space-etc.html)

During my travels at work, I've come across a few interesting memory management issues in Java. My team has deployed several large web-applications in a single instance of Apache Tomcat. The Linux box running these applications only has about 2GB of physical memory available. Once the apps are deployed, about 1.8 GB of the memory is consumed by Java alone. Clearly, we need to improve our memory management a bit.

However, I took a few minutes to do some digging on Java's Permanent Generation (Perm Gen) and how it relates to the Java heap. Here are some distilled notes from my research that you may find useful when debugging memory management issues in Java ...
JVM arg -Xmx defines the maximum heap size. Arg -Xms defines the initial heap size. Here is an example showing how you use these JVM arguments:

-Xmx1638m -Xms512m

In Tomcat, these settings would go in your startup.sh or init script, depending on how you start and run Tomcat. With regards to the MaxPermSize, this argument adjusts the size of the "permanent generation." As I understand it, the perm gen holds information about the "stuff" in the heap. So, the heap stores the objects and the perm gen keeps information about the "stuff" inside of it. Consequently, the larger the heap, the larger the perm gen needs to be. Here is an example showing how you use MaxPermSize:

-XX:MaxPermSize=128m



FOLLOWUP 1/30/09

Here are some additional notes on interesting/important JVM parameters:

Use the JVM options -XX:+TraceClassloading and -XX:+TraceClassUnloading to see what classes are loaded/un-loaded in real-time. If you have doubts about excessive class loading in your app; this might help you find out exactly what classes are loaded and where.

Use -XX:+UseParallelGC to tell the JVM to use multi-threaded, one thread per CPU, garbage collection. This might improve GC performance since the default garbage collector is single-threaded. Define the number of GC threads to use with the -XX:ParallelGCThreads={no of threads} option.

Never call System.gc(). The application doesn't know the best time to garbage-collect, only the JVM really does.

The JVM option -XX:+AggressiveHeap inspects the machine resources (size of memory and number of processors) and attempts to set various heap and memory parameters to be optimal for long-running, memory allocation-intensive jobs.

TrackBack URL: http://mark.kolich.com/mt-tb.cgi/96

MaxPermSize and how it relates to the overall heap

(Got from Google page cache. Lost the Author)

MaxPermSize and how it relates to the overall heap
Many people have asked if the MaxPermSize value is a part of the overall -Xmx heap setting or additional to it. There is a GC document on the Sun website which is causing some confusion due to a somewhat vague explanation and an errant diagram. The more I look at this document, the more I think the original author has made a subtle mistake in describing -Xmx as it relates to the PermSize and MaxPermSize.

First, a quick definition of the "permanent generation".
"The permanent generation is used to hold reflective data of the VM itself such as class objects and method objects. These reflective objects are allocated directly into the permanent generation, and it is sized independently from the other generations." [ref]

Yes, PermSize is additional to the -Xmx value set by the user on the JVM options. But MaxPermSize allows for the JVM to be able to grow the PermSize to the amount specified. Initially when the VM is loaded, the MaxPermSize will still be the default value (32mb for -client and 64mb for -server) but will not actually take up that amount until it is needed. On the other hand, if you were to set BOTH PermSize and MaxPermSize to 256mb, you would notice that the overall heap has increased by 256mb additional to the -Xmx setting.

So for example, if you set your -Xmx to 256m and your -MaxPermSize to 256m, you could check with the Solaris 'pmap' command how much memory the resulting process is taking up.

i.e.,
$ uname -a
SunOS devnull 5.8 Generic_108528-27 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine

$ java -version
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)

---------------------------------------------
$ java -Xms256m -Xmx256m -XX:MaxPermSize=256m Hello &
$ pmap 6432
6432: /usr/java1.3.1/bin/../bin/sparc/native_threads/java -Xms256m -Xmx256m
total 288416K
---------------------------------------------
Notice above that the overall heap is not 256m+256m yet? Why? We did not specify PermSize yet, only MaxPermSize.

---------------------------------------------
$ java -Xms256m -Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m Hello &
$ pmap 6472
6472: /usr/java1.3.1/bin/../bin/sparc/native_threads/java -Xms256m -Xmx256m
total 550544K
---------------------------------------------

Now we see the overall heap grow, -Xmx+PermSize. This shows conclusive proof that PermSize and MaxPermSize are additional to the -Xmx setting.

How pretty it is - Click

http://click.sourceforge.net/

Click is a open source simple JEE web application framework for commercial Java developers, licensed under the Apache license.Click uses an event based programming model for processing Servlet requests and Velocity for rendering the response. (Note other template engines such as JSP and Freemarker are also supported).

It is really a pretty good framework to develop website and easy to learn also.

Get to know Apache Click.
http://www.ibm.com/developerworks/web/library/wa-apacheclick/?ca=dgr-jw22ApacheClick&S_TACT=105AGX59&S_CMP=grjw22

Reap the benefits of document style Web services

http://www.ibm.com/developerworks/webservices/library/ws-docstyle.html

James McCarthy (mailto:jmccarthy@symmetrysolutions.com?subject=Reap), President and CTO, Symmetry Solutions, Inc.

While most Web services are built around remote procedure calls, the WSDL specification allows for another kind of Web services architecture: document style, in which whole documents are exchanged between service clients and servers. In this article, James McCarthy explains what document style is and when you should use it.

Buried deep in the Web Service Definition Language (WSDL) specification is a very subtle switch that can turn the SOAP binding of a Web service from a remote procedure call to a pass-through document. The style attribute within the SOAP protocol binding can contain one of two values: rpc or document. When the attribute is set to document style, the client understands that it should make use of XML schemas rather than remote procedure calling conventions. This article will provide a description of this WSDL switch, describe its benefits, and explain when you should use pass-through documents.
Setting your service to use document style
First, let's briefly touch on a few point about WSDL to understand how this subtle change occurs. WSDL is an XML specification that is used to describe network services and the protocol-specific requirements for reaching an endpoint (the service). WSDL describes services in abstract terms; through an extensible binding definition, it is able to define the protocol and data format specifications for calling a service in concrete terms. The following grammar, taken directly from the WSDL specification, shows the extensibility elements contained within a binding:

Listing 1. WSDL grammar for extending elements within a binding

<wsdl:definitions .... >
<wsdl:binding name=3D"nmtoken" type=3D"qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name=3D"nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name=3D"nmtoken"? > ?
<-- extensibility element (3) -->=20
</wsdl:input>
<wsdl:output name=3D"nmtoken"? > ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name=3D"nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
< /wsdl:definitions>

The WSDL specification (see the Resources section below for a link) currently describes three binding extensions: HTTP GET/POST, MIME, and SOAP version 1.1. The binding extensions defined in HTTP GET/POST and MIME are used to define the requirements to communicate with standard Web applications that may or may not return XML documents. When sending or returning an XML document, the HTTP GET/POST binding extension is implicitly document style.
The SOAP binding extension is used to define a service that supports the SOAP envelope protocol. The SOAP envelope is a simple schema that is designed to contain an XML message, providing an application-specific header and a body portion of the message. The SOAP binding extension allows the WSDL document to declare the requirements of a SOAP message so that the application is able to properly communicate with the service. The SOAP extension allows the style of the SOAP message to be declared as either document or RPC. If the style attribute is declared in the soap:binding element, then that style becomes the default for all soap:operation elements that do not explicitly declare a style attribute. If the style attribute is not declared in the soap:binding element, then the default style is document. Here is an explicit declaration of document style:

Regardless of the declaration within the soap:binding element, the soap:operation element can override the declaration for each operation, like so:

In a SOAP message for which document style is declared, the message is placed directly into the body portion of the SOAP envelope, either as-is or encoded. If the style is declared as RPC, the message is enclosed within a wrapper element, with the name of the element taken from the operation name attribute and the namespace taken from the operation namespace attribute.

Benefits of document style
No one can dispute that the ability to invoke a cross-platform remote procedure call using XML is extremely useful and is a compelling argument for using Web services. But if Web services were constrained exclusively to RPC messaging, the reach of the technology would be limited. Fortunately, developers have a choice of using either RPC or document style messaging and are able to use the right technology for the tasks they face.

With document style, you can make full use of XML
The XML specification was developed to allow ordinary data that is usually locked up in a proprietary format to be described in an open format that is human readable, self-describing, and self-validating. When a Web service uses document messaging, it can use the full capabilities of XML to describe and validate a high-level business document. When a service uses RPC message formatting, the XML describes the method and the parameters encoded for the method call and cannot be used to enforce high-level business rules. In order to enforce these rules, the RPC message must include an XML document as a string parameter and hide the validation within the method being called. For this reason, some of the benefits of XML are lost, or at least hidden within the back-end application.

Document style does not require a rigid contract
Another reason to use document messaging is that a remote procedure call is meant to be relatively static and any changes to the interface would break the contract between the service and the application. If a service is widely distributed, then it is likely that a large number of applications have produced stub code from its WSDL document. Changing the WSDL would cause all of the applications that rely on a specific method signature to break and a lot of support lines to ring. Good design dictates that the method signature of an RPC message service should never change. With document messaging, the rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the calling application.

Document style is better suited for asynchronous processing
When businesses are using a Web-based application to exchange information over the Internet, the application should be able to use a guaranteed delivery mechanism to improve its reliability, scalability, and performance. To achieve this, an application will generally use asynchronous message queues. Since a document message is usually self-contained, it is better suited for asynchronous processing and can be placed directly into the queue. The reliability of the application is improved because the message queue guarantees the delivery of the message even if the target application is not currently active; performance is improved because the Web application simply delivers the document to a queue and is then free to perform other tasks; and scalability is improved because the document is offloaded to one or more instances of an application that handles its processing.

Document style makes object exchange more flexible
The design of a business document is often very well suited to object-oriented architectures. As a result, two applications may be designed to exchange the state of an object by using XML. In contrast with object serialization, in an object exchange, each end of the exchange is free to design the object as it sees fit as long as the exchange conforms to the agreed upon XML document format. One reason for not using object serialization is to support client-side and server-side implementations of an object. Many current industry-specific XML schemas are designed as client/server architectures in which the processing that is done at the client is separate from the processing intended at the server. As is often the case, the client is simply requesting or saving information in a specific document format that is persisted at the server. Certainly, this type of exchange could be done using an RPC message, but the encoding scheme of such a message places constraints on the design of the object at each end. These constraints are not a problem with document style.


When to use document style
When should you use document style? The short answer: Anytime you are not interfacing to a preexisting remote procedure call, the benefits of document style may outweigh the extra effort that is often required to interface to the service. A caveat: The effort to build a service that uses document messaging is usually greater than the effort required to build an RPC message service. This extra effort usually involves the design of an XML schema or support for a preexisting schema, as well as the extraction of relevant information from a document. The schema design is important because the XML parser uses the schema to validate the document, supporting the intended business rules. Additional effort is required by the service to extract relevant information from the document to be used while handling the request. In contrast, an RPC message only requires the design of the method interface, from which it will automatically marshal and unmarshal the parameters.
When making your decision to publish a service, you might want to consider the following questions. I'll examine the consequences of your answers in the following sections.
Is this service interfacing to a preexisting procedure call and is the procedure call stateless?
Is the service to be used only within your organization, or by outside users as well?
Is one of the parameters simply an XML document specification?
Does the service require a request/response architecture?
Do the parameters represent complex structures that may benefit from an XML document schema for validation?
Can all of the information that needs to be exchanged be reasonably contained in memory?

Use document style when maintaining application state
You should consider a document architecture for your service if multiple procedures must be called in a particular sequence to maintain application state. If multiple procedure calls are required, then the procedure is not stateless and the service must maintain application state. Maintaining state within a Web service can be difficult; in the case of a remote procedure call, very few client platforms will generate stub code that is able to support state information. One possible solution is to use document architecture and pass the contents of an entire transaction within the document. In this case, the service will perform the calls to ensure that the proper sequence is maintained inside the service and state information is not maintained beyond a single transaction. If state information is still required, it can be built in to the resulting document, or the client application can maintain a token that identifies its state to the service.

Use document style to publish services for outside partners
If an application is being published outside of the organization, the publisher has very little control over who is relying on the service and what the consequences will be if any changes are made. In such cases, it may be more advantageous to use document messaging and support a common exchange protocol such as ebXML. Common exchange protocols are evolving to improve the management of external exchanges so that new trading partner agreements can be rapidly deployed. Also, if your service does not require a request/response architecture, then common exchange protocols are better designed to handle authentication, reliable message delivery, and asynchronous request/response.

Use document style to ease validation and use of complex documents
If your service is using a string parameter to pass or return an XML document, or if one of its parameters is an object with a complex structure that requires custom handling, then document messaging may be the better alternative. Hiding the true meaning of a parameter within a string can often lead to valid calls with invalid parameters. If the service publishes an XML document schema, then it is easier to validate against that schema prior to calling the service. A complex structure is often used to pass hundreds of pieces of information making up a complete transaction. When dealing with complex structures, a remote procedure service may have to deal with custom marshaling code while the application is still responsible for meticulously validating each element of the structure. If document messaging is used, then the application programmer can offload validation to the document designer using an XML schema, and no custom marshaling code is required.

Use document style to minimize in-memory processing
One final consideration when choosing between document and RPC messaging is the amount of information that may need to be handled. Since most if not all of the implementations that marshal parameters in RPC messaging perform this operation in-memory, memory constraints may make RPC messaging unfeasible. Many document-messaging services are able to choose between DOM and SAX handling of the document and as a result are able to minimize in-memory processing. This is particularly critical for a Web service that may be required to handle thousands of requests, many simultaneously.


Conclusion
When designing your next Web service, you need to consider all of the options that the current WSDL specification gives you. Before starting with a procedural interface, consider how the service will be used, who will be using it, and the type and volume of information that needs to be exchanged. Designing and developing a document style Web service may require a little more effort, but in many cases the effort will pay off in the quality of information and the reliability of the exchange.

Resources
"Deploying Web services with WSDL," Bilal Siddiqui (developerWorks, November 2001) is a good introduction to the Web services and Web Services Description Language.
Check out the specifications for WSDL and SOAP.
The XMethods site is hosting a demo Web service that is built using document style.
Check out the latest on IBM's Web Services initiative.

Useful doc for Axis: Axis 2 tips and tricks.

http://www.keith-chapman.org/2008/10/apache-axis2-tips-and-tricks.html

The difference of Timer implementation in WebLogic 8.x and 9.x

eDocs of wl8.x http://edocs.bea.com/wls/docs81/jmx/timer.html
eDocs of wl9.x http://edocs.bea.com/wls/docs90/jmxinst/timer.html

In the 8.1, the timer uses a simple way to add and remove notification while 9.x uses a service to do schedule.

Scheduling Jobs in WebLogic Server

(Comes form http://wldj.sys-con.com/read/48929.htm)
(Chinese Edition http://dev2dev.bea.com.cn/techdoc/200508639.html)

The need to run scheduled jobs is increasing and becoming common across all J2EE applications. The current J2EE specification doesn't provide an easy way to schedule jobs inside an enterprise application.

We can broadly classify scheduled J2EE jobs into two categories: Server-specific scheduled jobs and application-specific scheduled jobs. This article explores how to schedule application-specific jobs inside a WebLogic Application Server.

Server-Specific vs. Application-Specific Scheduled JobsServer-specific scheduled jobs are associated with the lifecycle of the application server. Typically these jobs are started during the server's startup and will be active until it's shut down. As a consequence, all the resources needed for scheduled jobs have to be specified in the server's classpath.

Application-specific scheduled jobs are associated with the lifecycle of the enterprise application. They are started after the application is deployed and will be active until the application is undeployed. The resources required for application-specific scheduled jobs are packaged in the enterprise application (EAR - enterprise archive resource).

Application jobs are preferable to server jobs for the following reasons:
Any changes to the application jobs can be redeployed easily with the application (EAR file). For server jobs the server has to be restarted for the new changes to take effect, and this may not be desirable as it impacts the availability of other applications deployed on that server.
Since the scheduled jobs usually invoke business functionality, it's more logical to package them with in the EAR file.

By associating the resources with the EAR file, we can deploy the EAR file on another instances of WebLogic Server without having to reconfigure the resources for that server.
Schedule Jobs Inside an Enterprise ApplicationWe will look at an example of how to implement application-specific scheduled jobs. Here we schedule two jobs that invoke business functions at certain specified intervals.

Order submission - invoked every day.
Inventory submission - invoked once a week.

In this example we're going to use WebLogic's Application Lifecycle Events in tandem with WebLogic's Timer Notifications.

These are the three steps involved in setting up scheduled jobs:
Implement the Timer Notification Listener, which is responsible for adding, listening, and handling the timer notifications.
Implement the Application Lifecycle Listener, which instantiates the Timer Notification Listener on desired application lifecycle events.

Register the Application Lifecycle Listener in weblogic-application.xml Implement the MyAppJobSchedulerMyAppJobScheduler will implement the javax.management.NotificationListener interface.

public final class MyAppJobScheduler implements NotificationListener
This class will instantiate weblogic.management.timer.Timer class and register itself as a listener for timer notifications. The Timer class is a WebLogic implementation of javax.management.TimerMBean.

timer = new Timer();
timer.addNotificationListener(this, null, "some handback object");

The order notification and inventory notification are added to the timer before the timer starts.

timer.addNotification("OrderSubmission", "Order Submission",
this,orderSubmissionDate, DAILY_PERIOD);
timer.addNotification("InventorySubmission",
"Inventory Submission", this,inventorySubmissionDate,
WEEKLY_PERIOD);

We will schedule the jobs so the Order job will run every day at 5 p.m. and the Inventory job will run once a week, every Friday at 10:30 p.m. Please check the code listing for details on how to construct the Date object with the specified time.

The callback method will get the notification. Based on the notification, a business process component (EJB) can be invoked to fulfill the scheduled job.

public void handleNotification(Notification notif, Object handback)
{
String type = notif.getType();
if ( type.equals("OrderSubmission") )
{
// invoke the component or ejb that does the order processing and submission
}
else if ( type.equals("InventorySubmission") )
{
// invoke the component or ejb that does the inventory processing and submission
}
}

The cleanUp method of MyAppJobScheduler stops the timer, and removes all the notifications that were added to it. We can invoke the cleanUp method as shown above from the preStop method, or it can be invoked from the finalize method of MyAppJobScheduler.

public synchronized void cleanUp()
{
System.out.println(">>> MyAppJobScheduler cleanUp method called.");
try
{
timer.stop();
timer.removeNotification(orderNotificationId);
timer.removeNotification(inventoryNotificationId);
System.out.println(">>> MyAppJobScheduler Scheduler stopped.");
}
catch (InstanceNotFoundException e)
{
e.printStackTrace();
}
}

Here is how the final method of MyAppJobScheduler will look:
protected void finalize() throws Throwable
{
System.out.println(">>> MyAppJobScheduler finalize called.");
cleanUp();
super.finalize();
}

Implement MyAppListenerWe will write a class MyAppListener that extends weblogic.application.ApplicationLifeCyleListener. Application lifecycle listener events provide handles that developers can use to control behavior during deployment, undeployment, and redeployment.

public class MyAppListener extends ApplicationLifecycleListener
We want to start the scheduled jobs as soon as the application is deployed. So we will invoke the MyAppJobScheduler in the postStart method of MyAppListener. If you want to invoke the Scheduler before the startup, the invocation will be in the preStart method.
public void postStart(ApplicationLifecycleEvent evt)
{
System.out.println( "MyAppListener:postStart Event");
//Start the Scheduler
myAppJobScheduler = new MyAppJobScheduler();
}

We want to unschedule the jobs before the application is undeployed. So we invoke the MyAppJobScheduler's cleanUp method in the preStop method of MyAppListener.
public void preStop(ApplicationLifecycleEvent evt)
{
System.out.println( "MyAppListener:preStop Event");
//Stop the Scheduler
myAppJobScheduler.cleanUp();
}

Register MyAppListenerIn the weblogic-application.xml, register MyAppListener class for application lifecycle events.
<listener>
<listener-class>MyAppListener</listener-class>
</listener>
Include MyAppJobScheduler, MyAppListener in the application classpath, or alternatively you can specify the jar file using parameter.
<listener>
<listener-class>MyAppListener</listener-class>
<listener-uri>scheduler.jar</listener-uri>
</listener>

References
WebLogic Server: Programming Application Lifecycle Events: http://e-docs.bea.com/wls/docs90/programming/lifecycle.html
WebLogic Timer: http://e-docs.bea.com/wls/docs90/javadocs/weblogic/management/timer/Timer.html
J2EE Notification Listener: http://java.sun.com/j2ee/1.4/docs/api/javax/management/NotificationListener.html

Scheduling Jobs in WebLogic Server - src

The source code is in the following link:
http://photos.sys-con.com/story/res/48929/source.html

MyAppJobScheduler.java
/* * MyAppJobScheduler.java * */
import java.util.*;
import javax.management.Notification;
import javax.management.NotificationListener;
import javax.management.InstanceNotFoundException;
import weblogic.management.timer.Timer;
// Implementing NotificationListenerpublic final class MyAppJobScheduler implements NotificationListener
{
private static final long DAILY_PERIOD = Timer.ONE_DAY;
private static final long WEEKLY_PERIOD = 7 * Timer.ONE_DAY;
private Timer timer;
private Integer orderNotificationId;
private Integer inventoryNotificationId;
public MyAppJobScheduler() {
// Instantiating the Timer MBean
timer = new Timer();
// Registering this class as a listener
timer.addNotificationListener(this, null, "some handback ?object");
// These values should be read from a property file
int orderSubmissionHour=17;
int orderSubmissionMinute=0;
int inventorySubmissionDay = 6;
int inventorySubmissionHour = 22;
int inventorySubmissionMinute = 30;
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.HOUR_OF_DAY,orderSubmissionHour);
calendar.set(Calendar.MINUTE,orderSubmissionMinute);
Date orderSubmissionDate = calendar.getTime();
calendar.set(Calendar.DAY_OF_WEEK, inventorySubmissionDay);
calendar.set(Calendar.HOUR_OF_DAY,inventorySubmissionHour);
calendar.set(Calendar.MINUTE,inventorySubmissionHour);
Date inventorySubmissionDate = calendar.getTime();
// Add the order notification which should run every day at ?5:00 PM
orderNotificationId = timer.addNotification("OrderSubmission", "Order Submission",
this,orderSubmissionDate, DAILY_PERIOD);
// Add the inventory notification which should run every Friday ?at 10:30 PM
inventoryNotificationId = timer.addNotification?("InventorySubmission", "Inventory Submission",
this,? inventorySubmissionDate, WEEKLY_PERIOD);
timer.start();
System.out.println( ">>> MyAppJobScheduler started." );
}

protected void finalize() throws Throwable {
System.out.println(">>> MyAppJobScheduler finalize called.");
cleanUp();
super.finalize(); }

public synchronized void cleanUp() {
System.out.println(">>> MyAppJobScheduler cleanUp method ?called.");
try {
timer.stop();
timer.removeNotification(orderNotificationId);
timer.removeNotification(inventoryNotificationId);
System.out.println(">>> MyAppJobScheduler Scheduler ?stopped.");
} catch (InstanceNotFoundException e){
e.printStackTrace();
}
}
/* callback method */
public void handleNotification(Notification notif, Object handback) {
String type = notif.getType();
if ( type.equals("OrderSubmission") ) {
// invoke the component or ejb that does the order processing ?and submission
} else if ( type.equals("InventorySubmission") ) {
// invoke the component or ejb that does the inventory ?processing and submission
}
}

public static void main(String[] args) {
MyAppJobScheduler myAppJobScheduler = new MyAppJobScheduler(); }
}


MyAppListener.java
/* * MyAppListener.java * */
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyAppListener extends ApplicationLifecycleListener{
MyAppJobScheduler myAppJobScheduler;
public void preStart(ApplicationLifecycleEvent evt) {
System.out.println("MyAppListener:preStart Event");
}
public void postStart(ApplicationLifecycleEvent evt) {
System.out.println( "MyAppListener:postStart Event");
// Start the Scheduler myAppJobScheduler = new MyAppJobScheduler();
}

public void preStop(ApplicationLifecycleEvent evt) {
System.out.println( "MyAppListener:preStop Event");
// Stop the Scheduler
myAppJobScheduler.cleanUp();
}

public void postStop(ApplicationLifecycleEvent evt) {
System.out.println( "MyAppListener:postStop Event");
}
public static void main(String[] args) {
System.out.println( "MyAppListener:main method"); }
}

weblogic-application.xml
<weblogic-application>
<listener>
<listener-class>MyAppListener</listener-class>
</listener>
</weblogic-application>