J道jdon.com

回复: 回复: 回复:OSGi ，有人用过吗？

banq — Thu, 02 Jul 2009 09:20:00 GMT

我们为什么需要分布式OSGi
http://www.infoq.com/cn/articles/newcomer-distributed-osgi

分布式OSGI其实已经在newton infiniflow中已经实现，2009年中标准出炉，这就越来越像EJB了。

不过因为它和EJB一样，是给POJO上的一个套子，这个套子是不是合适，看来用了EJB套子的人再换这个新套子试验看看。

正因为这种套子感觉，OSGI支持者就疯狂劝说SUN在其JDK中加入OSGI，Java 7可能考虑加入OSGI，但不是完全的。

OSGI曾经在Spring DM Server和SUN的glassfish v3推出时，引起一段骚动，但是现在已经没有什么动静，难道Java领域现在只有靠冷饭热炒来制造一些热点吗？

我不否定OSGi在动态上有其特点，但是从设计角度来看，而这正是很多人推荐OSGI的原因，从分离关注角度，从透明性角度(带的套子再超薄透明，也是套子)，OSGI要打折扣的。

另外，OSGI组件配置中指定输入包和输出包，这个配置相对于自动依赖注射auto wired，要显得有些弱智。

OSGI本身已经走向重量化，特别和SCA结合，简直是一个超级重量武器，和EJB有过之无不及，所以，我还是喜欢原来嵌入式设备上的OSGI，apache的felix用在服务器端就很好。

btw:我现在有一个机械判别组件或框架的重量和轻量的方法：核心组件jar包不要大于300K。

以上是个人意见，只供参考，不过现在我写这些，也许OSGI的fans们已经冷静许多。

关于Java 7模块系统(OSGI)
http://www.infoq.com/cn/articles/java7-module-system
[该贴被banq于2009-07-02 17:24修改过]

回复: 回复:OSGi ，有人用过吗？

banq — Thu, 02 Jul 2009 09:05:00 GMT

I personally think that we - as developers - have to enforce constraints on ourselves! We have to automatically check the defined constraints and let the build process fail if we e.g. accessed some classes we were not meant to access. OSGi's versioning concept (as a side effect ...) makes a first step of bringing the enforcement of architectural constraints to the developer's daily life by definining export and import packages ... and introduces a completely new dimension of problems! OSGi resolves versioning issues at runtime by giving each bundle it's own class loader and let that class loader see exactly the classes in the versions it depends on. Sounds neat ? Yes it is - and you will curse it! This leads to a really new dimension of problems, because it really changes the way your environment works. Your code passes all your unit tests, but once you start it in an OSGi runtime it crashes; Libraries crash because the enhance their classes at runtime; Singletons designed as static objects get created more than once; The story continues ... You typically end up in a situation where you constantly tweak your modules build specifications (that creates your manifest) and spread absolutely counter-intuitive dependencies across your whole system. Spring DM also addressed this topic - by adding some directives to your services and tweaking around with the class loaders ... and you still need to tweak and spread dependencies. I'm shivering at the thought that I need this workaround to even get started ...

Especially that class loading hell leads to a new dimension of problems. You will quickly notice that you cannot go on without a strong and automated integration testing suite that incorporates OSGi (another thing that Spring DM supports).

Now - what's my conclusion about all that stuff. First of all - before considering OSGi I would really check if I have the ultimate requirement to exchange bundles at runtime without shutting down the system - and even in this case I would really revisit these requirements and see if I can limit them to a corner where I could use other techniques for dynamically loading modules at runtime. There are alternatives out there fostering the architectural principles (e.g. you could use an IOC container, use independent container instances to enforce module independence, do constraint checking at build time, etc...) - most of these things are much closer to the KISS principle, avoid all the additional boiler plate code and build configuration - and therefore allow you to stay more agile.

I almost forgot the title :o) There's another technology out there with pretty the same characteristics (in terms of things being complicated): EJB. Spring is propably the most popular example of what can happen when a technology is way too complicated and makes life hard. Maybe we will experience the same thing with OSGi in in the next years ? I cannot say ... however, if this is the case, then there is a certain irony in that SpringSource now heavily supports OSGi :o)

回复:OSGi ，有人用过吗？

banq — Thu, 07 May 2009 01:59:00 GMT

OSGI可实现即将即用热部署，包括分布式环境，除了这个，你就会觉得OSGI象个套子。

OSGI跟踪管理服务是很复杂，即使有Spring DM帮忙，还是要启动OSGi runtime and install and start the bundles。

老外有一篇使用的心得：OSGI可能是下一个EJB，对OSGI又爱又恨：
http://peterrietzler.blogspot.com/2008/12/is-osgi-going-to-become-next-ejb-bubble.html

因这个网址被查封，转帖英文如下：

A few weeks ago I spotted an article that stated OSGi as "the next big thing after Spring". Actually, there are a whole bunch of articles, blogs etc... out there in the wild - all praising OSGi as one of the next "big things" that will reach many sectors in the Java space. I don't doubt this and I do admit that OSGi solves many problems and supports top notch architectural models such as high modularization and micro services. However, on the other side - after using OSGi for a couple of years and see how it performs (in the meaning of development performance) in different areas I really have doubts about OSGi.

Here are some things I love and hate about OSGi:

The concept of creating a system out of even hundred of typically pretty small bundles is very good. The really good thing about bundles in OSGi is that they have defined borders - not only in the sense of dependencies but also in the sense of runtime. Each bundle can serve as a micro application, having it's own lifecycle, having it's own citizens and each bundle can carefully decide which objects to expose to the outside world. Carefully adopted, this leads to a system with loose coupling and a high probability for reuse. However, at the same time the lifecycle model of OSGi makes life complicated. Actually, tracking services and managing all the aspects of what to do when services come and go is nasty (I've seen systems that had tried to manage these things with pretty large state machines in their bundle activators ... this is boiler plate that no one wants to write!) - Luckily, there's Spring DM out there that helps us manage these things. To be honest - I'd never even think about starting an OSGi project without using Spring DM. Altough Spring DM greatly reduced the complexity of bundle setup, it's still complicated. I still need to start the OSGi runtime and install and start the bundles - and I have to take care that all other bundles that I need are installed and started too ...

[该贴被admin于2009-07-02 17:03修改过]

JavaFX RIA企业应用简要

mikejava — Thu, 02 Jul 2009 08:30:00 GMT

测试成功。不知道 javafx 的前景如何？

回复:回复:tapestry组件的例子

fhit — Thu, 02 Jul 2009 08:13:00 GMT

没有接触过tapestry的朋友请特别注意这些参数问题。组件的参数和容器的关系是双向的。

在上面的代码中：


<div t:type="breadCrumb" myCurSection="curSection" returnPage="literal:section/mySectionIndex"></div>

请注意两个参数的写法是不一样的，其中一个有前缀：literal，而另一个没有。其实是省略了，写出来应该是：prop:curSection。

literal表示是字面常量，prop表示这个值是页面对应的java类的一个getCurSection而获得的值。在这种情况下，组件的myCurSection的值来自包含它的容器组件的getCurSection()方法。

而在外围容器组件中，如果组件通过另一个方式写的话，也可以获得组件的myCurSection值，并且可以修改myCurSection的值。

回复:对jdonjive中某些xml文件的疑惑

yllik — Thu, 02 Jul 2009 07:40:00 GMT

谢谢板桥老师形象的解释，我会继续努力研究这个问题

回复:tapestry组件的例子

fhit — Thu, 02 Jul 2009 07:02:00 GMT

这是使用这个组件的页面的代码：


<span t:type="breadCrumb" t:myCurSection="curSection"></span>

或者（组件的returnPage参数是可选的，这里因为提供了returnPage参数，所以点击面包屑的时候，返回到这个页面，比如在添加文章的时候，你希望点击面包屑时回到index页面，而不是继续停留在本页）：


<div t:type="breadCrumb" myCurSection="curSection" returnPage="literal:section/mySectionIndex"></div>

tapestry组件的例子

fhit — Thu, 02 Jul 2009 06:55:00 GMT

要了解tapestry面向组件的特点，最好是来一个例子。本人用perl、python和ruby编写过一些系统，发现java的tapestry好像更组件。

组件知道周围的环境，环境知道组件的情况，就好象是活的一样。以常见的一个导航路径为例（breadcrumb面包屑）：首页》论坛》设计模式、框架和架构。

下面的代码是组件的java类：


package com.m3958.tcms.components;

import java.util.ArrayList;
import java.util.Collections;

import org.apache.tapestry5.Link;
import org.apache.tapestry5.annotations.Parameter;
import org.apache.tapestry5.annotations.SetupRender;

import com.m3958.tcms.base.MyComponentBase;
import com.m3958.tcms.data.SectionNodeVo;
import com.m3958.tcms.utils.MyString;

public class BreadCrumb extends MyComponentBase{

	private int index;
	
	
	private ArrayList<SectionNodeVo> breadCrumb;
	
	public ArrayList<SectionNodeVo> getBreadCrumb() {
		return breadCrumb;
	}

	public void setBreadCrumb(ArrayList<SectionNodeVo> breadCrumb) {
		this.breadCrumb = breadCrumb;
	}

	private SectionNodeVo breadCrumbItem;
	
	
	public boolean isLast(){
		if(breadCrumb.size()  > index + 1){
			return false;
		}else{
			return true;
		}
	}
	
	@Parameter(required=true)
	private SectionNodeVo myCurSection;
	
	@Parameter
	private String returnPage;
	
	
	Object onActionFromCd(String sectionId){
		
		if(getLoginUser().isSuperman() || getLoginUser().isSitemanager()){
			Link link = null;
			if(MyString.isEmpty(returnPage)){
				 link = getPrl().createPageRenderLinkWithContext(getResource().getPage().getClass(), sectionId);
			}else{
				link = getPrl().createPageRenderLinkWithContext(returnPage, sectionId);
			}
			return link;

		}
		
		SectionNodeVo snv = getSitevoByManagingSite().findSectionNodevo(sectionId);
		int depth = 10;
		while(snv != null && depth > 0){
			depth--;
			if(getLoginUser().getSections().contains(snv.getId())){
				Link link = null;
				if(MyString.isEmpty(returnPage)){
					 link = getPrl().createPageRenderLinkWithContext(getResource().getPage().getClass(), sectionId);
				}else{
					link = getPrl().createPageRenderLinkWithContext(returnPage, sectionId);
				}
				return link;

			}
			snv = snv.getParent();
		}
		return null;
	}
	
	Object onActionFromMd(String sectionId){
		
		String sectionType = MyString.splitAndGet(myCurSection.getDtype(), "\\.", -1);
		
		Link link = getPrl().createPageRenderLinkWithContext("section/" + sectionType + "Create", sectionId);
		return link;
	

	}
	
	
	
	@SetupRender
	void initialize(){
		SectionNodeVo svo = getMyCurSection();
		breadCrumb = new ArrayList<SectionNodeVo>();
		while(svo != null){
			breadCrumb.add(svo);
			svo = svo.getParent();
		}
		Collections.reverse(breadCrumb);
	}

	public void setIndex(int index) {
		this.index = index;
	}

	public int getIndex() {
		return index;
	}

	public void setBreadCrumbItem(SectionNodeVo breadCrumbItem) {
		this.breadCrumbItem = breadCrumbItem;
	}

	public SectionNodeVo getBreadCrumbItem() {
		return breadCrumbItem;
	}

	public void setMyCurSection(SectionNodeVo myCurSection) {
		this.myCurSection = myCurSection;
	}

	public SectionNodeVo getMyCurSection() {
		return myCurSection;
	}

}

下面的是tml文件：


<div   xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd">
	<t:loop source="breadCrumb" value="breadCrumbItem" index="index">
		<a href="#" t:type="actionlink" t:id="cd" context="breadCrumbItem.id">${breadCrumbItem.name}(${breadCrumbItem.dtypeName})</a>
		<t:unless test="last">
			>> 
		</t:unless>
	</t:loop>
	<a href="#" t:type="actionlink" t:id="md" t:context="MyCurSection.id"><img src="${asset:context:images/newfolder.gif}" alt="新建目录" title="新建目录"/></a><br/>
	
	
</div>

回复:关于算法

banq — Thu, 02 Jul 2009 03:58:00 GMT

多谢楼主指教，我很烂的知识很多，因为我是普通的人，我以后如果有需要会学习，关键是要象老子讲的那样，让自己变成空房子，这样才能接受新知识。

我的关键意思是：不要把自己变成知识库，而是变成可以抓取知识的人。(不要把自己变成google，而是变成会使用Google的人)

现在的应试教育都已经把人搞畸形了，大家都在比谁的知识多，谁厉害，就象比谁的饭吃得多，谁的肚皮大，谁就有发言权一样，实在太愚昧，这样国人到底是不是先秦诸子的后代？

前段时间中央电视还抨击google，因为google在和他争发言权了，而这些主编和记者也是现在畸形教育出来的，他们认为谁有发言权是因为他的知识多，google有这么大影响力就是因为他的知识多，所以，他们就开始攻击它(知识本身是不管孔子的善恶好坏的)，实际他们不知道自己在攻击人类自身的知识库，更暴露了自己奇怪可笑的逻辑。

怪不得很多历史学家都说：涯山之后，便无中国。

[该贴被banq于2009-07-02 12:11修改过]
[该贴被banq于2009-07-02 12:12修改过]

回复:对jdonjive中某些xml文件的疑惑

banq — Thu, 02 Jul 2009 04:06:00 GMT

XML相当于水泥，把砖头(功能模块类)粘在一起。

回复:文思创新赴百度项目招聘JAVA牛人！（北京）

Hire — Thu, 02 Jul 2009 03:43:00 GMT

招聘中。。。。。。

对jdonjive中某些xml文件的疑惑

yllik — Thu, 02 Jul 2009 03:13:00 GMT

大家好，我学习jdon时间不长，还没怎么研究过jdonframework就直接开始了对jdonjive的学习。现在碰到个问题，jdonjive中不少包中都会带个xml配置文件，比如auth.xml,models.xml等等，请问这些xml文件是作什么用的呢
由于还没细读jdonframework，如果提了菜鸟问题，还请各位见谅，不吝赐教。

回复:关于算法

jvcoffee — Thu, 02 Jul 2009 02:07:00 GMT

我觉得知道几个算法没什么,因为算法的思想大都不是中国人自己想出来的,许多问题的算法国外都已经很成熟了,国内只是照搬过来用不同的语言实现而已。

各位大哥帮我看看这是个什么错误啊？

1s2k3y4 — Thu, 02 Jul 2009 00:41:00 GMT

怎么没有人呢？大哥们帮我看看吧

关于算法

Azuryy — Wed, 01 Jul 2009 12:25:00 GMT

Banq，
我觉得你的算法一定很烂！

各位大哥帮我看看这是个什么错误啊？

1s2k3y4 — Wed, 01 Jul 2009 11:37:00 GMT

各位大哥，最近一直有一个问题一直困扰着我。
最近我在做一个小项目我用到了Spring的编程式事务并且对它进行了简单的封装

public class MyTransactionManager
{
private IPlatformTransactionManager TransactionManager;
private ITransactionStatus status;
public MyTransactionManager()
{
TransactionManager = ServiceContainer.Container.IPlatformTransactionManager;
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
def = new DefaultTransactionDefinition();
def.PropagationBehavior = TransactionPropagation.Required;
status = TransactionManager.GetTransaction(def);
}
public void Commit()
{
TransactionManager.Commit(status);
}
public void Rollback()
{
TransactionManager.Rollback(status);
}
}
使用的时候是
try
{
MyTransactionManager m=new MyTransactionManager();
//
//中间的逻辑代码（通过的Hibernate进行数据库访问）
//
m.Commit()
}
catch(Exception e)
{
m.Rollback();
}
有时候当我单击某个按钮的时候程序就死在那里了，然后走断点的时候我发现当执行m.commit()的时候语句程序感觉上就被挂起了（程序不动了），过了一会报错
"Hibernate flusing: could not update: [DZ.BookingSystem.KBP.Model.RunnerOperation#12][SQL: UPDATE runneroperation SET RunnerDate = ?, BookingCountOfToday = ?, BookingUserCountInfield = ?, BookingQueueCount = ?, HadGetNumCount = ?, HadCalledBookingUserCount...
然后在不关闭程序的情况下，我去数据库主动操作刚刚在程序中操作的数据，同样无法操作，并报超时的错误。但是过了一会（在不关闭程序的情况下）我再走一次执行过的那段代码又恢复正常了（能够事务提交并且数据库变化）（请注意：是在没有重新启动项目的情况下），真的觉得好奇怪，谁能帮我解释下为什么？(要说明的是，在程序启动的时候，我开了其他几条死循环线程，同样会用到事务提交，我不知道会不会和这个错误有关联？）各位大哥，小弟在这里谢谢你们了，帮我看看吧！！！！！！！！

回复:J2EE常用资源管理方式总结。

freeren — Wed, 01 Jul 2009 11:36:00 GMT

最近突然很关心楼主的文章，这样的好文值得收藏，学习了！
相对于楼主的进步，本人真的是很是嫉妒和佩服！

回复:JavaFX RIA企业应用简要

banq — Tue, 30 Jun 2009 01:51:00 GMT

Jdon的Remote Access已经整入JdonFramework 5.8中，在线演示：http://www.jdon.com:8080/jdonremote/

JavaFX + Hessian + Jdon 源码下载：
https://sourceforge.net/project/showfiles.php?group_id=126953&package_id=138962

开发简要步骤：
在web.xml配置Hessian Servlet Proxy如下：
<servlet>
<servlet-name>Hessian2Jdon</servlet-name>
<servlet-class>com.jdon.bussinessproxy.remote.HessianToJdonServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Hessian2Jdon</servlet-name>
<url-pattern>/remote/*</url-pattern>
</servlet-mapping>

这样，当远程客户端调用http://localhost:8080//remote/helloService，那么这个Servlet 将在jdonframeowrk.xml查找服务名称为helloService的服务：
<app>
<services>
<pojoService name="helloService" class="sample.HelloServiceImpl"/>
</services>
</app>
远程客户端代码如下：
HessianProxyFactory factory = new HessianProxyFactory();
HelloService _service = (HelloService)
factory.create(HelloService.class, _url);
_service.hello(s);
客户端调用HelloService的hello方法时，将激活HelloServiceImpl.hello方法。Demo在线演示网址：http://www.jdon.com:8080/jdonremote/

[该贴被banq于2009-07-01 17:35修改过]

回复:谁能告诉我这个问题怎么解决？ JDK1.5特性

yuhonglei4025 — Wed, 01 Jul 2009 09:03:00 GMT

你的泛型有些地方没有做检查，忽略了一些警告，导致runtime错误

回复:回复:jdon的真正起源-坛主别删

water1735 — Wed, 01 Jul 2009 08:41:00 GMT

哈哈，楼主将Jive和banq的JiveJdon搞混了吧。你那同事也真可爱。banq是自己搞了个Jdon,然后在此基础上做的JiveJdon.

给公司炒了之后，很是迷惑

zjutsoft — Wed, 01 Jul 2009 07:14:00 GMT

不知道楼主现在做的怎么样了。是妥协于现状只求做好功能。还是继续坚持自己的多层架构。请回帖说说现在的情况

[请教]自学以后如何能找工作的问题?

zjutsoft — Wed, 01 Jul 2009 07:05:00 GMT

这个帖子，一直跟到现在了啊！不错。不知道楼主现在怎么样了。java方面是不是有很深的造诣了。或者已经在大公司工作了。或者已经放弃了。这个我比较关心。谢谢。如果楼主看到。请回个贴。时间才是最好的证明。

两年程序员的感悟，SQL才是重点，JAVA无所谓。

BinnyJ — Wed, 01 Jul 2009 06:16:00 GMT

我现在觉得，OO可以学习学习，但在中国大部分软件企业（特别是中小型），还是以面向过程，面向数据库，面向SQL为主。

看看我的帖子。
http://www.jdon.com/jivejdon/thread/36171.html

回复:Re: bq看看这个，既然可以这样为什么还要用dcl

whyenglish — Wed, 01 Jul 2009 05:49:00 GMT

可以这样吗？
class Singleton
{
private static Singleton instance = null;
//enforce singleton
private Singleton() {
//...
}
public static Singleton getInstance()
{
if(instance == null){
synchronized(Singleton.class){
//check again
if(instance ==null ){
instance = new Singleton();
}
}
}
return instance;
}
}

不知道这样对性能的影响会有多大？一旦instance实例化后，第二次getInstance()就不会再运行到 synchronized(..)。为什么非要在方法上进行整个同步呢？这样做会产生多个Singleton的实例吗？
[该贴被whyenglish于2009-07-01 13:51修改过]

回复:谁能告诉我这个问题怎么解决？ JDK1.5特性

banq — Tue, 30 Jun 2009 09:48:00 GMT

The type Collection is not generic; it cannot be parameterized with arguments <? extends E>

Collection不是泛型。

回复: 回复:(OO + 分布式计算) = 软件架构的方向

banq — Tue, 30 Jun 2009 08:38:00 GMT

>过度依赖网络的存储和过度依赖网络的存储
没明白，是不是写错了，或者详细演绎一下？谢谢

回复:(OO + 分布式计算) = 软件架构的方向

lynne — Tue, 30 Jun 2009 08:32:00 GMT

呵呵，过度依赖网络的存储和过度依赖网络的存储是两码事啊。

回复:请教struts2标签由于改变了工程编码后无法正常显示的问题

greentree — Tue, 30 Jun 2009 05:42:00 GMT

这个问题可也真是叫人头疼,不行的话只能是重新来一次了,在以前正常的分支基础之上, 将最编码后的所有页面和代码重新添加一遍!

回复:谁能告诉我这个问题怎么解决？ JDK1.5特性

jvcoffee — Tue, 30 Jun 2009 05:05:00 GMT

能把jsp代码贴出来么？
[该贴被jvcoffee于2009-06-30 13:05修改过]

谁能告诉我这个问题怎么解决？ JDK1.5特性

lamei — Tue, 30 Jun 2009 02:39:00 GMT

我已经用JDK1.5编译的，为什么TOMCAT会报这个问题呢？？？已经郁闷好久了。始终没解决。

HTTP Status 500 -

--------------------------------------------------------------------------------

type Exception ******

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 15 in the generated java file
The type Collection is not generic; it cannot be parameterized with arguments <? extends E>

Stacktrace:
org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:93)
org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330)
org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:435)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:298)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:277)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:265)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:302)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:329)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:416)

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.27 logs.

--------------------------------------------------------------------------------

Apache Tomcat/5.5.27