osgi+websphere6.1+jms+若干问题小结

osgi本来就是基于插件的模块化开发，如果要放在web容器下运行，它提供了一个ServletBrige.class类（名字记不太清了），比如在web.xml配置Servlet的name以及实现类为这个ServletBrige类，还有一些初始化的参数，这些参数名称是固定的，可以反编译这个ServletBrige类查看，那么web容器启动的时候，就能加载osgi，但是为什么要这样做？为什么不直接建立个web项目直接在web容器运行岂不是好？
如果按照这种方式，那么要获取web容器替我们初始化好的东西比如JNDI、数据源、JMS连接工厂等等就会有问题，因为osgi的类加载器是每个工程有自己的类加载器（osgi玩的不深，查了些资料貌似是这样说），如果要获取web容器配置的东西，那么要使用如下方式：

Thread current = Thread.currentThread();

ClassLoader old = current.getContextClassLoader(); //获得当前线程的类加载器

try{

current.setContextClassLoader(ServletBrige.class.getClassLoader());//将类加载器换成web.xml里面的servletBrige类（这个类名记不清楚~），这样就可以获取web容器初始化好的内容

InitialContext context = new InitialContext(); //这一步new InitialContext()的时候才不会报异常，才能获取web容器的内容

context.lookup("jms/datasource);

}catch(Exception e){

}finally{

current.setContextClassLoader(old); //操作结束后，将类加载器换回来

}

但是采用上面这一步获取数据源是没有问题的，但是采用上面的方式获取jms连接工厂就会报错，具体错误信息是无法强制类型转换，最后搞了好久，反编译看过了，最后类型一模一样仍然无法强制类型转换，（websphere6.1里面的jms以及队列配置没有任何问题）。
所以后来，不用这种方式，采用直接给new InitialContext(Props);的方式获取，代码如下：

Properties props = new Properties();

props.put(Context.INITIAL_CONTEXT_FACTORY, "xxxxx");//名字记不清楚了，这两个是was工厂写死的，明天看下代码补上

props.put(Context.PROVIDER_URL, "iiop://localhost:2809");//这里面的url也基本上写死的，里面的2809端口号是was的应用程序服务器 > server1 > 端口里面的BOOTSTRAP_ADDRESS值

InitialContext context = new InitialContext(props);

// 接着就可以获取jms的jndi了

用这种方式需要was的包，具体如下(家里安装的是was7)：
IBM\WebSphere\AppServer\runtimes\com.ibm.ws.admin.client_7.0.0.jar
IBM\WebSphere\AppServer\runtimes\com.ibm.ws.webservices.thinclient_7.0.0.jar
\IBM\WebSphere\AppServer\plugins\com.ibm.ws.runtime.jar
还有几个类明天补上

posted on 2012-07-25 00:51 朔望魔刃阅读(452) 评论(0) 编辑收藏

常用链接

留言簿

随笔分类

随笔档案

文章分类

文章档案

收藏夹

娱乐博客

牛博

搜索

最新评论

阅读排行榜

评论排行榜


只有注册用户登录后才能发表评论。




网站导航: 博客园 IT新闻知识库 C++博客博问管理