我如何利用Jersey中的supportsNullCreation()?

时间:2015-10-01 00:09:00

标签: java dependency-injection jersey jersey-2.0 hk2

我有一个可注入或可能返回null的注入式提供程序。当它为null时我得到一个异常。我将提供程序注册为Singleton,我是否可以将其注册为一种SingletonContext,我自定义为supportsNullCreation()返回true?我想如果我能做到这一点,那么即使findOrCreate()返回null,我的代码仍然会运行,这就是我想要的。

@ApplicationPath("rest")
public class MyApplication extends ResourceConfig 
{
    public MyApplication()
    {
        ...
    // Provider of DB
    this.register( new AbstractBinder()
    {
       @Override
       public void configure()
       {
 bindFactory(DbManager.class).to(EntityManagerFactory.class).in(Singleton.class);
       }
    });
}

然后就像这样使用:

@Singleton
@Path("myservice")
public class WebServiceClass
{
   // NOTE: Right now I have to comment this to run without a DB
   @Inject
   private EntityManagerFactory entityManagerFactory = null;
   ...

我得到的例外是......

java.lang.IllegalStateException: Context 
 org.jvnet.hk2.internal.SingletonContext@6cae5847 findOrCreate returned a null for 
descriptor SystemDescriptor(
    implementation=com.db.DbManager
    contracts={javax.persistence.EntityManagerFactory}
    scope=javax.inject.Singleton
    qualifiers={}
    descriptorType=PROVIDE_METHOD
    descriptorVisibility=NORMAL
    metadata=
    rank=0
    loader=org.glassfish.hk2.utilities.binding.AbstractBinder$2@7050f2b1
    proxiable=null
    proxyForSameScope=null
    analysisName=null
    id=145
    locatorId=0
    identityHashCode=863132354
    reified=true)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2075)
...

1 个答案:

答案 0 :(得分:2)

我建议稍微更改一下设计。在资源类中使用EntityManagerFactory并不是很好的设计。你留下了像

这样的代码
public class Resource {
    private EntityManagerFctory emf;

    @POST
    public Response get(Entity e) {
        EntityManager em = emf.createEntityManager();
        em.getTransaction().begin();
        em.persist(e);
        em.getTransaction().commit();
        em.close();
    }
}

这张照片有很多问题。对于你正在打破[单一责任原则] [1]。其次,这不允许您优雅地处理null EMF,即使它是可能的。你到处都有这个

if (emf != null) {
    // do code above
} else {
    // do something else.
}

此外,测试并不好。常见的模式是使用DAO层。我个人甚至在DAO和REST层之间添加了一个服务层,但你可以只使用DAO层。

例如,我要做的是为数据访问调用创建一个通用的抽象接口。

public interface DataService {
    Data getData();
}

然后为db access

创建一个实现
public class WithDbService implements DataService {
    private EntityManagerFactory emf;

    public WithDbService(EntityManagerFactory emf) {
        this.emf = emf;
    }

    @Override
    public Data getData() {
        ...
    }
}

然后创建另一个没有数据库访问权限的实现。

public class WithoutDbService implements DataService {
    @Override
    public Data getData() {}
}

然后,您可以使用Factory创建DataService。你要做的是使用ServiceLocator来尝试找到EMF。如果它不为null,则返回WithDbService else返回WithoutDbService

public class DataServiceFatory implements Factory<DataService> {

    private DataService dataService;

    @Inject
    public DataServiceFactory(ServiceLocator locator) {
        // abbreviated for brevity
        EMF emf = locator.getService(EMF.class);
        if (emf != null) {
            dataService = new WithDbService(emf);
        } else {
            dataService = new WithoutDbService();
        }
    }

    @Override
    public DataService provider() { return dataService; }
}
[...]
bindFactory(DataServiceFactory.class).to(DataService.class).in(..);

然后你可以在每个地方注入DataService。只要这两个实现遵循合同,它应该可以正常工作。

可能会有一些设计改进,但直接在资源类中使用EMF是一大步。