I have a simple Spring Integration 2.0.1 aggregator setup, using a SimpleMessageStore along with a regular Spring MessageGroupStoreReaper defined, in order to be able to implement a grouping timeout mechanism (which worked simply as an aggregator 'timeout' parameter in Spring Integration 1.0.4).
I already debugged and verified the messages are aggregated correctly within SimpleMessageStore based on groupId, but upon timeout the MessageGroupStoreReaper fails, with "Unable to access property 'messages' through getter" AccessException. The precise error is located within MessagingMethodInvokerHelper class, which asserts the messages field is not null. It seems somehow the messages aggregated are not available during execution of the Invoker, resulting in the ""Invalid method parameter for messages: was expecting a single payload." IllegalStateException.
What could be the cause of this issue and how to resolve it?
I already tried updating to 2.0.6, but the issue remains.
***EDIT
I updated my SI dependencies to 2.2.5, but this did not resolve my problem. I use Spring 3.0.7.
Only one solution to fix it just to upgrade to latest version of Spring Integration - 2.2.6.
2.0 is now out of support. Sorry
I resolved the issue, it seems that the previous setup that worked for SI 1.0.4 required modification on service activator side - the output channel was expecting List<Message<?>>, while the actual aggregated type was Message<List<Message<?>>>. After modification of activator's method signature to match the latter type, SI was able to match signature candidate properly. This could possibly be also fixed by modification of aggregator add method to operate on specific Message instead of List, with no modifications to the activator.
Related
I'm working on a system's back end that uses Spring Boot, REST, HATEOAS, Hibernate and PostgreSQL. For validation, I started using classes that extend org.springframework.validation.Validator. It works well, but only for calls made by the front end. For calls made in the back end, such as by using EntityManager, they don't fire. I've managed to have another validator being called in this situation by using #Constraint for ElementType.TYPE, but it only gets called for create and save methods.
Is it possible to use this validator to validate on delete methods too? There's a project here that's a non operational subset of the project I'm working on, containing the validators I mentioned.
Thanks in advance.
P.S.: I'd rather avoid manually calling the validators whenever I call a repository method in the back end.
P.P.S.: This answer makes me believe it's possible, but I couldn't translate the XML configuration to JavaConfig.
I finally found the answer. In application.properties, add:
spring.jpa.properties.javax.persistence.validation.group.pre-remove=javax.validation.groups.Default
The linked question told me which property I needed, but I didn't know where to place it. I tried to use custom Java configuration and even persistence.xml configuration, but several other things failed.
Here, I learned that "[...] all properties in spring.jpa.properties.* are passed through as normal JPA properties (with the prefix stripped) when the local EntityManagerFactory is created." So I just added that prefix and it worked.
We have placed hook on Stash to have JIRA number at start of commit message.
But when we use jgitflow, it does not put any JIRA number in commits, hence later pushing to Stash fails.
Question: How can we pass JIRA number to jgitflow while releasing to avoid this problem?
The release-start goal provides the scmCommentPrefix property for such a purpose:
The message prefix to use for all SCM changes. Will be appended as is. e.g. getScmMessagePrefix() + the_message;
You could hence invoke it as:
mvn jgitflow:release-start -DscmCommentPrefix=JIRA-123
The same is also provided for the release-finish goal via the same property, scmCommentPrefix.
mvn jgitflow:release-finish -DscmCommentPrefix=JIRA-123
It's an optional property in both cases, so no need to provide it if not required, but very useful in similar cases (hooks) indeed.
I have an interesting problem regarding json web token. The moment I add this dependency to maven pom, my unit tests for Spring Rest Controller throw gibberish, like
ResultActions results = mockMvc.perform(post("/customers/" + customerId + "/orders")
.contentType(MediaType.APPLICATION_JSON).content(new Gson().toJson(order)));
is expected to give 200, but gives 400. What I've noticed upon investigating the issue is that the problem happens only for tests that test POST/PUT (transactional HTTP requests I guess I could call them). I've tried excluding dependency from testing using information in this link, but to no avail. I'm not sure what other information to provide, because I really don't have the faintest idea as to what is causing this issue.
I've solved this issue. The problem was dependency conflict. JJWT depends on Jackson and I've already been using GSON for my Jsons. Those two conflicted in a weird way. I've solved the issue by changing JJWT to another JWT lib.
I wasn't able to find the solution and I found more people stuck in the same problem so I will post it here.
By default a JAX-WS server (at least for WebLogic) will not validate the message received with its associated schema.
This can lead to a lot of problems since any invalid value (wrong xsd:dateTime format, letters on a number field, etc) will result in a null value in the Java object, including mandatory fields.
What I need to do is a simple validation that should be provided by the server.
import com.sun.xml.internal.ws.developer.SchemaValidation;
#Stateless
#WebService(portName="ValidatedService")
#SchemaValidation
public class ValidatedService {
public void operation(#WebParam(name="request") ValidatedRequest request) {
/* do stuff */
}
}
For some reason when I was trying to use the provided schema validation I was getting the following exception:
Caused By: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.internal.ws.developer.SchemaValidation(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler) is not recognizable, atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I do not wish to implement any custom validator. The server should provided this type of service with simple and straightforward configuration.
The problem was: I was using the wrong package for #SchemaValidation.
The correct class that worked for me is com.sun.xml.ws.developer.SchemaValidation, which is provided in the file mw_home\modules\glassfish.jaxws.rt_1.3.0.0_2-1-5.jar (using WLS 10.3.6).
In the previous code segment I was referencing the wrong package: com.sun.xml.internal... but using the one provided by WebLogic worked instantly.
If you are using Maven and using the bundled JAR as dependency you might not have this library in the classpath, which led me to the problem. You need to add it to your classpath via dependency (provided scope only) and reference the correct package for that class name in your JAX-WS WebService class (an abstract class won't do it).
More information in the Enabling Schema Validation on the Server page.
This schema validation is enough for me at the moment since I do not need any custom behavior.
In my case: Maven project with many modules. I got the next error when was trying to deploy application into tomcat:
failed to parse runtime descriptor: javax.xml.ws.WebServiceException: Annotation #com.sun.xml.ws.developer.SchemaValidation(handler=class com.sun.xml.ws.server.DraconianValidationErrorHandler) is not recognizable, at least one constructor of class com.sun.xml.ws.developer.SchemaValidationFeature should be marked with #FeatureConstructor
I resolved problem by don't including jaxws-rt.jar in WEB-INF/lib.
It appears that this library already exists in the tomcat/lib folder.
Just tuned up pom.xml, setted provided scope for this dependency entry.
Now all works fine.
I am trying to get schema validation working for a JAX-WS Web Service deployed on Weblogic 10.3.3.
According to the documentation, this should be as simple as adding the annotation
"#SchemaValidation" to the endpoint class. However when I try this the following exception is thrown when the application is deployed:
Caused by: javax.xml.ws.WebServiceException:
Annotation#com.sun.xml.internal.ws.developer.SchemaValidation
(handler=class com.sun.xml.internal.ws.server.DraconianValidationErrorHandler)
is not recognizable,
atleast one constructor of class com.sun.xml.internal.ws.developer.SchemaValidationFeature
should be marked with #FeatureConstructor
at com.sun.xml.ws.binding.WebServiceFeatureList.getWebServiceFeatureBean(WebServiceFeatureList.java:169)
at com.sun.xml.ws.binding.WebServiceFeatureList.parseAnnotations(WebServiceFeatureList.java:141)
The error message is complaining that "com.sun.xml.internal.ws.developer.SchemaValidationFeature" does not have a constructor annotated with #FeatureConstructor. When I look at that class, it sure seems to have one:
#com.sun.xml.internal.ws.api.FeatureConstructor(value={"handler"})
public SchemaValidationFeature(java.lang.Class arg0);
I have googled around but cannot find any reference to this more than this fellow unfortunate soul who did not get any answers. It would be great if someone could point me in the right direction because at this moment I am stuck.
SchemaValidation annotation is working, but make sure you're importing correct class.
com.sun.xml.ws.developer.SchemaValidation
instead of
com.sun.xml.internal.ws.developer.SchemaValidation
The second class is bundled with JDK by default. The first one (used by weblogic) comes from glassfish.jaxws.rt_XXX.jar, so you may need to add this jar to your classpath explicitly.
I have faced the same problem recently.
To overcome this, I added the tag
<validation-request>true</validation-request>
to the file weblogic-webservices.xml
This enabled SOAP request validation on the app-server.
XML Structure of weblogic-webservices.xml
Note : I have not been able to use the #SchemaValidation tag successfully, but the above way - works as expected.