In Spring Boot 2.1.2, in the default log4j2.xml file, I noticed the following line:
<Property name="LOG_EXCEPTION_CONVERSION_WORD">%xwEx</Property>
I have been searching for the meaning of the %xwEx conversion pattern all day (yes, even the second page of Google), but I can't figure it out. And it is not listed in the table of patterns within the official documentation.
What does it mean?
Many thanks to Christoph for the answer on GitHub:
If I'm not mistaken this is a Spring-Boot specific converter plugin for log4j2. See ExtendedWhitespaceThrowablePatternConverter:
#Plugin(name = "ExtendedWhitespaceThrowablePatternConverter", category = PatternConverter.CATEGORY)
#ConverterKeys({ "xwEx", "xwThrowable", "xwException" })
public final class ExtendedWhitespaceThrowablePatternConverter
extends ThrowablePatternConverter {
// ....
}
As I'm not a team member don't take this for granted though.
Cheers,
Christoph
Related
That's not really an issue, beacause I found a workaround, but it conflicts with the documentation, so I wanted to share and document about it.
FYI Spring Boot 2.1.10 + SCSt 2.1.4 + RabbitMQ binder
I first implemented an application local error handler as given into official docs :
#StreamListener(Sink.INPUT)
public void handle(Person value) {
throw new RuntimeException("BOOM!");
}
#ServiceActivator(inputChannel = Sink.INPUT + ".my-group.errors") // won't work
public void error(ErrorMessage message) {
log.error("Handling ERROR: " + message.getPayload().getMessage());
}
spring.cloud.stream.bindings.input.destination=persons.inputs
spring.cloud.stream.bindings.input.group=my-group
But that didn't go well, to say the least. This is what I eventually had to keep:
#ServiceActivator(inputChannel = "persons.inputs.my-group.errors")
As you can see, what's happening is that I had to stick to the actual destination definition instead of the channel's; which I think is very uncomfortable! And I want to underline, again, that this is contradictory to the official docs here: https://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_application_error_handling (plus there are noticeable typos, IMHO: they even write that the destinationName is actually required)
Can anyone share thoughts about the situation with me? Have I done it right and am I right to think that this is wrong?
It's a bug in the documentation; it is, indeed, unfortunate the binding name was not used in the error channel name instead of the destination and group, but it's too late to change it now. We could possibly do something in a future release.
Please open 2 GitHub issues to
fix the documentation
consider adding an option to name the error channel using the binding name instead.
I am building my first ever Wicket project and I find that the amount of properties files in my code base is growing rapidly. Ideally I would like to contain all internationalization in a single file for each language/region. Just so I can find things easily.
I found out that my application properties file could be ideal for this. My application properties file is called ApiAdminApplication.properties. Now I am trying to add my translatables to this file, without making a mess of things.
According to the javadoc of ComponentStringResourceLoader this should be possible. Apparently the lookup order is as follows:
page1.properties => form1.input1.Required
page1.properties => Required
form1.properties => input1.Required
form1.properties => Required
input1.properties => Required
myApplication.properties => page1.form1.input1.Required
myApplication.properties => Required
The second to last line contains the behavior I am looking for, but cannot get to work.
I have a page called CustomerEditPage which in turn contains a form with id customerForm
So here is what I am adding to ApiAdminApplication.properties, and what I think should work according to the snippet above:
CustomerEditPage.customerForm.name=Customer name
Sadly, this does not work. I can however get this to work by leaving out the page name, and starting with customerForm, but that is not what I want. I want per page internationalization contained in a single file.
Can anyone give me some pointers on this? Thanks.
I think the javadoc of ComponentStringResourceLoader is just wrong and should be fixed.
To accomplish what you need you will need to extend ClassStringResourceLoader and override getResourcePath(). In your impl you will have to prepend the result with the name of the page that owns the Component passed as a parameter.
Then you will need to register your loader at ApiAdminApplication#init() method with:
getResourceSettings().getStringResourceLoaders().add(new MyClassStringResourceLoader(ApiAdminApplication.class))
see the defaults.
Please file a bug report at https://issues.apache.org/jira/projects/WICKET/issues so that the javadoc issue is fixed (or someone else who knows better than me how to accomplish this can explain us).
After reporting the bug I ended up doing what martin-g suggested, and extended ClassStringResourceLoader. For your convenience, here is what I did:
public class PrefixedStringResourceLoader extends ClassStringResourceLoader {
public PrefixedStringResourceLoader(Class<?> clazz) {
super(clazz);
}
protected String getResourcePath(final Component component) {
final Class<? extends Page> parentClass = component.getPage().getClass();
final String resPath = super.getResourcePath(component);
if (!resPath.isEmpty())
return String.format("%s.%s", parentClass.getSimpleName(), resPath);
return parentClass.getSimpleName();
}
}
There is a small gotcha to this. It always requires you to work with complete resource paths. This can be a bit tricky, I had some problems with the snippet below:
<input type="submit" wicket:id="save" wicket:message="value:save" />
This evaluated to CustomerEditPage.customerForm.save.save, where I expected it to become: CustomerEditPage.customerForm.save. This is not the case because the wicket:message actually becomes a child of the save form input.
I ended up going for:
<input type="submit" wicket:id="save" wicket:message="value:caption" />
Which evaluates to CustomerEditPage.customerForm.save.caption, which I find somewhat more readable. Of course, you could roll your own more advanced resource loader, but this one is good enough for me.
I'm using spring-data-mongodb 1.8.0; MongoDB 3.0.6; mongo-java-driver 3.1.0;spring-framework.version 4.0.3.
What I want is to query a list of user with certain phone numbers.
example for user: { "_id" : ObjectId("5625e5c32e1ca013a03f0d1b"), "phone" : "12345535"}
In Mongo Shell db.user.find({phone: { $in: [ "12345535", "123535"]}}) works fine. But in Spring I failed. Java Class User(with getters/setters omitted):
#Document(collection = "user")
public class User {
#Id
String id;
String phone;
}
What I tried is:
Query q = new Query(Criteria.where("phone").in("12345535","123535"));
mongoTemplate.find(q, User.class);
It comes to error:
Exception in thread "main" java.lang.IllegalAccessError: tried to access class org.springframework.beans.PropertyMatches from class org.springframework.data.mapping.PropertyReferenceException
at org.springframework.data.mapping.PropertyReferenceException.detectPotentialMatches(PropertyReferenceException.java:134)
at org.springframework.data.mapping.PropertyReferenceException.<init>(PropertyReferenceException.java:59)
at org.springframework.data.mapping.PropertyPath.<init>(PropertyPath.java:75)
at org.springframework.data.mapping.PropertyPath.create(PropertyPath.java:327)
at org.springframework.data.mapping.PropertyPath.create(PropertyPath.java:307)
at org.springframework.data.mapping.PropertyPath.from(PropertyPath.java:270)
at org.springframework.data.mongodb.core.convert.QueryMapper$MetadataBackedField.getPath(QueryMapper.java:837)
at org.springframework.data.mongodb.core.convert.QueryMapper$MetadataBackedField.<init>(QueryMapper.java:729)
at org.springframework.data.mongodb.core.convert.QueryMapper$MetadataBackedField.with(QueryMapper.java:740)
at org.springframework.data.mongodb.core.convert.QueryMapper$MetadataBackedField.with(QueryMapper.java:686)
at org.springframework.data.mongodb.core.convert.QueryMapper.getMappedKeyword(QueryMapper.java:258)
at org.springframework.data.mongodb.core.convert.QueryMapper.getMappedObjectForField(QueryMapper.java:200)
at org.springframework.data.mongodb.core.convert.QueryMapper.getMappedObject(QueryMapper.java:123)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:1700)
at org.springframework.data.mongodb.core.MongoTemplate.doFind(MongoTemplate.java:1690)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:602)
at org.springframework.data.mongodb.core.MongoTemplate.find(MongoTemplate.java:593)
at com.example.TestMongo.main(TestMongo.java:30)
But with changing field phone to id, same code works fine.
Query q = new Query(Criteria.where("id").in("5625e5c32e1ca013a03f0d1b","f0d1e"));
mongoTemplate.find(q, User.class);
With debugging, I find that it even didn't go to the request phase, error occurred in the query-building phase. It seems $in cannot be processed by PropertyPath.create, while in the id case, it can.
How can I fix this? I am a newbie and searched a lot but got no luck.Can you please help me out. Every answer is appreciated. Thanks guys.
As indicated in the announcement blog and the release train wiki, Spring Data MongoDB 1.8 requires Spring 4.1, ideally 4.1.8 which includes an important security fix.
The issue have appeared on me while using Spring 4.2.3.RELEASE and Spring MongoDB 1.6.1
Switching to Spring mongoDB 1.8.1 solves the issue.
(Meant as a comment to #OliverGierke's answer, but couldn't do it, due to low reputation level.)
We have implemented our repositories exactly as demonstrated in the Spring Data documentation. Everything was fine until we upgraded from STS 2.9 to STS 3.1. All attempts to get these errors to disappear have failed, and in some cases they don't even make sense! They don't match any properties in either the interface or the entities used!
Here is an example:
public interface CreditNotesRepository extends JpaRepository<CreditNotes, Long> {
CreditNotes findCurrentCreditNotes(Long shipmentDetailId);
}
The findCurrentCreditNotes is a named query in our entity. This code executes perfectly fine.
#NamedQueries({
#NamedQuery(name = "CreditNotes.getCount", query = "SELECT COUNT(f) FROM CreditNotes f"),
#NamedQuery(name = "CreditNotes.findCurrentCreditNotes", query =
"SELECT creditNotes FROM CreditNotes creditNotes"
+ " WHERE creditNotes.shipmentDetail.shipmentDetailId = ?1 "
+ " AND creditNotes.notesSeqNumber = (SELECT max(creditNotes2.notesSeqNumber) FROM CreditNotes creditNotes2"
+ " WHERE creditNotes.shipmentDetail.shipmentDetailId = creditNotes2.shipmentDetail.shipmentDetailId)")
})
And the error we get:
Invalid derived query! No property find found for type ca.cole.freight.model.CreditNotes
Although this is just a flag (doesn't affect compilation), it is annoying and confusing. Can anyone shed some light on this? And explain it to me like I'm 6 years old! ;)
At the post on the Spring Forum, Spring Team announced that
It is already fixed for STS 3.3.0
I didn't check this version yet. But I'm using 3.5.0.RELEASE and the problem comes back! My fix is to uncheck Invalid Derived Query
It's an IDE error explained in the following post:
http://forum.springsource.org/showthread.php?138585-Invalid-derived-query!-No-property-delete-found-for-type-java-lang-Object
In the meantime, you can turn off the validation in preferences/spring/project validators/Data validator uncheck invalid derived query and STS wont throw the marker anymore.
There is also workaround for this. Add #Query annotation on your method definition in Your repository without JPQL/SQL query defined.
Here is example :
#Query
List<OwnerModel> findByFirstNameAndAgeNotZero(#Param(value = "firstName") String firstName);
In this case named query OrderModel.findByFirstNameAndAgeNotZero will be used. Your Eclipse error Invalid derived query should also disappear without need of disabling validation as described by #Tuan Dang
Checked on Eclipse 4.5.1 with Spring plugin installed for #NamedQuery and #NamedNativeQuery.
I've just been going through this myself. Unfortunately, the implementation of Spring Data changed between 1.1 and 1.2. It no longer supports the <repository> XML declaration. You can set up a custom postfix, but by default, it expects a bean of class name <InterfaceName>Impl. If it can't find the custom repository implementation, you start getting errors like the one you're encountering. It's trying to create methods to query for objects based on names of methods in your interface.
An alternative is to back your Spring Data version down to 1.1 and specify a schemalocation of http://www.springframework.org/schema/data/jpa/spring-jpa-1.1.xsd in your XML.
The question says it all I'd like to use CacheBuilder, but my values are pulled in asynchronously. This worked previously with MapMaker as the CacheLoader wasn't a requirement. Now I'd like to know if I can hack this up or if there are any non deprecated alternatives. Thank you.
I think the question you're trying to ask is "How can I use CacheBuilder without having to specify a CacheLoader?" If that's the case, then there will be support for this in Guava release 11.0. In the meantime a build() method on CacheLoader is already checked into trunk (as of this morning):
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/cache/CacheBuilder.html
One method would be to make with generic parameters K and V as your desired outputs:
LoadingCache<K, ListenableFuture<V>> values = CacheBuilder.newBuilder()
.build(
new CacheLoader<K, ListenableFuture<V>>() {
public ListenableFuture<V> load(K key) {
/* Get your future */
}
});