I am designing/implementing an app for various deployment conditions,
based on the Spring Profile the app will either be integrated with SQL or NoSQL,
various vendors, but some use-cases are not compatible, so right now I have a solution with a dummy
implementing class, but I am not sure that this is the right way.
Is there a clean-er way? Throw an exception? If so, how, if I need an impl. when compiling?
Thanks.
Related
Spring boot 2.1.5
Project Reactor 3.2.9
I am setting up a bunch of rest reactive APIs using the above-mentioned frameworks and I am running into an annoying problem with MDC (mapped diagnostic context). My applications are in JAVA.
MDC relies on thread locals to store the current query's mapped context to put in the logs. That system, obviously, is not perfect and contradicts the reactive pattern since the different steps of your execution will be executed through different threads.
I have run into the same problem with the Play Reactive framework but found a workaround there by copying the mapped context transparently from one actor to another.
For spring and reactor, I could not find a satisfying solution yet.
Some random examples found on the internet:
First - It works but forces you to use a bunch of utility methods
Same thing
Second - It tries to copy the context during the onNext publisher event but seems to lose some features on the way of doing that. The signal context, for example, is lost.
I am in need of a proper solution to deal with this:
A library which would make the link between MDC and reactor?
A way to tweak reactor/spring to achieve it transparently?
Any advice?
"I could not find a satisfying solution yet."
Working with contexts is the only solution for the moment. Since as you said threadlocals goes against everything that has to do with reactive programming. Using thread local as a storage point during a request is a resource heavy way of solving things and in my opinion poor design. Unless logging frameworks themselves come up with a better solution to the problem we developers must pass the data through the context to accommodate for the logging frameworks blocking nature.
Reactive programming is a paradigm shift in the programming world. Other things like database drivers, that use threadlocal to rollback transactions are also in big trouble. the JDBC database driver spec is defined as blocking in nature, and atm. there has been attempts by spring and the R2DBC project to define a new JDBC driver spec that is inherently non/blocking. This means that all vendors must rewrite ther database driver implementations from scratch.
Reactive program is so new that lots of libraries need to rewrite entire codebases. The logging frameworks as we know it needs to be rewritten from the ground up which is a huge task. And the context in reactive is actually something that should not even be in reactive programming, it was implemented just to accommodate for MDC problems.
It's actually a lot of overhead needing to pass data from thread to thread.
So what can we do?
push on logging frameworks, and/or help logging frameworks to rewrite their codebase
Accept that there is no "tweak" that will magically fix this
use the context and the way suggested in the blogposts
Project reactor context
I'm building application at top of the Laravel. In my Domain layer I have services. One of these needs to send an EMail. Laravel has Illuminate\Mail package for these purposes.
But Mailer contract depends on \Illuminate\Mail\PendingMail class.
https://github.com/laravel/framework/blob/5.7/src/Illuminate/Contracts/Mail/Mailer.php
Does it mean I need to write my own interface (port) for my Domain layer to fully decouple my application from framework?
To be honest, I'm not sure what you are asking. But I'll try to answer anway.
If you use (any) framework functionality directly in your code, you obviously couple your application to the framework. That's the whole point of a framework. It offers you a lot of functionalities that are commonly used throughout different types of applications. It can be seen as foundation for an applciation. These functionalities are often made available through interfaces, so that the implementation can be swapped out if necessary. Swapping out the implementation doesn't make your application less coupled to the framework though. It just allows you to use a different kind of implementation; the interface will still be a framework one.
So, the only way to prevent (heavy) coupling with a framework would be to write your own interfaces that abstract all the framework functionalities. You could then have proxy classes that implement these new interfaces and do nothing else than proxying requests to the proper functions of the framework, allowing you to write other proxy classes in future for a different framework.
If you ask me, this sounds like a bad idea though. Because in the end, you are building your own framework based on your own interfaces. So you are using additional custom code which adds no additional functionality, but comes with the added risk of bugs and errors.
I m a newbie & i m good at Struts framework. Today i tried a tutorial for Spring MVC Framework.
The example url that i tried following is as below:
http://static.springsource.org/docs/Spring-MVC-step-by-step/part6.html
I think they have made this tutorial much more complex especially near its end. I saw some errors mainly typos in part 5, part 6 of tutorial. I found Spring framework as not properly organized and how would we know what classes to extend especially when their names are so weird (pardon my language) e.g. AbstractTransactionalDataSourceSpringContextTests.
Overall i found that Spring is making things much more complex than it should be. I'm surprised why there is such a hype about Springs being very easy to learn.
any suggestion how to learn spring easily ? how to judge what to extend ? is there a quick reference or something?
The tutorial you have referred to covers all the layers of the application - data access, business logic and web. For someone who is looking to only get a feel of Spring MVC, which addresses concerns specific to the web layer of the application, this could be more information than required. Probably that is why you got the feeling that the tutorial is complex.
To answer your questions, Spring is easy to learn because the whole framework is designed to work with POJOs, instead of relying on special interfaces, abstract classes or such. Developers can write software as normal Java applications - interfaces, classes and enums and use Spring to wire the components up, without having to go out of the way to achieve the wiring. The tutorial you have referred to tries to explain things in a little bit more detail than experienced programmers would typically do in a real application, probably because the authors wanted the readers to get enough insight into how Spring works so that concepts are understood well.
In most applications (regardless of their size or nature), there is typically no need to extend Spring classes or to implement specialised classes. The Spring community is quite large and an even larger ecosystem of readily available components exists that integrate with Spring. It is therefore very rare that one has to implement a Spring component to achieve something. For example, let us take the example of the data access layer. Different teams like using different approaches to accessing databases. Some like raw JDBC, others like third-party ORMs like iBatis or Hibernate while some others like JPA. Spring distributions contain classes to support all these approaches. Similarly, lets say someone was looking to incorporate declarative transaction management in their application. Again, transaction management can be done in many different ways and a large number of transaction management products are available for people to use. Spring integration is available for most of these products, allowing teams to simply choose which product they want to use and configure it in their Spring application.
Recent Spring releases have mostly done away with extensive XML based configuration files, which being external to the Java code did make Spring application a bit cumbersome to understand. Many things can be done nowadays with annotations. For example,
#Controller
public class AuthenticationController
{
...
}
Indicates that AuthenticationController is a web MVC controller class. There are even ways to avoid using the Controller annotation and follow a convention-over-configuration approach to simplify coding even further.
A good and simple tutorial to Spring MVC is available at http://www.vaannila.com/spring/spring-mvc-tutorial-1.html. This tutorial uses XML based configuration for Spring beans instead of annotations but the concepts remain the same.
I have seen tutorial you follow , Its seems you have follow wrong one first , you first tried to simple one, Instead of tutorials you should go for book first
I recommend you two books to understand the power of Spring
spring in action and spring recipes.
For practical you can use STS a special ide for spring project development.Its have some predefined template you dont't need to write whole configuration yourself.
In starting just see simple tutorials like Spring mvc hello world , form controller than go for big ones
Spring is very cool , All the best.
We are writing a new set of services and have decided to make them share a common interface... calling it a BaseService. The idea is that whenever anyone wants to develop a new service in our organization, they should be just able to extend and use this BaseService.
We have written a few other classes which also form a part of this base jar, it does things like handle transactions and connect to database using hibernate etc.
Right now all the services that extend the BaseService are a part of the same project (Eclipse + Maven), and some of the services are dependent on each other, but because they are in the same project we don't have a problem with dependencies.However, we expect 40-50 services to be written which would extend base service and would also be interdependent.
I am worried that the size of the base project would be huge and that just because when someone has to use one service they might have to depend on my base jar which has 50 services.
Is there a way that we can make some projects dynamically dependent on others?
Lets say I have a service A which depends on service B, when I build/compile Service A,it should be able to realize that it has a dependency on service B and automatically use the Service B jar.
I have heard of OSGi, will it solve my problem or is there a way I can do it with Maven or is there a simpler solution ?
Sorry about the long post !
Thanks in advance for your suggestions
It doesn't make any sense to "dynamically" manage project dependencies, since build dependencies are by definition not dynamic.
Your question, at least for the moment, seems to be entirely about how to build your code rather than about how to run it. If you are interested in creating a runtime system in which new service implementations can be dynamically added then OSGi may be the solution to look at. An extra advantage here would be that you could enforce the separation of API from implementation, and prevent the implementing services from invalidly depending on parts of your core module that you do not want them to have visibility of.
You could also use OSGi to manage evolution of your core service API through versioning; for example how do you communicate the fact that a non-breaking change has been made to the API versus a breaking change etc.
I would say there are two options depending if i understand your question correct. First one. You have already defined an interface (java term) and now you have different implementations of that. The simple solution for Maven would be to a have a module which is called for example: service-api and than this will be released and can be used by others as dependencies. On their side they simply implement the interface. No problem with the dependencies. If you are more talking about OSGi than you should take a look to maven-tycho.
I love the concept of DI and loosely coupled system, a lot. However, I found tooling in Spring lacking at best. For example, it's hard to do "refactoring", e.g. to change a name of a bean declared in Spring. I'm new to Spring, so I would be missing something. There is no compiling time check etc.
My question is why do we want to use XML to store the configuration? IMO, the whole idea of Spring (IoC part) is to force certain creational pattern. In the world of gang-of-four patterns, design patterns are informative. Spring (and other DIs) on the other hand, provides very prescribed way how an application should be hooked up with individual components.
I have put Scala in the title as well as I'm learning it. How do you guys think to create a domain language (something like the actor library) for dependency ingestion. Writing the actual injection code in Scala itself, you get all the goodies and tooling that comes with it. Although application developers might as well bypass your framework, I would think it's relatively easy to standard, such as the main web site/app will only load components of certain pattern.
There's a good article on using Scala together with Spring and Hibernate here.
About your question: you actually can use annotations. It has some advantages. XML, in turn, is good beacause you don't need to recompile files, that contain your injection configs.
There is an ongoing debate if Scala needs DI. There are several ways to "do it yourself", but often this easy setup is sufficient:
//the class that needs injection
abstract class Foo {
val injectMe:String
def hello = println("Hello " + injectMe)
}
//The "binding module"
trait Binder {
def createFooInstance:Foo
}
object BinderImpl extends Binder {
trait FooInjector {
val injectMe = "DI!"
}
def createFooInstance:Foo = new Foo with FooInjector
}
//The client
val binder:Binder = getSomehowTheRightBinderImpl //one way would be a ServiceLoader
val foo = binder.createFooInstance
foo.hello
//--> Hello DI!
For other versions, look here for example.
I love the concept of DI and loosely
coupled system, a lot. However, I
found tooling in Spring lacking at
best. For example, it's hard to do
"refactoring", e.g. to change a name
of a bean declared in Spring. I'm new
to Spring, so I would be missing
something. There is no compiling time
check etc.
You need a smarter IDE. IntelliJ from JetBrains allows refactoring, renaming, etc. with full knowledge of your Spring configuration and your classes.
My question is why do we want to use
XML to store the configuration?
Why not? You have to put it somewhere. Now you have a choice: XML or annotations.
IMO,
the whole idea of Spring (IoC part) is
to force certain creational pattern.
In the world of gang-of-four patterns,
design patterns are informative.
ApplicationContext is nothing more than a big object factory/builder. That's a GoF pattern.
Spring (and other DIs) on the other
hand, provides very prescribed way how
an application should be hooked up
with individual components.
GoF is even more prescriptive: You have to build it into objects or externalize it into configuration. Spring externalizes it.
I have put Scala in the title as well
as I'm learning it. How do you guys
think to create a domain language
(something like the actor library) for
dependency ingestion.
You must mean "injection".
Writing the
actual injection code in Scala itself,
you get all the goodies and tooling
that comes with it.
Don't see what that will buy me over and above what Spring gives me now.
Although
application developers might as well
bypass your framework, I would think
it's relatively easy to standard, such
as the main web site/app will only
load components of certain pattern.
Sorry, I'm not buying your idea. I'd rather use Spring.
But there's no reason why you shouldn't try it and see if you can become more successful than Spring. Let us know how you do.
There are different approaches to DI in java, and not all of them are necessarily based on xml.
Spring
Spring provides a complete container implementation and integration with many services (transactions, jndi, persistence, datasources, mvc, scheduling,...) and can actually be better defined using java annotations.
Its popularity stems from the number of services that the platform integrates, other than DI (many people use it as an alternative to Java EE, which is actually following spring path starting from its 5 edition).
XML was the original choice for spring, because it was the de-facto java configuration standard when the framework came to be. Annotations is the popular choice right now.
As a personal aside, conceptually I'm not a huge fan of annotation-based DI, for me it creates a tight coupling of configuration and code, thus defeating the underlying original purpose of DI.
There are other DI implementation around that support alternative configuration declaration: AFAIK Google Guice is one of those allowing for programmatic configuration as well.
DI and Scala
There are alternative solutions for DI in scala, in addition to using the known java frameworks (which as far as I know integrate fairly well).
For me the most interesting that maintain a familiar approach to java is subcut.
It strikes a nice balance between google guice and one of the most well-known DI patterns allowed by the specific design of the scala language: the Cake Pattern. You can find many blog posts and videos about this pattern with a google search.
Another solution available in scala is using the Reader Monad, which is already an established pattern for dynamic configuration in Haskell and is explained fairly well in this video from NE Scala Symposium 2012 and in this video and related slides.
The latter choice goes with the warning that it involves a decent level of familiarity with the concept of Monads in general and in scala, and often aroused some debate around its conceptual complexity and practical usefulness. This related thread on the scala-debate ML can be quite useful to have a better grip on the subject.
i can't really comment on scala, but DI helps enforce loose coupling. It makes refactoring large apps soooo much easier. If you don't like a component, just swap it out. Need another implementation for a particular environment, easy just plug in a new component.
I agree! To me he way most people use Spring is a mild version of hell.
When you look at the standard Springified code there are interfaces everywhere, and you never really know what class is used to implement an interface. You have to look into some fantastic configuration to find that out. Easy read = not. To make this code surfable you need a very advanced IDE, like Intelly J.
How did we end up in this mess? I blame automated unit testing! If you want to connect mocks to each and every class you can not have dependencies. If it wasn't for unit testing we could probable do just as well without loose coupling, since we do not want the customer to replace single classes willy nilly in our Jars.
In Scala you can use patterns, like the "Cake Patten" to implement DI without a framework. You can also use structural typing to do this. The result is still messy compared to the original code.
Personally I think one should consider doing automated testing on modules instead of classes to escape this mess, and use DI to decouple entire modules. This strategy is by definition not unit testing. I think most of the logic lies in the actual connections between classes, so IMHO one will benefit more from module testing than unit testing.
I cannot agree that XML is problem in Java and Spring:
I use Spring and Java extensively without to much XML because most configuration is done with annotations (type and name is powerful contract) - it looks really nice. Only for 10% cases I use XML because it is easier to do it in XML than code special solution with factories / new classes / annotations. This approach was inspired by Guice and Spring from 3.0 implements its as JSR-330 (but even that I use Spring 2.5 with spring factory configured with JSR-330 annotations instead of default spring-specific #Autowired).
Probably scala can provide better syntax for developing in DI style and I'm looking at it now (pointed Cake Pattern).