when webSphere application server startup, hibernate uses WebSphere datasource.
step by step錛?br />
1 coding statup constom service
import javax.management.Notification;
import javax.management.NotificationFilterSupport;
import javax.management.NotificationListener;
import javax.management.ObjectName;
public class WebsphereStartup implements CustomService,NotificationListener {
public void initialize(Properties arg0) throws Exception {
NotificationFilterSupport filter = new NotificationFilterSupport();
filter.enableType(NotificationConstants.TYPE_J2EE_STATE_RUNNING);
ObjectName target = new ObjectName("WebSphere:*,type=Server");
AdminServiceFactory.getAdminService().addNotificationListenerExtended(
target,
this,
filter,
null);
}
public void shutdown() throws Exception {
// When was shutdown錛?nbsp; this method is executed
}
public void handleNotification(Notification notification, Object handback) {
// write init code here
init();
}
}
2 modify hibernate config file hibernate.cfg.xml
<property name="hibernate.connection.datasource">data source jndi</property>
<property name="hibernate.connection.username">name</property>
<property name="hibernate.connection.password">password</property>
<property name="hibernate.session_factory_name">HibernateSessionFactory</property>
<property name="connection.autocommit">false</property>
<property name="net.sf.hibernate.transaction.JTATransactionFactory">net.sf.hibernate.transaction.WebSphereTransactionManagerLookup</property>
<property name="show_sql">false</property>
<property name="dialect">org.hibernate.dialect.Oracle9Dialect</property>
娉ㄦ剰錛氬鏋滄槸闈炰簨鍔℃ф暟鎹簮 閭ｄ箞鍦╤ibernate.cfg.xml 蹇呴』璁劇疆 <property name="connection.autocommit">false</property>
涓篺alse
3 create datasource jndi on was
濡傛灉鏄潪浜嬪姟鎬ф暟鎹簮錛屽湪寤虹珛鏁版嵁婧愭椂錛屼篃瑕佽緗負闈炰簨鍔℃ф暟鎹簮銆?br />
4 config custom service bean on Websphere
was console >servers> application server > server1>manage>custom service >new
5 start Server
]]>
閿欒淇℃伅錛堝湪Systemout.Log鏂囦歡涓級
java.security.AccessControlException: Access denied (java.io.FilePermission
瑙ｅ喅鏂規硶
淇敼 server.policy 鏂囦歡錛屽湪 install_root/properties/server.policy 涓壘鍒版鏂囦歡銆傛鏂囦歡鍖呭惈榪欎簺緙虹渷璁稿彲鏉冿細
// Allow to use ibm jdk extensions
grant codeBase "file:${was.install.root}/java/ext/-" {
permission java.security.AllPermission;
};
// Allow to use ibm tools
grant codeBase "file:${was.install.root}/java/tools/ibmtools.jar" {
permission java.security.AllPermission;
};
// Allow to use sun tools
grant codeBase "file:/QIBM/ProdData/Java400/jdk14/lib/tools.jar" {
permission java.security.AllPermission;
};
// Allow to use sun tools (V5R2M0 codebase)
grant codeBase "file:/QIBM/ProdData/OS400/Java400/jdk/lib/tools.jar" {
permission java.security.AllPermission;
};
// WebSphere system classes
grant codeBase "file:${was.install.root}/plugins/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${was.install.root}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${was.install.root}/classes/-" {
permission java.security.AllPermission;
};
// Allow the WebSphere deploy tool all permissions
grant codeBase "file:${was.install.root}/deploytool/-" {
permission java.security.AllPermission;
};
// Allow the WebSphere deploy tool all permissions
grant codeBase "file:${was.install.root}/optionalLibraries/-" {
permission java.security.AllPermission;
};
// Allow Channel Framework classes all permission
grant codeBase "file:${was.install.root}/installedChannels/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.install.root}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${user.install.root}/classes/-" {
permission java.security.AllPermission;
};
濡傛灉鑺傜偣涓婃湁涓浜涙湇鍔″櫒紼嬪簭闇瑕佽鍙潈錛岃岃繖浜涜鍙潈鍦?server.policy 鏂囦歡鍜?server.policy 鏂囦歡涓湭瀹氫箟涓虹己鐪佸鹼紝閭ｄ箞鏇存柊 server.policy 鏂囦歡銆傜己灝戣鍙潈灝嗗垱寤?java.security.AccessControlException 寮傚父銆傜己灝戠殑璁稿彲鏉冨湪寮傚父鏁版嵁涓垪紺恒?
鐒跺悗閲嶆柊鍚姩鏈嶅姟鍣?/p>
or
ServiceMBeanSupport 鍜孲erviceMBean
2 startup class on Websphere
customService interface 錛坣eed com.ibm.ws.runtime.jar )
3 startup class on tomcat
ServletContextListener interface
]]>
The need to use statically-defined stubs depends only on what kind of client you have; it doesn't depend at all on where the EJB is that you're looking up or invoking. If your client is a WebSphere container that's been upgraded via the EJB 3.0 feature pack, then we have technology in the container itself that will dynamically generate the client-side stub for you in-memory when it's needed, assuming that you at least have the EJB remote interface packaged where the client can access it. So if your client is the WAS web container, EJB container, or application client container and the client environment has had the EJB 3.0 feature pack applied, you should not need to generate or package any client-side stubs with your client. If your client environment is something other than the above, then you will need to generate the client-side stubs with the createEJBStubs tool that comes with the EJB 3.0 feature pack, and package the resulting stubs in your client package. Here's a snippet of the documentation that covers this in more detail:
Just-In-Time Deployment
The EJB 3.0 Feature Pack adds a new feature to WebSphere application server called Just-In-Time Deployment. With Just-In-Time Deployment, the EJB container dynamically generates the wrapper, stub, and tie classes in-memory as needed when the application is running. Additionally, the web container and application client containers dynamically generate the stub class required for remote EJB invocations. Effectively, this means that you do not need to process EJB 3.0 modules, web modules that invoke EJB 3.0 beans, or client modules that invoke EJB 3.0 beans, through the EJBDeploy tool prior to running them in WebSphere.
The createEJBStubs tool
Even though the Just-In-Time deployment feature will, in many cases, dynamically generate the RMI-IIOP stub classes that are required for invocation of remote EJB interfaces, there remain some cases where these stub classes are not dynamically generated. For EJB 3.0 clients not running inside a WebSphere feature-pack-upgraded web container, EJB container, or client container, it is necessary for you to generate the stub classes with the createEJBStubs tool, then make the generated stubs available in the client environment's classpath. Typically you would accomplish this by copying the generated stubs to the location where the client's business interface class resides.
To summarize, the createEJBStubs tool must be used to generate client-side stubs for the following environments:
* "Bare" Java SE clients, where a Java SE JVM is the client environment
* WebSphere Application Server container environments without the EJB 3.0 feature pack applied
* Non-WebSphere application server environments
]]>