re: 成功其实很简单,就是强迫自己坚持下去! Hi 骑士 2008-11-22 03:01
也许坚持是寂寞的很寂寞!也许是痛苦的,真的很痛苦。但是还是要坚持下去!相信自己!坚持下去你就是第一!
re: 成功其实很简单,就是强迫自己坚持下去![未登录] nile black 2008-08-21 10:32
不要蹉跎了自己的才华,与君共勉.
re: 成功其实很简单,就是强迫自己坚持下去![未登录] nile black 2008-08-21 10:31
不要蹉跎了自己的才华,与君共勉
re: 弃用notepad++[未登录] yang 2008-06-29 10:49
支持,我也卸载了.我很反感一些做开源的家伙,接着这个名声开始对什么都指手划脚,哪怕自己根本就不了解的东西.
其中令人恶心的,首推所谓的自由软件支付Richard Stallman
re: 弃用notepad++ gk 2008-06-14 10:34
顶!
re: 弃用notepad++ 如坐春风 2008-06-08 19:12
好!
re: 弃用notepad++ OnlyLinux 2008-06-04 05:44
Use JEdit, then. JEdit is the best open source text editor, I think it's much better than UltraEdit.
re: Eclipse Tips 隔叶黄莺 2008-03-19 10:31
好,让我解决了
2. Mylar导致Content Assist中出现重复的方法提示。
谢谢
re: Java IDE与开发工具试用印象[未登录] Welkin Hu 2008-01-18 12:44
@GentleYang
印象嘛,就是工作当中碰到的一些事情和感受。
“在开源时代,几乎你能想到的别人也都想到了”这句话没错,但想到不等于做到。坦率的说,开源产品还有太多的东西没有做到,尤其是易用性方面。
re: Java IDE与开发工具试用印象 GentleYang 2008-01-18 10:39
虽然我还是个coder新人;但是对于博主关于Eclipse中集成hibernate的相关论述不能完全苟同... 在开源时代,几乎你能想到的别人也都想到了,所以我很乐意在遇到一个非领域性问题时先去查找是否别人也遇到过这个问题...
在Eclipse中做hibernate相关的开发,现在已经有了N多的工具或插件嘞... 可以满足几乎所有要求嘞... N个数据源可以同时切换、一个库的N个表可以自由选择映射与否或者重映射与否... 总之可以让开发人员随心所欲地控制和利用它,甚至你可以把它生成的HBM改得面目全非,下次更新时再选择使用哪个版本...
PS:一点个人体会 ^=^
re: 用Myeclipse的理由 linginfanta 2007-08-23 17:15
项目不大,1万多行,
Myeclipse那个速度呀,真受不了
P4 3.0
1.5 G 内存。
为什么Configuration.buildSessionFactory()后会报
org.hibernate.HibernateException: No local DataSource found for configuration - dataSource property must be set on LocalSessionFactoryBean
今天被Spring的事务管理机制耍了,不得临时用用HibernateTemplate。一用才发现简单的查询被Spring搞复杂了,而且缺失了一些功能。
1,不支持分页。HibernateTemplate中有个fetch size,但没有first result。
2,传入命名参数时不是一个map,而是一个名称数组和一个值数组。
3,传入参数为null时有异常。
当然,解决办法很简单——写一个新类扩展HibernteTemplate。
此外,Spring参数文档中对HibernateTemplate的用法举例也有问题。在它的例子中,每个DAO类都有一个HiberanteTemplate属性,而不是每个DAO的方法自己创建一个新的HibernateTemplate实例。
这种做法的主要问题在于,HibernateTemplate中的一些设置,如fetch size, max results等,可能在调用者不知情的情况下,应用到后续查询中。
我现在更愿意把HibernateTemplate理解成Spring集成Hibernate的一个sample。想用就用,想改就改。
@netfishx
应当有往这个方向努力的目的,但还达不到。原因很简单,各个持久层的查询语言和模型不一致,比如HQO,SQL, JDOQL, JPQL, Criteria等等。Spring的Template虽然统一了API的方法名和参数个数,但其接收的参数本身仍是分裂的。
@dennis
老大高啊!一下子就找到我想要的解决办法了。俺马上就试试。
最大的作用应该是切换持久层框架。比如说最常见的同时用hibernate和原生jdbc,很多项目都会用到。
明白你的意思了,你是要得到Hibernate Configuration对象,重新build SessionFactroy吧。
你需要从ApplicationContext中得到LocalSessionFactoryBean,然后利用LocalSessionFactoryBean的newSessionFactory方法得到一个新的SessionFactroy或者getConfiguration()得到Configuration对象,前提你的bean要实现ApplicationContextAware接口得到Context对象,然后:
LocalSessionFactoryBean localSessionFactroyBean=(LocalSessionFactoryBean )ctx.getBean("&mySessionFactory");
Configuration=localSessionFactroyBean.getConfiguration();
加上符号&就可以引用到FactroyBean本身。不过这样一来你就要自己将SessionFactroy设置到HibernateTemplate
你是怎么得到SessionFactroy的呢?HibernateDaoSupport的getSessionFactory得到的就是原生的SessionFactroy啊
@Welkin Hu
并不是你没有用它就没有存在的必要,会有人用到的,spring不也给你了不同它的方法了么.
@aninggo
这么说主要好处是保证自动关闭session。这个的确很有用。
至于第二点,Jason想到的是方便用户从一种持久层技术切换到另一种。而在我们的产品中,持久层比较稳定,反倒是Spring,有可能被换掉。出发点不一样啊。
@Welkin Hu
虽然可以通过注入使用hibernate的原生API,但是还是有风险的,一旦该方法没有被事务包装起来,那么session最后就没有办法被自动关闭掉,这不像使用template,总可以被关闭掉,不管有没有事务封装。
而且joson说过 ,template的主要目的是提供一个统一的持久层访问接口.用不用完全看个人喜好,学习这个api的曲线不会太陡峭吧:)
@aninggo
我想知道的是,和直接使用hiberate API相比,有什么好处?不用HiberateTemplate,同样能整合事务,而且一样简单。
1.HibernateTemplate提供持久层访问模板化
2.使用HibernateTemplate无须实现特定接口,它只需要提供一个SessionFactory的引用,利用aop注入到dao就可以实现对持久层的操作
3.整合事物操作就已经是它存在的最好的理由了,还想要什么?
re: Spring断想:接口粘合 Welkin Hu 2007-05-14 09:19
@Coffee and Tea
嘻嘻,我的想法就是想给Java加点儿动态特性。当然,前提是不影响性能。
re: Spring断想:接口粘合 Coffee and Tea 2007-05-14 09:10
这是语言的问题,动态语言接口不必静态声明,因此就不需要有独立的接口jar包。
但是这也有两面性,如果缺少编译时检测,那么必须要加强其他手段防止接口错误,比如持续集成。
re: Spring断想:接口粘合 wolfsquare 2007-05-13 04:41
说得不是很清楚,但我直觉这样的问题不是来自于依赖,而是设计方案导致的。
【组件C1和C2是两个不同的业务组件,它们的UI中都有使用UIA这个组件】
从这个情形来看,后面的业务组件C1和C2其实应该是组合出来或是继承出来,
而从经验的角度看,可能以组合的方式更灵活一些。
re: Spring断想:接口粘合 Welkin Hu 2007-05-11 20:57
@dennis
你的观点我是赞同的。即便Spring真的提供了这个功能,我们在使用时也会审慎的考较它:是真的节省开发成本了,还是增加开发成本了?
如果有限度的,谨慎的使用接口粘合特性,应当是节省开发成本的。如果大张旗鼓的用,那十有八九是增加成本。
我只是觉得对于我在文章中所举的案例,确是一个需要接口粘合机制的东东。
@fullqin
真是只有想不到,没有做不到。以前零星听闻过Hivemind的大名。有机会一定研究一把。
re: Spring断想:接口粘合 dennis 2007-05-11 18:00
@Welkin Hu
依赖转移到xml文件,转移到火星,它仍然存在。我一直觉的xp的简单原则是对这种场景的最好考量。依赖这个东西不可能消除,再深究下去就over-engineering了。我们讲松耦合,而不是“无”耦合。
re: Spring断想:接口粘合 fullqin 2007-05-11 16:37
apache下的hivemind是基于接口粘合,可以去看看
re: Spring断想:接口粘合 Welkin Hu 2007-05-11 13:05
@dennis
Adapter模式仍然是用java类和接口来表达的,它没法完全消除开发时的依赖。
re: Spring断想:接口粘合 dennis 2007-05-11 10:37
接口之间的黏合?我觉的这里的场景应该是adapter模式应用的地方
数据量多也不明显。夏昕在《深入浅出Hibernate》中有介绍:Oracle就是这特性,得好的服务器配置才能体现其优点。
re: 终于明白了AOP中的方面是什么意思 Long 2007-04-24 17:53
呵
@BeanSoft
做这个,根本没有钱途,谁作呀!
是系统不同,还是键盘不同呢??
偶机器上2个系统,但是都是Ctrl+Space,
可见,跟系统没啥关系, 键盘的是。。。???
re: 终于明白了AOP中的方面是什么意思 ddd 2007-04-24 16:15
我今天在看Spring的文章的时候,也才知道AOP。。
简单的说, AOP就是插入一个功能,
在不影响现有功能的情况下, 向内插入一个新功能
re: 用Myeclipse的理由 Welkin Hu 2007-04-19 08:50
to m99c
对啊,WTP本身提供了XML的编辑器。刚刚试了一下,Myeclipse就是用的它。
前几天我测试时,用的是Eclipse 3.3 M6,WTP1.5.2和这个版本没法共同工作,使我误以为Eclipse没有XML编辑器。
今天用Myeclipse 3.2.2试了一下,确实是有的。
re: 用Myeclipse的理由 m99c 2007-04-19 00:03
可能楼主不太关心Eclipse,Myeclipse XML编辑器就是用Eclipse官方的WTP插件中的XML编辑器,初始代码是IBM贡献的。“做一个ear,至少要做三个项目:ear, war,ejb”这个也是Myeclipse 集成WTP插件的结果。
re: 用Myeclipse的理由 我为J狂 2007-04-18 20:09
IBM当初给Eclipse起名字的时候就太不讲究了,居然叫"日食",明显是在向SUN公司挑衅,SUN公司的反击也是正常的。
re: 用Myeclipse的理由 匿名 2007-04-18 10:52
偶从03年用eclipse直到去年。因为eclipse越来越慢就忍受不了了。
现在用的是IntelliJ IDEA 。
网络上有一篇比较java ide的文章 ,分别比较了nb idea和eclipse。我觉得说的比较中肯。
nb的优势在ui设计。idea的优势在web开发,eclipse的优势在插件比较多
偶不用eclipse还有一个原因就是eclipse是swt的,这个技术很不好,有使java分裂的嫌疑(其实ibm就是这个干的)。另外其设计也远远比不上swing(偶真的不是有意在鼓吹swing).
另外还有一个很重要的因素jdk事实是掌握在sun手里,eclipse出现以后,sun为了打击eclipse(我觉得打击ms的.net是次要的,因为ms不能从根本上动摇java的根基),狂升级jdk,结果导致java性能狂升。由于eclipse是不标准的,他从这个过程中得到的好处很少(事实上eclipse不得不拼命追赶这个升级的过程) 我们看到eclipse2到eclipse3之间版本和特性发布很快很多质量很好,到了3以后eclipse明显发布速度还是特性升级速度都慢了很多。
最明显的nb从4到5,性能提升了一个数量级(由于jdk的提升),而eclispse的速度却在变慢。。。。。。。
呵呵 一家之言。。。。。
re: 早起20分钟起床,却把时间花费在交通堵塞上 patriotlml 2007-04-14 10:42
北京还差些.sigh.
re: Java IDE与开发工具试用印象 patriotlml 2007-04-14 10:27
好文章.
收藏
数据量太少了,体现不出效果,我曾经做过10000条数量级,当时没有留意Hibernate有batch_size这设置,我是在程序里面控制的(通过嵌套循环),然后用一个配置文件设置一个batch_size,总之原理跟Hibernate设置batch_xize差不多,测试证明,这个数值不是越大、或者越小就有某种趋势,而是应该有一个适合的大小。
如果过大,优点是插入的语句次数小,但缺点是每次事务提交的数据量大,内存占用也厉害。
如果过小,优缺点刚好相反,所以不能笼统的说设置的值越大或者越小就越好,需要测试过,跟进实践情况而定。
忘了说了,我用的是Oracle 10g测的。它是支持batch处理的。
re: 工作中的英语常用语 文林 2007-03-27 15:52
别在意 应该是 never mind 吧,没有 no。
不过 never mind 翻译成 没关系 居多
don't care about 可以翻译成 别在意
误差的英文单词忘记了,等我见到了 给 楼主 补上
现在好了, JDK 都开源了, 就看有没有能耐改了... 根据了解国内做 JVM/JDK 的公司好像还不多.
re: 郁闷,高级开发员居然不喜欢写文档 BeanSoft 2007-03-27 14:07
同感, JavaDoc 和基础的流程, 数据库文档, 必须得有. 至少 JavaDoc 是可以同步产生的, 随时更新的. 看看 JDK 的 JavaDoc(当然实际开发不用这么细) 就明白为啥 JDK 的编码规范被人推崇.