I'd like to write some generic batch listeners to log out some useful information of all batches configured in my application. To do so I'd like to get the configured skippable/retryable exceptions from batch configuration. However I did not find any API for that. Is there a way to retrieve this configuration independant of the jsr352 implementation?
No you won't see this or anything similar really in the specification API (so anything that did exist would be impl-specific).
The theme of separation of concerns lies behind many of the API choices, and nothing like a "job definition model" API exists in the spec.
Related
I'm looking into the Axon framework and I'm having a hard time with the automatic persistence of the command state.
I've looked at the documentation regarding the command model repository and from my understanding the state of the command model for the standard repository should be auto-persisted provided I have the correct dependencies. This sentiment is also present in another blog/tutorial I've looked at (you might need to scroll down a bit to the Repository section).
The problem is that although I've added the axon-mongo dependency, the command state is not being persisted automatically. I've tried to configure the relevant Repository beans as per the docs but It doesn't seem to have worked either. I'm not even sure whether this is required given that (from my understanding of the docs) you would do this mainly if you want to query the command state.
While I understand that I can create my own repository and save the entities myself (similar to this tutorial), I'd rather not given seems to provide this out of the box.
Am I missing something here?
NOTE: My Mongo setup seems to be correct since I've managed to persist my events in MongoDB as per the documentation.
UPDATE
As per Steven's comment (and subsequent comments), I decided to try and implement a state-stored aggregate however I found an issue with the (de)serialization of the aggregate. I've sent my Aggregate to Steven and he has confirmed that it is simple enough that it should be (de)serialized by XStream. I have also tried to serialize my aggregate using a standalone instance of XStream and it worked, which led me to believe that this is more of an Axon issue than an XStream issue. I also tried to use the Jackson and java (de)serializers (since they are the other options provided by Axon) and I found similar problems. I have concluded that this is an Axon bug and i have stopped trying to solve the issue.
From your question it is not immediately clear if you are aware of the possible Command Model storage mechanisms you can choose from.
So firstly, like #Mzzl points out in his comment, you can view the Command Model state from two angles:
Event Sourced
State-stored
By default, Axon Framework will set up your Aggregate with an EventSourcingRepository behind it. This means, that if an Aggregate (e.g. your Command Model) is required to handle a new Command, that the Aggregate will be loaded by retrieving a stream of all the events that it is has published.
Second, it will call all the #EventSourcingHandler annotated methods on your Aggregate implementation to recreate the state of the Command Model.
Lastly, once all the Events which are part of the Aggregate's Event Stream have been handled, the command will be provided to the #CommandHandler annotated method.
The state-stored approach is obviously a little different, as this means the entirety of your Aggregate will be stored in a repository.
Note though, that the State-Stored approach is only supported through the GenericJpaRepository class. Thus, storing the Aggregate in it's entirety in a MongoDB is not an option.
If you are looking for an Event Sourcing approach for your Aggregate, the events can be sourced from any EventStore implementation covered by the framework.
That thus means you can choose JPA, JDBC, MongoDb and Axon Server as the means to storing your events and retrieving a stream of events to recreate your Command Model.
Configuration wise, there are a couple of approaches to this.
If you are using the Configuration API provided by Axon directly, you can use:
AggregateConfigurer#defaultConfiguration(Class<A>) for an Event Sourced approach
AggregateConfigurer#jpaMappedConfiguration(Class<A>) for a State-Stored approach
If you are in a Spring Boot environment with your application, it's a little simpler to switch between event sourced and state-stored.
Simply having the #Entity annotation on your Aggregate implementation is sufficient for the framework to note you want to store the Aggregate as is.
Hope this sheds some light on the situation #The__Malteser!
Update
Based on the comments, it's clear that the XStreamSerializer which the framework uses by default to de-/serialize objects, is incapable of serializing your Aggregate instance in a State-Stored fashion.
Based on the exception you're receiving, being Cannot marshal the XStream instance in action, I did some searching/digging. I have a hunch that XStream is by default not capable to simply serialized non-static inner classes.
However, as we're not sure what the implementation is of your Aggregate, it's hard to deduce whether that's the problem at hand. Would you be able to share your implementation with us here so that we can better deduce whether an inner class is the problem?
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.
I work on an application that uses Spring MVC and Hibernate. I am implementing some RESTful web services and am curious how to easily filter collections server side.
As an example, I want to be able to filter a collection of employee entities. I have researched several options, such as RQL, the way Google handles custom searches, Ebay's answer, and even Yahoo's YQL. They all seem to be good answers to the filtering question, but I can not seem to find any libraries that will allow me to easily implement this concept.
I did find here, that:
Apache CXF introduced FIQL support with its JAX-RS implementation since 2.3.0 release
but we are already using Spring MVC.
I'm surprised there is no library for taking the bold query string below, for example, and translating that into SQL or something that Hibernate can use to filter.
/employees?lastname=john OR jon&hiredate lt 20010201
It is entirely possible that I am thinking of this incorrectly, but I wanted to tap into the community's experience and knowledge. What am I missing?
I know this is old, but for completeness, there are at least two libraries that handle parsing RQL:
https://github.com/jazdw/rql-parser
https://github.com/jirutka/rsql-parser (not quite RQL by default, but configurable)
I'm using jazdw/rql-parser myself and started working on an SQL mapper but as Oleksi mentioned there is a lot of custom code required for validating, field mapping, etc. so I don't know how generic I can make it yet.
A library that directly converts a GET like that into SQL could be very insecure. You need to have an intermediate layer to do some validation to make sure that the user isn't messing with the URL to execute a SQL injection.
As far as I know, the best you can do is use your JAX-RS implementation to cleanly read in those query parameters, validate them, and use something like a prepared SQL statement to securely execute them.
My Apache Tomcat Server is getting periodic updates from a Java based client Application, At the moment the scenario is just one client and talking to the server.
I want to log the messages from the client onto the server with time-stamp what kind of framework will help me in achieving this?
EDIT: The OP goal was actually pretty unclear and I'm modifying my answer after some clarifications.
Well, I'm not sure, but maybe a logging framework will suit your needs. If so, have a look at:
Log4J: The most famous logging framework, widely used.
Java Logging aka java.util.logging: didn't succeed to replace Log4J.
Logback: "Logback is intended as a successor to the popular log4j project. It was designed, in addition to many individual contributors, by Ceki Gülcü, the founder of log4j".
SL4J: A "Simple Logging Facade for Java serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time".
And pick one of them (I'd use Log4J or Logback).
To save your messages for later processing from the webapp (e.g. generating a web page with some graphs/charts), the best approach is to use a database. Just read/write them from/to a simple table with a timestamp column.
If you are not really familiar with Java, JDBC, persistence, connection pooling, datasource, etc, I'd suggest to use the Spring framework as it will hide most of the complexity. For the database part, have a look at the Chapter 11. Data access using JDBC from the Spring documentation. Pay a special attention to the JdbcTemplate or the SimpleJdbcTemplate, they should allow you to get the job done.
Create a special JSP page for accepting log entries, and invoke it with
http://..... foo.jsp?l=the%20stuff%to%log (i.e. URL encoded)
You then just need to pick out the "l" parameter and do with it what you need to do. An initial implementation could be invoking the log(String s) method in the servlet context.
When I look at Java frameworks like Hibernate, JPA, or Spring, I usually have the possibility to make my configuration via an xml-file or put annotations directly in my classes.
I am cosistently asking myself what way should I go.
When I use annotations, I have the class and its configuration together but with an xml I get a bigger picture of my system because I can see all class-configurations.
Annotations also get compiled in some way I guess and it should be quicker than parsing the xml, but on the other hand, if I want to change my configuration I have to recompile it instead of just changing the xml file (which might become even more handy for production environments on customer side).
So, when looking at my points, I tend to go the xml-way. But when looking at forums or tutorials usually annotations are used.
What are your pros and cons?
A good rule of thumb: anything you can see yourself wanting to change without a full redeploy (e.g. tweaking performance parameters) should really go in something "soft-configurable" such as an XML file. Anything which is never realistically going to change - or only in the sort of situation where you'll be having to change the code anyway - can reasonably be in an annotation.
Ignore any ideas of performance differences between annotations and XML - unless your configuration is absolutely massive the difference will be insignificant.
Concentrate on flexibility and readability.
If you're writing an API, then a word of warning: Annotations can leak out into your public interface which can be unbelievably infuriating.
I'm currently working with APIs where the API vendor has peppered his implementation with Spring MBean annotations, which suddenly means I have a dependency upon the Spring libraries, despite the possibility I might not need to use Spring at all :(
(Of course, if your API was an extension to Spring itself, this might be a valid assumption.)
I think the decision comes down to 'lifecycle', and impedance mismatch between lifecycles.
Lifecycle: Every piece of data, whether its source code, a database row, a compiled class, an object, has a lifecycle associated with it. When does it come into existence and when is it garbage collected?
Suppose I put Hibernate annotations on a Java class. Seems like a reasonable idea, especially if I am creating a new database from scratch and am confident that only this one application will ever connect to it - the lifecycles of my classes, the database schema and the ORM mapping are naturally in sync.
Now suppose I want to use that same class in an API and give it to some third party to consume. The Hibernate annotations leak into my API. This happens because the lifecycle of that class and the database are not the same thing. So we end up using mapping tools to translate between layers of beans in a system.
I try to think about lifecycles and that annotations that can cause lifecycle mismatches should be avoided. Some annotations are relatively harmless in this respect, and some are a hidden danger.
Examples of bad annotations: ORM mapping, database configuration, hard coded config for items that may vary between deployment environments, validations that may vary depending on context.
Examples of harmless annotations: REST endpoint definitions, JSON/XML serialization, validations that always apply.