2018-01-07 21:06

是由于 jfinal 3.3 将 configPlugin() 方法提到 configRoute() 之前调用造成的,最简单的解决办法是在 src/main/resources 目录下面创建一个 com.jfinal.core 的包,然后将 com.jfinal.core.Config.java 代码 copy 到那个包里,将 configRoute() 这行代码向前挪一个位置

jfinal 3.4 会解决这个问题

2018-01-07 17:24

你用的 tomcat 与 windows 太老了,难免有些问题,这个问题确实很诡异,感谢你的分享

我有一个与客户对接的 jfinal API 项目在阿里云上跑了快两年,从来没重启过。客户自己对接的部分死了都不知到多少回了,问我的系统为啥这么稳,我说我用的 jfinal

2018-01-07 17:08

异常来看是 jetty 版本不对,使用 jfinal 官方提供的 jetty 版本,否则的话也可以使用传统的 Jetty 启动方式来代替 jfinal 整合的启动方式

2018-01-07 17:06

使用下面的方法配置一下:
arp.getEngine().setSourceFactory(new ClassPathSourceFactory());

上面的配置可以去 classPath 以及 jar 包中去加载 sql 文件,而 StackOverFlowError 应该是你的 sql 模板文件有循环引用而造成的,例如 A include B,而 B include C,再 C include B ,这样造成了死循环

仔细看一下 jfinal 手册中有关最佳实践的描述

2018-01-06 20:12

@shan 是你当前正配置的这个 controller 的 viewPath,这个 viewPath 与前面配置的 baseViewPath 是不同的,最终的 path 为;
finalPath = baseViewPath + viewPath + view

baseViewPath 与 viewPath 在项目启动的时候会一次性拼接好,性能会尽可能地高

2018-01-06 19:31

期待开源

2018-01-06 19:30

感谢分享

2018-01-06 19:28

add("/aaa", Dbtest.class); 改成:add("/aaa", Dbtest.class, "/");

add 方法如果省略第三个参数,默认与第一个参数相同,所以:
add("/aaa", Dbtest.class); 与 add("/aaa", Dbtest.class, "/aaa"); 完全等价

2018-01-06 19:25

看下手册模板引擎有关《原样输出》 这一章节,像下面这样解决:
#[[
layUI 或者任意代码
]]#

2018-01-06 19:24

@jasun 现在用一下 @Before(NotAction.class) 拦截器也可以

2018-01-05 20:10

看一下 CacheInterceptor 中的代码,再扩展一下这个拦截器即可

2018-01-05 18:18

通过 arp.setShowSql(true) ,将 sql 输出到控制台,看一下有啥问题

2018-01-05 14:33

然后,使用不同的 layout,只需要调用不同的函数就可以了,例如前端界面调用:
#@frontLayout()

后端界面调用:
#@adminLayout()

2018-01-05 14:32

当然可以,多次调用 engine.addSharedFunction(...) 添加多个layout 文件进去即可,为不同的 layout 文件中的函数取不同的名字,例如:
#define frontLayout()
...
#end

#define adminLayout()
...
#end

2018-01-05 11:29

如果你的模板在 class path 或者jar 包之中,配置一下:
Engine.use().setSourceFactory(new ClassPathSourceFactory());

如果不是的话,配置一下这个:
Engine.use().setBaseTemplatePath(....);