Reputation: 19729
Due to our requirements, we will have views and usecases that are deployment specific. Deployments will have generic and deployment specific parts (beans). This means that we would probaly need one context.xml file that would contain the generic beans for all deployments, and then deployment specific deploymentContext.xml for each deployment. This means that some POJOs exists in one deplyment, but not the other.
My questions: 1) is it possible to have deployment specific context files to extend the generic context file? 2) is it possible to describe a class in the deployment specific context file, that already exists in the generic context file? I.e. It would override the bean described in the generic context file, as in class inheritance. 3) is the approach described above feasible, or should the build descriptor instead dynamically generate the context.xml file? I would prefer the extension approach... 4) if I deploy all deployment specific contexts, but remove some of the POJO classes from the src directory, will the application break upon deployment or only after I try to instantiate the bean that does not exist?
Thanks a lot!
Upvotes: 0
Views: 91
Reputation: 240948
Not exactly the way you are asking, But Use of @Profile
suits here
@Profile("dev")
public class SomeBean{
}
This bean will be only come to action if the profile set is dev
Document
Also See
Upvotes: 3