I am building a multi module Spring Boot project.
The intent is not to deploy several applications which share code, but rather to have one application where code relevant to different sections of the business are split into separate jars.
The parent project has <packaging>POM</packaging>.
The modules underneath the parent have <packaging>JAR</packaging>.
The parent pom includes as dependencies each of the modules.
One of modules has the main class which is annotated with #SpringBootApplication
This loads the Spring context correctly, and this class can access classes in other modules\jars when the application is built and run.
However, Spring does not instantiate components located in other modules, annotated (in this instance) with #Endpoint and #Configuration, and their constructors are not being called when the application starts.
The package names in the other modules shares the same structure, so #Components there should be be picked by by the scanBasePackages declaration in the main class which starts the Spring context.
Is there a way to do this?
Thanks
Related
(This is primarily a history question. Pivotal recommended that all forum discussions take place on StackOverflow, which is why I am asking it here.)
What are the reasons that the Spring Boot project used to justify moving an application's classes and dependencies from the "top level" of the executable jar format to be underneath BOOT-INF/?
Just trying to guess, it seems that this makes it easy to extract only the application-related classes and jars from the fat jar with a simple java -xf the-jar.jar BOOT-INF/classes command. Was that it? Was there some other reason?
TL;DR
Packaging application classes in the root of the jar required Spring Boot's class loader to use an unconventional delegation model and also caused problems with Java agents.
Detailed explanation
When a jar file is launched with java -jar all of the classes in the root of the jar are on the class path of the system class loader. In a Spring Boot fat jar, this includes the classes for the launcher which is responsible for creating a class loader that can load the application's classes and their dependencies that are nested inside the fat jar.
In Spring Boot 1.3 and earlier, application classes are packaged in the root of a fat jar file. This means that they are on the class path of the system class loader. With a standard, parent first delegation model this would mean that application classes would be loaded by the system class loader rather than Spring Boot's class loader. This is problematic as it's only Spring Boot's class loader that can load the classes from the dependencies that are nested inside the fat jar. The result being that the application cannot load the classes of any of its dependencies.
Spring Boot 1.3 overcame this problem by using an unconventional delegation model for its class loader. It created a new class loader using the URLs from the system class loader but not using the system class loader as a parent – the system class loader's parent was used instead. This meant that Spring Boot's class loader would be used to load the application's classes in the root of the jar and the classes of the application's dependencies in the nested jars.
This approach had some drawbacks. The first was that it made Spring Boot's class loader rather complex. The second was that it broke a number of assumptions that Java agents make with regards to how their classes will be loaded. We worked around a couple of these but it became clear that we were fighting a losing battle.
Spring Boot 1.4 rearranges a fat jar to place application classes in BOOT-INF/classes (it also moves nested jars to BOOT-INF/lib but that has no effect from a class loading perspective). Moving the application classes into BOOT-INF/classes means that they are no longer on the class path of the system class loader. This means that Spring Boot's class loader can be configured to load classes from BOOT-INF/classes and from within the jars in BOOT-INF/lib and use the system class loader as its parent. Java agents can be packaged in the root of the jar from where they'll be loaded by the system class loader as usual.
For further reading you may be interested in the message on the commit that introduced the change and the other issues to which it links.
I have spring maven multi module project, in that I have more modules, these modules consists of dao, domain, service, and controllers. I have separate application context XML file for each modules. Controllers in the modules are not working, but controllers present in the web module is working. I had given #Controller in the controller class, and mvc:annotation-driven and context:component scan tags in the spring application context file. Why is it not working?
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.
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).
I'm working on a recently mavenized legacy project with following multi-modular structure:
Parent:
Web
Service
Dao
("Service" module is dependent on "Dao" module)
Problem: some tests of Service classes call DAO code that creates beans using Spring's ClassPathXmlApplicationContext (this part is not really DAOs but caching related). Since, ClassPathXmlApplicationContext uses spring config xml of the DAO module - the Service tests fail throwing FileNotFoundException. I think this is because tests run in Service module and the spring config xml being referred lies in Dao module.
Please advise on how can I resolve the above issue in tests referring to code/resources of other modules?
Put a copy of the Spring configuration under src/test/resources in the Service module. Quite often you want a different configuration for testing anyway, but also it means your tests are less dependent on configuration changes in another module.