I am learning Spring Webflux. In some code samples they add a org.springframework.data.r2dbc.repository.config.EnableR2dbcRepositories annotation to the main class [example]
#SpringBootApplication
#EnableR2dbcRepositories
public class SpringReactiveApplication {
public static void main(String[] args) {
SpringApplication.run(SpringReactiveApplication.class, args);
}
}
and in others they don't [example]. I have tried it both ways with no difference in the result. So I am trying to understand when do we need this annotation and when we don't?
There is another annotation that I have seen some examples use and other's don't. That is org.springframework.stereotype.Repository. In some examples [e.g.] I see:
#Repository
public interface CustomerRepository extends
ReactiveCrudRepository<Customer, Long> {
others don't use it. so asking same question for this annotation as well.
#SpringBootApplicaton is the combination of #EnableAutoConfiguration, #ComponentScan and #Configuration annotations.
#EnableAutoConfiguration enables Spring Boot's auto-configuration mechanism.
By annotating classes/interfaces with #Repository annotation we make
clasess/interfaces available for auto-detection during auto-configuration.
Therefore, by default Spring Boot tries to guess the location of #Repository definitions as long as the interfaces are located in the same package or sub-package.
But if the repositories are outside of SpringReactiveApplication located package we need register repository beans to the context using #EnableR2dbcRepositories. We will also get more control by using the #EnableR2dbcRepositories.
For the interfaces that extend ReactiveCrudRepository it's not necessary to put #Repository annotation on them. Because Spring Boot recognizes the repositories by the fact that they extend one of the predefined Repository interfaces.
Related
I have two different #Service classes that use the same methods.
I have extracted those methods in a separate class, that both will reference. To be able to access those methods, I added them to the companion object of the class, but the issue is that they use external services in their implementation, which I cannot wire in a companion object or pass it and access it there.
class CommonMethods {
companion object {
fun firstValidationField(input: User) {
// logic
input.timezone = userRepository.getTimezone(input.userId)
return input
}
etc
}
}
What is the best way to inject userRepository to this class so I can access it and have the common methods work for both external service classes?
I had these methods in the service class, so autowiring repositories there wasn't an issue. But extracting them as they are common, not sure how to approach this.
I use #Autowired to inject it
If firstValidationField() is really so simple as you wrote in the question, you can inject the userRepository in your both services, and userRepo.getTimeZone(..) that's it.
However, if the method impl. is more complex than that, or there are other commonly used methods, I would suggest wrapping those methods in an additional #service, say UserService, and inject the UserService into your other #services.
Usually, Util classes are not designed to be instantiated, it contains mainly static method calls. IMO, "Injecting" objects to a Util class isn't the right direction to go.
I've read what the annotation says but I'm kinda dumb, so couldn't understand propertly
Identifies injectable constructors, methods, and fields. May apply to static as well as instance members. An injectable member may have any access modifier (private, package-private, protected, public). Constructors are injected first, followed by fields, and then methods. Fields and methods in superclasses are injected before those in subclasses. Ordering of injection among fields and among methods in the same class is not specified.
Can you explain me what is #Inject for? If it is possible with a real life analogy with something less abstract
#Inject is a Java annotation for describing the dependencies of a class that is part of Java EE (now called Jakarta EE). It is part of CDI (Contexts and Dependency Injection) which is a standard dependency injection framework included in Java EE 6 and higher.
The most notorious feature of CDI is that it allows you to inject dependencies in client classes. What do I mean by dependencies? It is basically what your class needs to do whatever it needs to do.
Let me give you an example so that it is easier to understand. Imagine that you have a class NotificationService that is supposed to send notifications to people in different formats (in this case, email and sms). For this, you would most probably like to delegate the actual act of sending the notifications to specialized classes capable of handling each format (let's assume EmailSender and SmsSender). What #Inject allows you to do is to define injection points in the NotificationService class. In the example below, #Inject instructs CDI to inject an EmailSender and SmsSender implementation objects via the constructor.
public class NotificationService {
private EmailSender emailSender;
private SmsSender smsSender;
#Inject
public NotificationService(EmailSender emailSender, SmsSender smsSender) {
this.emailSender = emailSender;
this.smsSender = smsSender;
}
}
It is also possible to inject an instance of a class in fields (field injection) and setters (setter injection), not only as depicted above in constructors.
One of the most famous JVM frameworks taking advantage of this dependency injection concept is Spring.
The task is to hide Library1 interface1 behind the facade of Library2.
Full source here https://bitbucket.org/tim4dev/inheritance-interfaces/src/master/
(Library1) interface1
(Library2) interface2 : interface1
(Library2) Klass2: Interface2
(application)
implementation project(":library2")
class KlassApp constructor(
private val klass: Interface2
) {
fun klassAppFun() {
klass.interface1fun1()
}
}
We get an error
KlassApp.kt: Unresolved reference: interface1fun1
Question: what are the standard patterns to hide Library1 behind the facade of Library2 ?
You need to choose:
make Library1 an api dependency of Library2, not implementation as you currently have it (so not hide it fully);
if you want to hide it, you can't expose any types of Library1 in public parts of Library2, which includes extending its interfaces.
See the documentation for the difference of api and implementation:
So when should you use the api configuration? An API dependency is one that contains at least one type that is exposed in the library binary interface, often referred to as its ABI (Application Binary Interface). This includes, but is not limited to:
types used in super classes or interfaces
types used in public method parameters, including generic parameter types (where public is something that is visible to compilers. I.e. , public, protected and package private members in the Java world)
types used in public fields
public annotation types
I would like to register the following items for DI using an open generic implementation and interface. I know the following example will not work, as well as other combinations I've tried with MakeGenericType, or GetGenericArguments. I would like to simply call AddRepository<MyDbContext> and then be able to inject my implementation into classes without explicitly having to register the type I am using.
Interface
public interface IRepository<TEntity>
{
}
Implementation
public class Repository<TEntity, TContext> : IRepository<TEntity>
where TEntity : class
where TContext : DbContext
{
}
Registration
public static class RepositoryServiceCollectionExtensions
{
public static IServiceCollection AddRepository<TContext>(
this IServiceCollection services) where TContext : DbContext
{
services.TryAddScoped(
typeof(IRepository<>),
typeof(Repository< , TContext>));
return services;
}
}
The dependency injection container Microsoft.Extensions.DependencyInjection and its abstraction layer does not support open generic factories. So you generally cannot achieve what you would like to do there. There’s also no support planned.
Unlike many those other dependency injection related features, this is also not really possible to patch by just providing the right wrapper or factory types. So you will actually have to change your design here.
Since you want to resolve IRepository<TEntity> and the only way to do this is by registering an equivalent open generic type, you will have to have some type Repository<TEntity> that implements your repository. That makes it impossible to retrieve the database context type from the generic type argument, so you will have to use a different way here.
You have different options to do that. For example, you could configure your Repository<TEntity> (e.g. using M.E.Options) with the context type and make that resolve the Repository<TEntity, TContext> dynamically. But since you have actual control over your database context, I would suggest either adding a marker interface or introducing another type for the context which you can then register with the container:
public class Repository<TEntity> : IRepository<TEntity>
{
public Repository(IDbContext dbContextFactory)
{ … }
}
public class MyDbContext : DbContext, IDbContext
{ … }
Then, your extension method could look like this:
public static IServiceCollection AddRepository<TContext>(this IServiceCollection services)
where TContext : DbContext, IDbContext
{
services.AddTransient(typeof(IDbContext), sp => sp.GetService<TContext>());
services.TryAddScoped(typeof(IRepository<>), typeof(Repository<>));
return services;
}
Of course, this changes how your Repository implementation works, but I don’t actually assume that you need to know the TContext type other than to inject the database context type. So this will probably still work for you.
That being said, I have too agree with Chris Pratt, that you probably don’t need this. You say that you want to introduce the repository, because “coding stores and implementations for every entity is a time consuming task” but you should really think about whether you actually need that. A generic repository is very limited in what it can do, and mostly means that you are doing just CRUD operations. But exactly that is what DbContext and DbSet<T> already do:
C: DbContext.Add, DbSet<T>.Add
R: DbContext.Find, DbSet<T>.Find
U: DbContext.Update, DbSet<T>.Update
D: DbContext.Remove, DbSet<T>.Remove
In addition, DbContext is a “unit of work” and DbSet<T> is an IQueryable<T> which gives you a lot more control and power than a generic repository could possible give you.
You cannot have a partially open generic reference. It's all or nothing. In other words, you can try:
services.TryAddScoped(
typeof(IRepository<>),
typeof(Repository<,>));
But, if that doesn't work, you'll likely need to add a type param to your AddRepository method:
public static IServiceCollection AddRepository<TEntity, TContext>(this IServiceCollection services)
where TEntity : class
where TContext : DbContext
{
services.TryAddScoped(
typeof(IRepository<TEntity>),
typeof(Repository<TEntity, TContext>));
return services;
}
Of course, I think that breaks what you're ultimately trying to achieve here: registering repositories for all the entity types in one go. You can always use a bit of reflection find all entities in your assembly (they would need to share something in common: base class, interface, etc.) and then enumerate over them and use reflection to call AddScoped on your service collection for each.
All that said, the best thing you can do here is to actually throw all this away. You don't need the repositories. EF already implements the repository and unit of work patterns. When you use an ORM like EF, you're essentially making that your data layer instead of a custom class library you create. Putting you own custom wrapper around EF not only adds entropy to your code (more to maintain, more to test, and more than can break), but it can also mess up the way EF works in many cases, leading to less efficiency in the best cases and outright introducing bugs into your application in the worst cases.
I'm in a situation where the implementation of a library we are using is newer than the implementation one of our dependencies was coded against. E.g. Dependency uses MyLibrary-1.0 and we're using MyLibrary-2.0.
In the newer implementation a deprecated method has been removed, which causes run-time errors for us.
I'm trying to use AOP (Spring-AOP to be specific) to intercept calls made to the missing method, and proxy them into an existing method... but I can't seem to get the Aspect right.
It feels like Java is raising the 'java.lang.NoSuchMethodError' exception before my Aspect has an opportunity to intercept. Is there some trick I'm missing, or is this just not feasible (e.g. the method must exist in order to aspect it)?
#Before("execution(* com.mylibrary.SomeClass.*(..))")
Fails with java.lang.NoSuchMethodError
#Around("target(com.mylibrary.SomeClass) && execution(* missingMethod(..))")
Fails with java.lang.NoSuchMethodError
Assuming that your are talking about a 3rd party library which is independent of Spring, you cannot use Spring AOP with its proxy-based "AOP lite" approach which only works for public, non-static methods of Spring components. Please use the more powerful AspectJ instead. The Spring manual explains how to integrate full AspectJ with load-time weaving (LTW) into Spring applications. If your application is not based on Spring so far and you just wanted to use the framework because of Spring AOP, you can skip the whole Spring stuff altogether and use plain AspectJ.
The feature you want to use is an inter-type declaration (ITD), more specifically AspectJ's ability to declare methods for existing classes. Here is some sample code:
3rd party library:
package org.library;
public class Utility {
public String toHex(int number) {
return Integer.toHexString(number);
}
// Let us assume that this method was removed from the new library version
/*
#Deprecated
public String toOct(int number) {
return Integer.toOctalString(number);
}
*/
}
Let us assume that the method I commented out was just removed from the latest version your own project depends on, but you know how to re-implement it.
Project dependency depending on old version of 3rd party library:
package com.dependency;
import org.library.Utility;
public class MyDependency {
public void doSomethingWith(int number) {
System.out.println(number + " in octal = " + new Utility().toOct(number));
}
}
Because the previously deprecated method Utility.toOct does not exist anymore in the version used by your own project, you will get NoSuchMethodError during runtime when calling MyDependency.doSomethingWith.
Your own application:
package de.scrum_master.app;
import org.library.Utility;
import com.dependency.MyDependency;
public class Application {
public static void main(String[] args) {
System.out.println("3333 in hexadecimal = " + new Utility().toHex(3333));
new MyDependency().doSomethingWith(987);
}
}
As you can see, the application also uses the same library, but a different method which still exists in the current version. Unfortunately, it also uses the dependency which relies on the existence of the removed method. So how should we repair this?
Aspect using ITD:
AspectJ to the rescue! We just add the missing method to the 3rd party library.
package de.scrum_master.aspect;
import org.library.Utility;
public aspect DeprecatedMethodProvider {
public String Utility.toOct(int number) {
return Integer.toOctalString(number);
}
}
If you compile this project with the AspectJ compiler Ajc, it just works. In your real life scenario, compile the aspect into its own aspect library, put the weaving agent aspectjweaver.jar on the JVM command line in order to activate LTW and enjoy how it weaves the method into the library class via byte code instrumentation during class-loading.
Log output:
3333 in hexadecimal = d05
987 in octal = 1733
Et voilà! Enjoy. :-)
When the JVM load a class, it resolves all dependencies in a "linker" phase : external classes, properties and method. You can't pass this phase in your case, because methods are missing.
There are two modes on (Spring-)AOP: Proxy, and weaving.
Proxy create... a proxy around a class: the targeted class must exist and be loaded
Weaving can happen before a class is loaded: when a classloader load a class, an array of byte[] is passed to the weaver, which can manipulate the class bytecode before the class is really reified. This type of aop can work in your case. However, it will not be an easy task.