I am working on a webapp which uses Primefaces as a view, and I inject Spring beans from other projects into JSF Managed beans.
I have an architectural problem:
I've created separate projects(modules) for each component that I use (Business Logic, Persistence, and others) and also create separate projects with their interfaces.
I want my webApp to depend only on the interface of the Business Logic, and to inject the implementation of the BL using Spring Dependency Injection.
I want to achive this recursively: Business logic to depend only on other interfaces, and to inject implementations using spring.
The problem is that having no dependency in the Maven pom file to the actual implementations, when I deploy the application (on a web logic server) the implementation jars are not deployed, and Spring doesn't find the beans to wire.
Is there a way to achieve decoupling without adding dependencies to actual implementations?
Can I include Spring's bean configuration files from other projects if the projects are not added as dependencies?
Did I figured this decoupling all wrong?
I appreciate your ideas.
Well obviously you need the dependencies in your maven pom else nothing will be included. You can add the dependencies with a scope of runtime which includes them in your final war but not during development (scope compile).
For loading the context of modules you might come-up with a naming convention and/or standard location for your files. With that you could do something like this in your web applications beans xml
<import resource="classpath*:/META-INF/spring/*-context.xml" />
This would load all files ending with -context.xml from the /META-INF/spring directory on the classpath (including jar files).
Related
Currently, I am working on a Spring MVC project and want to divide the project to smaller modules. I have been searching for the info and found this page. Although this page describes how to build multiple maven module but I think it lacks of configuration information such as: how can I load persistence.xml to my persistence module? How can I read my applicationcontext.xml in service module? In my original code, the web.xml will locate and load the persistence.xml and applicationcontext.xml, but maven module doesn't have web.xml. So do I have to build java configuration class for each module? If anyone can provide basic information of working with multiple maven modules and Spring MVC, I am really thankful for that.
Assuming that the whole purpose of creating multiple modules for your project is to isolate the code by its functional parts, then yes, you will want to have separate config files for each deployable instance. This means that the only place (outside tests) where config files/classes will exist in your project, will be in your web app. Since your web app is likely using your other modules as dependencies packaged as JARs, config files in those JARs would not be very convenient.
Note: It is possible to bake config files into your other modules, but in my experience, this only causes confusion and headaches down the road.
Are there any differences in capabilities of the EJB when defining / running it from a WAR vs. an EJB container? What are the benefits vs. drawbacks of deciding on one approach vs. other.
What capabilities do we lose when accessing it from a WAR?
In our case, the developers want to use the EJB for creating / accessing REST webservice.
One of our architects has mentioned below. And for this reason he wants to have a separate EJB that would be added ( the jar ) to EAR but also to WAR for using it as REST endpoint. i would prefer not to have it in multiple places
I’d prefer our approach to put transaction/service based code in EJBs to
leverage Container Managed Transactions, JPA, MDB and all the good stuff EJBs
have to offer.
From the documentation I have read on using EJB as a REST service implementation, it says
Add the EJB class to the WEB-INF/classes directory of your WAR file or to a
JAR that is located in your WEB-INF/lib directory. When a client makes a request
to a JAX-RS annotated enterprise bean, the JAX-RS runtime environment looks up
and uses an EJB instance of the class to invoke the resource method.
So, I want to know, if we put the EJB in the WAR - as in creating the source in the WAR's source so that the class will be added to WEB-INF/classes when the WAR is built, instead of having to put the same ejb jar in two different places based on what it is used for - as a REST webservice endpoint vs. other capabilities, will it satisfy all the requirements or I will have to put the jar in two places?
I am using Websphere 8.5 with EJB 3.1, if that makes a difference in the answer.
There are two primary differences highlighted in section 15.4 of the EJB 3.1 specification:
All EJBs in a WAR share the component namespace (java:comp) with the WAR and all other EJBs in the WAR. Normally, each EJB has its own component namespace. This makes it easier to share reference names and bindings (though this can be done explicitly in EE 6 with java:module or java:app), but it increases the chance of conflict in a large WAR.
EJB classes are loaded by the WAR class loader. In practice, this doesn't matter much, it's just something to be aware of if you encounter class loading problems.
If you want to use an EJB as a REST service, you must package the EJB in the WAR. If you're concerned about "duplicating" EJB logic inside the WAR and for an EJB module, you could declare a base class in the EJB module, and then declare subclasses in the WAR and EJB modules that extend the base class and are annotated #Stateless or #Singleton.
Regarding EJB capabilities there is no difference between packaging an EJB in a WAR or in an EJB module.
There are situations where you have to package EJBs in WARs e.g. if you have a REST endpoint which is at the same time an EJB.
Most often WARs encapsulate frontend functionality. In these situations it is just from a design perspective not advisable to put the EJBs into WARs.
In the project our team's working on, we currently have 3 separate Spring projects which utilizes the same services. To avoid redunancy and code copy-pasting, we're planning to create a "common" project wherein all the three projects would be dependent on the common project. In this instance, is it possible to inject these services (perhaps using the #Service annotation) to the Controllers of the Spring projects?
EDIT:
I tried implementing this on my own and what I basically did was I configured the pom.xml to get the Spring Context 3.1.1 dependency (which are also being used by my Spring projects) for my "common" project. With that, I was able to annotate my service with #Service. Afterwards, on my Spring project, I set the component-scan to a level wherein my two projects would meet. On my Spring controller, I #Autowired the service from the "common" project. I ran the Spring project and apparently it worked. Is this the best way to do this?
That's absolutely fine, and standard. Spring (unlike CDI) couldn't care less whether your beans come from the current project or from an imported jar.
I was able to determine what I needed to do to get my interceptor working; however, I don't understand why I had to do that. All of the projects I am using my interceptor project in are either jar / war and CDI-enabled.
I thought CDI covered both EJB beans, regular POJO beans, properties, and anything resolveable via EL. And ... that to register an interceptor for CDI beans, I could simply declare it in beans.xml. None of my projects are EARs.
Now that I have it working by building the project as an ejb-jar, that is the main thing, but am I wrong in thinking it should work in beans.xml alone and building the project as just a regular jar?
Please point me to any documentation that specifies this clearly, everything on oracle's site indicates beans.xml should suffice.
Walter
Hello I am new to the Spring and maven world, and I want to know what is the difference between this 2 dependencies?
Its a simple question.. I am having trouble with my pom.xml file, so I want to know everything :).
Thanks in advance.
These are actually 2 of many Spring Framework modules. You can easily find what packages these artifacts contain, using this site:
http://mvnrepository.com/artifact/org.springframework/spring-core/3.1.1.RELEASE
This can give you information about classes contained within a particular artifact and probably about the its purpose.
For Spring Framework, spring-core contains mainly core utilities and common stuff (like enums) and because it's really critical for Spring, probably all other Spring modules depend on it (directly or transitively).
In turn spring-context provides Application Context, that is Spring's Dependency Injection Container and it is probably always defined in POMs of artifacts that use Spring Framework somehow. In fact, spring-context depends on spring-core so by defining spring-context as your dependency, you have spring-core in your classpath as well.