If I use Sprint-Batch to read the Json file without specifying taskExecutor it works fine, but with taskExecutor specified it can't read properly. Wrapping with SynchronizedItemStreamReader can solve the problem of thread safety, but it does not work with JacksonJsonObjectReader. So I want to know if there is a thread-safe JacksonJsonObjectReader class to use
The typical usage of the JacksonJsonObjectReader is to use it as a delegate in a JsonItemReader. So if you wrap the JsonItemReader in a SynchornizedItemStreamItemReader, there is no need to synchronize the object reader (since the entire read method will be synchronized).
Now if you want to use the JacksonJsonObjectReader outside of this setup, you need to synhronize it yourself. This class is not thread safe.
Related
5.5 and axon framework starter 4.5.4
I can read and write my events with eventhandler and queryhandler without problem
but when I want to use eventstore.readevents function I got serialization .I try to set my application properties both my reader and writer but not working still same error(By the way I clean database and delete old events each time).I alson try to set xstream type but still same issue
axon.serializer.general=jackson
axon.serializer.events=jackson
axon.serializer.messages=jackson
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class org.axonframework.serialization.UnknownSerializedType and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ArrayList[0])
at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:77) ~[jackson-databind-2.12.5.jar:2.12.5]
at com.fasterxml.jackson.databind.SerializerProvider.reportBadDefinition(SerializerProvider.java:1276) ~[jackson-databind-2.12.5.jar:2.12.5]
at com.fasterxml.jackson.databind.DatabindContext.reportBadDefinition(DatabindContext.java:400) ~[jackson-databind-2.12.5.jar:2.12.5]
First of all, I have to ask why you want to use eventStore#readEvents given that this is not a common usage. This method is used internally by the Framework and most of the time, should be kept like that.
To your problem, you can easily check on Framework code what is happening and how it uses the eventStore#readEvents method.
First of all, the signature here: DomainEventStream readEvents(String aggregateIdentifier);
It returns a DomainEventStream which is an Iterator implementation of a DomainEventMessage (as you can also see on code: public interface DomainEventStream extends Iterator<DomainEventMessage<?>> {).
Checking any of the usages, for example the EventSorcingRepository, you can see how it is used here and here and pretty much use Iterator's method for that (hasNext and peek for instance).
Using those methods will give you access to the DomainEventMessage where you can get the Type but also the Payload (and other useful things you may need).
Hope that clarifies the usage of it but also make sure you really want to use it!
I want my logging methods to output some sort of request ID. To do that I need to pass a request object (or some derivative) to the logging functions.
This is all fine when logging from the request handlers, but is problematic when used from within library-style methods, as I don't wish those to be aware of any ongoing http-requests.
Furthermore, those same library methods might be used in the future by console applications, and than the request-id would be replaced by some sort of worker-thread-id.
Using a context solves the problem, but this means I will have to add a context parameter to all my methods, which is somewhat annoying.
So, basically, what I need is some sort of static storage that is passed between method and goroutine calls.
I'm not sure there's anything like that in Go, so maybe my approach is totally off-base, in that case, I would be happy to hear what is a better approach to solve the above problem.
Thanks,
Try another logging library. For instance, in log15 (https://github.com/inconshreveable/log15) a Logger as an embedded key/value context.
logger := log.New("request_id", "8379870928")
You can pass the logger object to anyone that needs to log. Later on:
logger.Warn("blabalbla")
... will embed the request_id that you have put.
My app attempts to pass a fairly complex object that uses RxAndroidBle classes from one Android activity to another by adding it to an Intent as a Serializable extra. But I'm getting crashes, apparently due to problems with serialization of these classes.
Is there any fix for this?
Unfortunately it is not possible to serialize classes of RxAndroidBle because most of them contain references to objects that are not serializable.
If you cannot pass a reference to an object that you want to use in a different part of the code (for instance in a different process) then you would need to create a new instance of RxBleClient in that process and use it.
I couldn't find any reference with this functionality. Shall I just implement a helper method in the builder to read fields in StateTransition object and populate the chain configureTransition() call by myself??
Just to confirm not to reinvent the wheels.
UPDATE:
I'm trying to use StateMachineBuilder to configure with some pre-defined states and transitions in a properties file. In Builder, they use this chained call to generate configuration:
builder.configureTransitions().withExternal().source(s1)....
What I have in mind is, everything read from the file is stored in an object, the spring sm library has this StateTransition object. But as far as I know from the API, there is no way to use it directly to configure a state machine. Instead, I can read individual fields in the object and use the chained call above.
Thanks!
If you want to do it like that, what you mentioned is pretty much only option. Hopefully we get a real support for external state machine definition, i.e. tracked in https://github.com/spring-projects/spring-statemachine/issues/78.
I have been using the BatchSqlUpdate class successfully for a while. The only annoyance using it is that named parameters need to be registered before running any query using the declareParameter or setParameter methods. This means that the type of the parameters has to be declared as well. However, Spring also provides a NamedParameterJdbcTemplate class which has a very convenient batchUpdate method that takes named parameters as input (an array of maps or SqlParameterSource objects) without the need of declaring them first. On top of that, this class can be reused easily and I also believe it's thread-safe.
So I have a couple of questions about this:
What's the recommended way to perform (multiple) batch updates?
Why is this feature duplicated across two different classes that also behave differently?
Why does BatchSqlUpdate require declared parameters if NamedParameterJdbcTemplate does not?
Thanks for the thoughts!
Giovanni
After doing some research, I reached the following conclusions.
First of all, I realized that the NamedParameterJdbcTemplate class is the only one accepting named parameters for batch updates. The method batchUpdate(String sql,Map[] batchValues) was added in Spring 3 to achieve this.
The BatchSqlUpdate class contains an overridden update(Object... params) method that adds the given statement parameters to the queue rather than executing them immediately, as stated in the javadoc. This means that the statements will be executed only when the flush() method is called or the batch size exceeded the maximum. This classed doesn't support named parameters, although it contains a updateByNamedParam() method inherited from SqlUpdate. This is unfortunate since this method allows reuse of the same map for the named parameters, whereas the NamedParameterJdbcTemplate.batchUpdate() method requires an array of maps, with the associated overhead, code bloating and complications in reusing the array of maps if the batch size is variable.
I think it would be useful to have an overridden version of updateByNamedParam(Map paramMap) in BatchSqlUpdate to behave just like update(Object... params) but with added support for named parameters.