Pretty much everything in the question. I just discovered p6spy in association with hibernate which is really cool to see the actual sql queries, though I'm quite baffled on how it works.
So how does it work?
the basic idea on p6spy goes like this:
depending if you go for Datasource or for JDBC driver in your code,
what you do is instead of referring the real ones, you specify p6spy
specific ones: com.p6spy.engine.spy.P6SpyDriver or com.p6spy.engine.spy.P6DataSource respectively (for full documentation, see: p6spy.readthedocs.io/en/latest/configandusage.html).
afterwards you configure the real ones in your spy.properties file (using realdriver or realdatasource properties respectively)
depending on the configuration you can achieve the logging of sql statements (using com.p6spy.engine.logging.P6LogFactory)
so to answer your question, the idea is that all the jdbc calls (statements execution, transaction related stuff) will be wrapped (proxied) by p6spy and depending on your configuration, these can be logged via the file logger (using appender=com.p6spy.engine.logging.appender.FileLogger), stdout logger (using appender=com.p6spy.engine.logging.appender.StdoutLogger) or log4j logger (using: appender=com.p6spy.engine.logging.appender.Log4jLogger)
If interested in more details, feel free to ask, or check the project itself on: https://github.com/p6spy/p6spy
Related
Why I get this error even though i specified the hibernate.dialect as OracleDialect. If you recommend to use oracle10gDialect or Oracle9iDialect please explain, cause Hibernate can find the Dialect using JDBC meta data when it connect to the db in very first time. Correct me if i'm wrong.
I believe your problem is to find the correct dialect. But I believe this is part of the configuration. This is not a programming problem, This is a configuration strategy that you used to manipulate or use of configuration.
you can externalize the configuration with multiple profiles such as dev, UAT, PROD which is based on the environment. Then your CICD
the pipeline will pick the correct profile which has the correct dialect according to the deployed environment.
Or you can add default dialect and override the properties based on
the environment in which the application is deployed.
The reason is application is the component where looking for the database.
or check this post if you wanted to do programmatically ( I haven't try this) :
Is there a way to detect SQL Dialect without knowing the database type?
Also please read the driver specification and JPA dialect usage. some databases expect exact versions of dialect to support full functionality.
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 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 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.
I am looking for a tool that Logs SQL statemetns fired in the application as I use the application.
I found p6spy. But there is an issue with that. It doesnt seem to be compatible with XA Datasources.
Is there a way to make p6spy work on Websphere 6.1 OR is there an alternative to p6spy ?
Also, if anyone has any AspectJ code that intercepts the PreparedStatment object and dumps the SQL, that would also be great.
It is not mandatory for the JDBC drivers to implement a feature to be able to extract / print out the SQL statements. To be honest, I would do this in database. All reasonable database products can log in detail everything that comes in. Also, you can at the same time get further information like execution plans and their impact on the server.
It does depend on the way that you are accessing the database. If you are using Hibernate then you can make that spit out its SQL, if you are accessing the datasource through WAS then you can use the trace service. Set the trace to something like:
=info: com.ibm.websphere.rsadapter.=detail
And see what you get out of it.
I seem to remember there being some parameter you can add to your jdbc url configuration, and/or the connection. Can't remember the details.
You shold change trace level into jdbc driver.
If you using DB2 then change custom properties for data source
if you using Oracle then change driver on the ojbdc6_g.jar and change JVM properties