I wonder if there is a java framework to journalize operations done on objects and then save them in database.
In fact, I'm working on an application where a particular object undergo many operations, each one is changing its logic (many conrols may be applicated on the object depending on user).
Now, I would like to trace controls or operations done on this object and store them in new tables serving just for statistics. I think that this could be implemented without modifying the whole exiting code of the application. I mean it could be seen as a vertical layer...
I have already seen the description of hibernate interceptors but I'm not sure that it could meet my needs
I would like also to precize that I'm working with spring core and hibernate..
Anyone has an idea about a java framework or an API meeting my need
thanks in advance..
I'm sure Hibernate Interceptors can be helpful for you. But, there is a little change that your entities might have to go through, because interceptors work when saving all the entities, you have to let the interceptor know that you are not interested in saving a few of them by adding custom annotations to them.
Other ways of doing is by using Spring AOP, you can log work without touching any of your code, but for this to happen, you need to be using spring in your environment already.
Other ways could be using traditional Servlet filters to do this.
There is a concept of Hibernate Event handlers, you may also look it up.
Related
I'm writing an application with Spring MVC which I'd like to be configurable with properties files. I looked into Spring's util namespace and found this:
<util:properties id="MyProperties" location="propertiesPath" />
with this, I can annotate my classes field simply with
#Value("myProperty")
and have the property simply injected. So, it's very simple to read your properties. But when you have to save them, it's not as intuitive.
I've stumbled upon quite a few questions on how to do it properly and I think this represents best what I want to say: Updating a properties file injected by Spring to include a last run timestamp.
My question is: why it's so difficult to save properties in Spring? Am I doing it the wrong way? At this point I am even wondering if saving properties this way is a good practice or if I should use a database.
From Oracle I can read:
The Properties class represents a persistent set of properties. The Properties can be saved to a stream or loaded from a stream.
But Spring seems to make easier only one of them. Please enlighten me.
Thank you.
Spring is largely involved in creating the static, unchanging, structure of your application, and not really involved in transaction processing or business-logic. Often it defines how transactions are to be processed, but it isn't usually involved in the processing itself. We often talk about the separation of the domain model and the architecture -- spring is about architecture.
Writing something out to a store of some kind, say properties to a disk file, is transactional logic (even if you don't need an explicit transaction to do it). It would be one of the end-user features of your system, not part of the architecture -- it would be a feature (even if the end user, in this case, is a sys-admin). Spring has little support for this type of behaviour -- just as it has little support for storing information regarding dynamic changes to the application context.
Using properties like this supposed it read-only. If you need some managing with it, you should better write you custom service with pure java properties handling http://www.mkyong.com/java/java-properties-file-examples/
Is there a way to log all database tables (and maybe other objects) that the application running within Tomcat reads from/write to? All of the database access is performed either via Hibernate (wired through Spring) or Sql2o.
We are in process of migrating a legacy database, and it would be nice to automatically separate tables that are actually used from the ones that are pure legacy (and we've got lots of those!).
Thanks!
You can create new Aspect since you are already using Spring, and monitor all your read/write services, so every time any of it is called, you can log it.
It should be quite easy, define new aspect (f.e. MyAspect), define before/after or round actions (which will log your table names somewhere), and just put the annotation on your services (#MyAspect).
Another way is to create triggers on your tables (not sure if that is an option), but I'd preffer an aspect... It's much cleaner approach.
A project I'm working on is going to upgrade from jee5/seam to jee6, where "those who descide" think it is a good idea to drop seam since most of its features have been incorporated into jee6. But I have a case that I doesn't seem to be able to solve in jee6.
We have several wizards using ConversationScope. We use Seams FlushModeType.Manual in order to avoid getting "dirty" data commited until we want we actually wants to commit it (each page-load basically gets it own transaction but since nothing is written to the database until we flush, most commits doesn't change the state of the database).
I have made a few attempts using PersistenceContextType.EXTENDED in jee6 but it seems like I can't find a way to defer the flush to the database like seam does and the only workarounds seems to be to use detached objects or a separate view-model.
We really like how working with attached objects make (for our cases) things really simple to understand and fast to develop.
Is there a solution where we can keep working with attached objects in conversations?
As a big fan of Seam2 I wrote great apps using conversations, conversation scoped entity manager with flush mode set to manual and detached objects.
However, we must now admit that this pattern, despite being strongly pushed in the Seam manual and working great as far as Hibernate is the JPA implementation, is fundamentally broken. The reason is explained in this post from Mark Struberg: Is There A Way To Fix the JPA EntityManager?
So, the answer is no, there is no practical solution to keep working with attached objects in conversations. You should work with detached objects.
There is another another great CDI blogger who experimented with conversation scoped entity manager: Conversational CRUD. It might be worth reading if you keep on trying to work with attached objects.
I've been scratching my head around developing a simple plugin based architecture on top of Spring, for one of my current apps. No matter how much separation one could achieve using patterns like MVC, one always reaches a point where coupling is inevitable.
Thus, I started weighing options. At first I thought that filters are a good one. Every plugin I'd make would be a filter, which then I will simply insert into the filter map. Of course, this will create a bit of overhead when enumerating and checking all the filters, but at least , controllers won't have to care what has happened to the data before it reached them, or what happens afterwards, they will just care to fetch the models (through DAO or whatnot) and return them.
The problem with this is that not all of my app requests are HTTP-based. Some are based on emails, others are internally scheduled (timed), so Filters won't help much, unless I try to adapt every type of incoming request to HTTPRequest, which would be too much.
Another one I thought about was annotation based AOP, where I annotate every method, where the plugin would intercept methods based on certain conventions. My problem with is that first I am not so experienced with AOP in general, and second, simply writing all those conventions already suggests a bit of coupling
By far the option that mostly appeals to my way of thinking is using Spring-based events. Every type of request handler within my app (web controller, email handler, etc) will be a sort of an event dispatcher, which will dispatch Spring events on every major action. On the other hand, plugins will simply listen for when a particular event happens, and do some logic. This will allow me to utilize point #1 as well, as some of those plugins could be filters as well, i.e when they receive a notification that a certain controller action is done, they may just decide to do nothing, and rather wait for when they get called by the filter chain. I see this as a somewhat nice approach. Of course here comes the overhead again, of dispatching events, plus the fact that every involved class will eb coupled with Spring forever, but I see this as a necessary evil.
My main concern regarding Spring events is performance, both in terms of latency, and memory footprint.
I am still not an expert, so a bunch of feedback here would be of tremendous help. Are spring events the best for this type of architecture, or there is another solution that I've missed? I am aware that there might even be some third-party solutions out there already, so I'd be glad if someone could point out one or two tried and proven ones.
Thanks.
The concept of a plugin can be achieved with the Spring bean factory. If you create a common interface you can define multiple beans that implement it and inject them where needed. Or you can use a factorybean to deliver the right plugin for the job.
Your idea of using events is called an 'Event Driven Architecture'. This goes a lot further than just plugins because it not only decouples from the implementation but also offers the possibility to decouple from which instance is used (multiple handlers), which location (multiple machines) and the time at which the request is handled (asynchronous handling). The tradeoff is an increased overall complexity, a reduced component-level complexity and the need for a messaging infrastructure. Often JMS is used, but if you just want a single-node setup both Spring and Mule offer simple in-memory modes as well.
To help you further you should expand a bit on the requirements you are trying to meet and the architectural improvements you want. So far you have mentioned that you want to use plugins and described some possible solutions, but you have not really described what you are trying to achieve.
There are technically two questions here, but are tightly coupled :)
I'm using Hibernate in a new project. It's a POS project.
It uses Oracle database.
We have decided to use Hibernate because the project is large, and because it provides (the most popular) ORM capabilities.
Spring is, for now, out of the question - the reason being: the project is a Swing client-server application, and it adds needless complexity. And, also, Spring is supposed to be very hungry on the hardware resources.
There is a possibility to throw away Hibernate, and to use JDBC. Why? The project requirement is precise database interaction. Meaning, we should have complete control over the connections, sessions and transactions(and, yes, going as low as unoptimized queries).
The first question is - what are your opinions on using the mentioned requrement?
The second question revolves around Hibernate.
We developed a simple Hibernate pilot project.
Another project requirement is - one database user / one connection per user / one session per user / transactions are flexibile(we can end them when we want, as sessions).
Multiple user can log in the application at the same time.
We achived something like that. To be precise, we achived the full described functionality without the multiple users requirement.
Now, looking at the available resources, I came to a conclusion that if we are to have multiple users on the database(on the same schema), we will end up using multiple SessionFactory, implementing a dynamic ConnectionProvider for new user connections. Why?
The users hashed passwords are in the database, so we need to dynamically add a user to the list of current users.
The second question is - can this be done a little easier, it seems weird that Hibernate doesn't support such configurations.
Thank you.
If you're pondering about weather to use Hibernate or JDBC, honestlly go for JDBC. If your domain model is not too complex, you don't really get a lot of advantages from using hibernate. On the other hand using JDBC will greatly improve performance, as you have better control on your queries, and you get A LOT less memory usage from not habing all the Hibernate overhead. Balance this my making an as detailed as possible first scetch of your model. If you're able to schetch it all from the start (no parts that are possible to change wildly in throughout the project), and if said model doesn't look to involved, JDBC will be your friend.
About your users and sessions there, I think you might be mistaking (tho it could just be me), but I don't think you need multiple SessionFactories to have multiple sessions. SessionFactory is a heavy object to initialize, but once you have one you can get multiple hibernate session objects from it which are lightweight.
As a final remark, if you truly stick with an ORM solution (for whatever reason), if possible chose EclipseLink JPA2 implementation. JPA2 has more features over hibernate and the Eclipselink implementation is less buggy then hibernate.
So, as far as Hibernate goes, I still dont know if the only way to dynamicaly change database users(change database connections) was to create multiple session factories, but I presume it is.
We have lowered our requriements, and decided to use Hibernate, use only one user on the database(one connection), one session per user(multiple sessions/multiple "logical" users). We created a couple of Java classes to wrap that functionality. The resources how this can be done can be found here.
Why did we use Hibernate eventually? Using JDBC is more precise, and more flexibile, but the effort to once again map the ResultSet values into objects is, again, the same manual ORM approach.
For example, if I have a GUI that needs to save a Page, first I have to fetch all the Page Articles and then, after I save the Page, update all the Articles FK to that Page. Notice that Im speaking in nouns(objects), and I dont see any other way to wrap the Page/Articles, except using global state. This is the one thing I wouldnt like to see in my application, and we are, after all, using Java, a OO language.
When we already have an ORM mapper that can be configured(forced would be the more precise word to use in this particular example) to process these thing itself, why to go programming it?
Also, we decided to user google Guice - its much faster, typesafe, and could significantly simplify our development/maintence/testing.