小编RRR*_*R_J的帖子

为什么我们在许多Java相关API中需要一个默认的无参数构造函数？像一般规则一样,所有java bean类或实体类(JPA等)或JAX-WS实现类都需要显式的无参数构造函数.

如果默认情况下Java提供了无参数构造函数,那么为什么这些标准中的大多数需要显式构造函数？

我试图通过以下示例清除我对Spring Transaction边界的疑虑.

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void test() {    
    test1();
    test2();        
}

@Transactional(propagation=Propagation.NOT_SUPPORTED, readOnly=false)
public void test1() {
    this.jdbcTemplate.execute("INSERT INTO TEST VALUES('T', 'C2', 0, 1)");      
}

@Transactional(propagation=Propagation.SUPPORTS, isolation=Isolation.READ_UNCOMMITTED, readOnly=true)
public void test2() {
    System.out.println(this.jdbcTemplate.queryForInt("select count(*) from TEST"));         
}

我想从test1()中隔离test2()方法,每次调用test()时test2()都不应该读取test1()提交的数据.请建议是否可以使用传播或隔离属性来处理此场景.

提前致谢.

我们的项目中有以下代码,虽然它工作正常但随机我们在运行时得到class def not found错误.我们的App服务器在每个星期日重新启动,因此有时我们会在任何随机服务器实例上收到此错误.服务器重启解决了问题,但任何线索都是为什么类加载中断.

我在这个问题上有一些类似的错误,似乎问题已在jdk 9中修复了.JR8中的lambdas转换

但在我得出结论之前,有人可以解释它是同一种错误,以及为什么偶尔会发生这种错误.

public boolean isAttachmentExpired(final Document_Attachment da) {
    return this.bcDocumentScreen.getValidator().getAttachmentsValidator().isAttachmentExpired(da);
}

public boolean isAttachmentWarningShown() {
    return CollectionUtils.isNotEmpty(getAttachments()) && getAttachments().stream().anyMatch(this::isAttachmentExpired);
}

public boolean isAttachmentExpired(final Document_Attachment da) {
        final Date today = DateHelper.today();
        return DateHelper.diffInYears(today, da.getUploaded()) >= 1;
    }

错误:-

Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor1913.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.persistence.ManagedEntityInterceptor.aroundInvoke(ManagedEntityInterceptor.java:48)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196) …