Skip navigation

Ondrej Zizka's Blog

March 5, 2013 Previous day Next day

TL;DR: You can't. At least not using the CDI standard. Maybe not even in Weld, not sure. But here's what you can do:

 

Sometimes you might want to create an app which is tolerant to unsatisfied CDI dependencies.

For example, you might want to have optional secondary MailSession which could be used as a fallback.

Basically, any time you want to have something optional and not bother having an extra option like "enableFoo = false".

 

So instead of getting an exception from the deepness of your application server, you would like to detect in your app whether the CDI dep was satisfied or not. Ideally, by having it set to null.

For example:

 

@Inject(nullOnFailure=true) FooBean foo;

 

Well, there's no such feature in CDI.

But there's something you can use:

 

class Bar {

    @Inject Instance<FooBean> foo;

    public doSomething(){
        if( foo.isUnsatisfied() ){
             log.error("Foo was not found!")
             return;
        }
    }

}

My friends are writing a web app. Java EE 6 (JBoss EAP 6.0.1), JPA/Hibernate.

 

DTOs

On other colleague's advice, they don't use collections in Entities at all. Instead, they query for lists of entities and build up DTOs with collections, using multiple calls.

What do you think about this approach? Is it justifiable? Or is it rather about lack of experience with Hibernate?

 

I personally do mixed approach. I use @OneToMany collections whereever needed, even bi-di.

But I try to avoid @ManyToMany, and if there's need for it, I rather create an entity between, or don't map the other side.

 

Bottom-up

Also, since they don't have UI yet, they started creating the service / DAO layers.

They have kind of complete set of CRUDs for all entities.

But in my experience, this leads to a lot of unused code, and what they will really need when building UI won't be there.

Plus, there's a danger of view layer programmers won't ask for the right methods;

instead, they will use existing ones and code the rest in Java code, what will lead to a highly inefficient DB usage.

 

Isn't it better to start coding after you have at least some UI and use cases?

Filter Blog

By date:
By tag: