I am using Spring framework in my application and it is deployed on MULE server.
Based on debug or info level, the amount of logging and the percentage of logging will vary.
Till date, I write the log statements explicitly in all my business logic.
Is there any way to do this through configuration, say configure at some point -
CLASS NAME - METHOD NAME - LOG AT ENTRY POINT WITH INPUT PARAMETERS - LOG AT EXIT POINT WITH RETURN
This way my code will not look very clutter.
I am not sure exactly what you are asking, but it sounds like you would like to automatically log entry and exit from methods along with parameters. If that is the case, you might consider some form of Aspect Oriented Programing (AOP). Here and here and here are some links to pages with good examples of implementing exactly this kind of logging with PostSharp. Since you are using Spring (.NET or just Spring?), you might know that Spring.NET has an AOP solution (or here for Spring). Here is a project from CodeProject that provides a log4net logging aspect already written for PostSharp (not sure if this is currently up to date or not). There are other AOP solutions out there, PostSharp is one of the more popular.
I answered with a .NET slant because that is what I am more familiar with and you didn't indicate a language preference (via the tags) in your question.
As wageoghe mentioned, using Spring AOP is an option.
Another one, since you're running in Mule, is to use component interceptors around your Spring beans.
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 have a use case where I would like build a common interface or service which can update entities of application. Example case is shown as below:
Now every application has to handle update functionality of entities. Rather than implementing update functionality in n application module. I would like to build a common interface or server in spring boot.
Service will be like below:
My question is how to design service/interface which can used for above scenario. Any api or tool which can help me to achieve this. I dont want to write code for update in every application module.
Thanks in advance.
Last year I was thinking about the similar concept to yours, but in Apache Camel framework context. I haven't got enough time and motivation to do so, but your post encouraged me to give it a try - perhaps mostly because I've found your concept very similar to mine.
This is how I see it:
So basically I considered an environment with application that might uses N modules/plugins that enriches application's features, i.e. processing feature etc. Application uses module/plugin when it is available in the classpath - considering Java background. When the module is not available application works without its functionality like it was never there. Moreover I wanted to implement it purely using framework capabilities - in this case Spring - without ugly hacks/ifs in the source code.
Three solutions come to my mind:
- using request/response interceptors and modifying(#ControllerAdvice)
- using Spring AOP to intercept method invocations in *Service proxy classes
- using Apache Camel framework to create a routes for processing entities
Here's the brief overview of POC that I implemented:
I've chosen Spring AOP because I've never been using it before on my own.
simple EmployeeService that simulates saving employee - EmployeeEntity
3 processors that simulates Processing Modules that could be located outside the application. These three modules change properties of EmployeeEntity in some way.
one Aspect that intercepts "save" method in EmployeeService and handles invocation of available processors
In the next steps I'd like to externalize these Processors so these are some kind of pluggable jar files.
I'm wondering if this is something that you wanted to achieve?
link to Spring AOP introduction here: https://docs.spring.io/spring/docs/5.0.5.RELEASE/spring-framework-reference/core.html#aop
link to repository of mentioned POC: https://github.com/bkpawlowski/spring-aop
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.
I am considering to utilize Expression-Based Access Control from Spring Security 3.0.
The documentation says: You can access any of the method arguments by name as expression variables, provided your code has debug information compiled in.
That means that I have to have debug info left in my production wars and jars to properly use Expression-Based Access Control. For me it seems not very good idea at all.
Please tell me your opinions on this issue, so I can summarize your expirience to deside where I go for it or not.
Thank you in advance!
Max
It is a little strange, but this isn't tied to Spring Security. Spring Web MVC uses it too; e.g., to discover #RequestParam and #PathVariable default values.
In my experience people typically leave debug information in their builds (even production builds) to support troubleshooting (debug level logging is a different story), so Spring takes advantage of this. But it's fair to say that Spring is violating the principle of least surprise here, meaning that one wouldn't expect turning debug info off to turn a working app into a broken app.
Please see Spring security annotations with EL — requires debug information compiled in?
I have looked at Spring MVC a few times briefly, and got the basic ideas. However whenever I look closely it seems to require you already know a whole load of 'core Spring'. The book I have for instance has a few hundred pages before it gets onto Spring MVC... which seems a lot to wade through. I'm used to being able to jump in, but there's so much bean-related stuff and XML, it just looks like a mass of data to consume.
Does it simplify if you put the time in, or is Spring just a much bigger framework than I thought? is it possible to learn this side of it in isolation?
#John Spring just a much bigger framework than I thought? - probably so, at least I thought so.
is it possible to learn this side of it in isolation? - Yes , here is a good way to learn your way http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/spring-web.html
And also I'd recommend you read a book manning spring in action 2nd edition, I also was learning spring from zero, and now I'm comfortable with it after reading this book, of course you have to refer to reference every now and then.
Here is where you can get basic info about MVC concept if you are not already familiar with(its in php, but important thing is point not syntax)
http://net.tutsplus.com/tutorials/other/mvc-for-noobs/
EDIT
If you want to see MVC in action, with examples or other spring uses use this repository https://src.springframework.org/svn/spring-samples to checkout some projects , you'll see mvc-basic, mvc-ajax ..etc this is really good resource , you can checkout projects with Tortoise SVN on windows or subeclipse from eclipse
At least you need to understand the core Spring - dependency injection, application context configuration and so on. It's actually not too complex, just a bit hard to start. For an experienced developer it might make sense to take a look at some sample app for the basic setup.
ps. I've got this sample project for JSF/Spring/JPA/Hibernate combination. Not Spring-MVC, but may be still helpful.
I myself am trying to learn Spring MVC from NetBeans official documentation from here:
http://netbeans.org/kb/docs/web/quickstart-webapps-spring.html
Coming from ASP.Net/C#, it feels like there are so many steps to do in that simple example.
The great thing about Spring is that you can pick and choose what you use. If you want to use Spring, you don't have to jump in head first, you can just try it out by, say, using the Dependency Injection features, or by using the JDBC Template stuff. My recommendation would be to start small, and see how you like it.
To use the Web MVC stuff, you will need to understand Dependency Injection for configuring your controllers. You can choose to use the older more flexible XML-style configuration, or you can use the newer Annotations. Or you can mix and match. Starting with XML would probably be best as it will help you understand how stuff is working (it'd be like learning C and C++ before Java). Then you can move to using Annotations. Personally, I use XML to instantiate all my beans. I use the #Autowire annotation to inject dependencies. This seems to be the sweet spot for most flexibility and ease of use.