J道jdon.com

jdon的真正起源-坛主别删

hantsy — Fri, 03 Jul 2009 11:21:00 GMT

连jive,jdon都分不清，就JJYY，现在的人啊。。。

回复:有个问题假如你的项目当中有些domain字段是数据字典形式的，大家是怎么ddd的

banq — Fri, 03 Jul 2009 09:27:00 GMT

SEX如果会变化，那么就以类继承方式扩充。

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

tiaoD — Fri, 03 Jul 2009 09:20:00 GMT

谣言碰上了无知再加上敢说话==混乱

回复:如何用代码来编译jsp页面

tiaoD — Fri, 03 Jul 2009 09:18:00 GMT

实现很简单把JSP的标准看明白
根据规则把JSP的每条语句转换成一个方法里面的prinf
然后把JSP搞成JAVA 再编译

mysql中的date?

tiaoD — Fri, 03 Jul 2009 09:09:00 GMT

字段长度

回复:有个问题假如你的项目当中有些domain字段是数据字典形式的，大家是怎么ddd的

gamex — Fri, 03 Jul 2009 06:08:00 GMT

而且这也引申了一个问题，像这种业务字段由客户自己去添加的应用，用DDD去提炼领域代码似乎有点勉强。我看过的千篇一律都是以数据表字典来做这件事的，一些业务类型都是在存在数据表当中。假如要重用这领域代码，要连同这些类型表一起打包。

有个问题假如你的项目当中有些domain字段是数据字典形式的，大家是怎么ddd的

gamex — Fri, 03 Jul 2009 06:01:00 GMT

比如说：
user{
name；
age；
sex：（比如，这些有可能以字典形式设计的（而不设计成枚举的），因为以后方便增加类型）
}
大家会怎么设计会，是会把sex设计成String，还是有一个关联？
1.设计成String的缺点是，假如我以后更改了类型，在user里面保存的旧类型就匹配不上
2.假如设计成字典类型，又不能直观的在代码当中体现出类型就像枚举那样，而且也和相应的数据库绑定在一起。
没有相应的表数据你就不知道有多少种类型。
虽然他是个值对象，但是是否有一种方式可以很好的兼顾两者，即能很好的扩充类型，又能得到很好的领域代码。

我不知道我这样描述是否大家回听得懂否，希望大家一起来讨论下。

mysql中的date?

zhangxiuwei — Fri, 03 Jul 2009 03:52:00 GMT

在一个类中，private java.util.Date createDate;
如何把java.util.Date的类型的值保存到mysql数据库中。总是报error,如下：
com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data truncated for column 'date' at row 1;
如何解决？

我来讨论一下纯理论的老问题.长方形和正方形的继承关系.

snowwolf — Fri, 03 Jul 2009 03:49:00 GMT

正方形继承矩形类的做法无疑是错误的：
对于那个变形方法来说，他获得的对象是矩形，因为矩形的行为中定义了长宽可以分别做任意修改而不会互相影响。用一个类继承矩形没有错，错就错在这个类修改了父类的这种行为。
其实从开闭原则更容易看待这个问题。分别设置高和宽是矩形类的public方法，这两个方法是“开”的。在正方形类继承他的时候，他可以重写这两个方法，没有问题，但在方法的实现上实质是正方形类“闭”了一个方法，简单的来说就是正方形类想“private”setWidth()或setHeight()。子类绝对是不能“闭”父类“开”属性的。
由此引申继承的问题，extends关键字代表“扩展”，即子类应该是扩展了父类的行为和属性，而不应该是加入了更多的约束。即子类应该比父类更“开”，而不可能是更“闭”。
PS：“正方形是一个矩形”这句话其实没说完，完整的表达是这样的“正方形是矩形的一个特例”。从这里可以看出来，正方形只是矩形这个类的一个实例，创造这个实例的人应该自己管理他对这个实例的约束。而如果你要从这种带有约束性质的实例来抽象出一个类，那么这个类绝对不可以从这些实例的类中继承。
再说简单点：在一个矩形对象恰好在宽、高相等的时候，我们才从概念上认为它是“正方形”。

回复: 回复: 回复: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

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