Develop Reference

Exception is thrown when input with % is send to the back end - Thymeleaf

I have some html text inputs which send data to a back-end spring system. When I put just a (%) as a character I am getting the following Exception:
java.lang.IllegalArgumentException: Incomplete escaping sequence in input
14:17:34,269 INFO [stdout] (default task-4) at org.unbescape.uri.UriEscapeUtil.unescape(UriEscapeUtil.java:617)
14:17:34,269 INFO [stdout] (default task-4) at org.unbescape.uri.UriEscape.unescapeUriQueryParam(UriEscape.java:1702)
14:17:34,269 INFO [stdout] (default task-4) at org.unbescape.uri.UriEscape.unescapeUriQueryParam(UriEscape.java:1668)
14:17:34,269 INFO [stdout] (default task-4) at org.thymeleaf.spring5.util.SpringRequestUtils.checkViewNameNotInRequest(SpringRequestUtils.java:55)
14:17:34,269 INFO [stdout] (default task-4) at org.thymeleaf.spring5.view.ThymeleafView.renderFragment(ThymeleafView.java:275)
14:17:34,269 INFO [stdout] (default task-4) at org.thymeleaf.spring5.view.ThymeleafView.render(ThymeleafView.java:190)
I am encoding the data before is sent to the back-end using JS's encodeURIComponent method and in the link the % becomes %25 which is the correct encoded value but why does it throw an exception and what is the possible solution to this I am out of ideas tbh.
Thank you in advance for your responses :)

You did not disclose more information other than "When I put just a (%) as a character" and "I am encoding the data".
My crystal bulb is telling me there is some http(s) request and one of the request parameters contains an encoded percentage sign only. When this request is parsed by the server the %25 is decoded back into %. So far no problem.
But is it possible that the application now tries to decode the data itself and just sees the % sign? Then it would come back with exactly the error that you see.
In that case you might want to double encode: % -> %25 -> %2525

change your thymeleaf version.
<properties>
<thymeleaf.version>3.0.13.RELEASE</thymeleaf.version>
</properties>
for more information about this bug, you can read about it. hope it will resolve your issue.[Thymeleaf Issue#255]
[1]: https://github.com/thymeleaf/thymeleaf-spring/issues/255

Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint

Hi guys I have the following problem :
I have a back-end server written in Spring and working with PostgreSQL. At first, all was OK but now my friend created a SQL script for filling the database with test data. And here we go :
19:46:30,253 INFO [stdout] (default task-6) Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "user_pkey"
19:46:30,254 INFO [stdout] (default task-6) Detail: Key (id)=(1) already exists.
19:46:30,254 INFO [stdout] (default task-6) at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2497)
19:46:30,254 INFO [stdout] (default task-6) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2233)
19:46:30,254 INFO [stdout] (default task-6) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:310)
19:46:30,254 INFO [stdout] (default task-6) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:446)
19:46:30,254 INFO [stdout] (default task-6) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:370)
19:46:30,255 INFO [stdout] (default task-6) at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:149)
19:46:30,255 INFO [stdout] (default task-6) at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:124)
19:46:30,255 INFO [stdout] (default task-6) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:197)
19:46:30,256 INFO [stdout] (default task-6) ... 158 more
In that script, we also have some test data for users. And this error is throwing during an attempt to sign up. I understand, this error saying that I cant save user with an existing id to the database. But I actually did not set the id for the user. When I send user to save() method user id = null, and I believe that Hibernate should look at the database or at user_id_sequence and choose last id + 1 for the current saving user. At least it worked like that until we filled our database with the test data. The question is why Hibernate is not choosing (last id + 1) but trying to save a new user with an existing id = 0? Is there any way to solve it?
Id generating strategy :
#Getter
#Setter
#MappedSuperclass
#EqualsAndHashCode
#NoArgsConstructor
#ToString(exclude = {"deleted", "updated"})
public class BaseEntity {
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
// ...
}
Hibernate configuration :
datasource.url=**********
datasource.username=**********
datasource.password=**********
datasource.driver=org.postgresql.Driver
hibernate.show_sql=false
hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.batch.size=200
hibernate.hbm2ddl.auto=update
Sql script looks like a simple script for filling the database with test data :
INSERT INTO public.country (id, created, deleted, updated, code, name, telephone_prefix, continent_id) VALUES (101, NULL, false, NULL, 'ISR', 'Israel', 972, NULL);
....

Do you specify a an ID for your seeded data script ? If you do and they are positive numbers, you can try changing the ID to negative numbers. If you don't specify the ID you can try specifying the ID and make them negative numbers

Mybatis - error occurred during closing connection

I'm using mybatis connect to oracle.
My mybatis config is:
<settings>
<setting name="lazyLoadingEnabled" value="true" />
<setting name="aggressiveLazyLoading" value="false" />
<setting name="logImpl" value="${logImpl}" />
<setting name="defaultStatementTimeout" value="10" />
</settings>
<environments default="default">
<environment id="default">
<transactionManager type="JDBC" />
<dataSource type="POOLED">
<property name="driver" value="${jdbc.driver}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<property name="poolPingConnectionsNotUsedFor" value="290000"/>
<property name="poolPingQuery" value="SELECT COUNT(*) FROM RESORT"/>
<property name="poolPingEnabled" value="true"/>
</dataSource>
</environment>
</environments>
My code of open session is like
SqlSession sqlSession = factory.openSession();
Object result = null;
try
{
QueryInfoMapper mapper = sqlSession.getMapper(QueryInfoMapper.class);
result = mapper.queryInfoFromOpera(mybatisMapping);
} finally
{
sqlSession.close();
}
Because of application scoped of the class, and sqlSession could not be used in application scope, so I have to manage sqlSession by myself.
The log is
2019-04-11 15:30:35,773 INFO [stdout] (default task-60) Opening JDBC Connection
2019-04-11 15:30:41,860 INFO [stdout] (default task-57) Bad connection. Could not roll back
2019-04-11 15:30:41,861 INFO [stdout] (default task-57) Claimed overdue connection 962608913.
2019-04-11 15:30:41,861 INFO [stdout] (default task-57) A bad connection (962608913) was returned from the pool, getting another connection.
2019-04-11 15:30:41,895 INFO [stdout] (default task-57) Created connection 1812494479.
2019-04-11 15:30:41,895 INFO [stdout] (default task-57) Setting autocommit to false on JDBC Connection [oracle.jdbc.driver.T4CConnection#6c08788f]
2019-04-11 15:30:41,895 INFO [stdout] (default task-57) ==> Preparing: SELECT TRAVEL_AGENT_NAME FROM( SELECT TRAVEL_AGENT_NAME FROM OPERA.NAME_RESERVATION WHERE RESV_NAME_ID = ? ) WHERE ROWNUM = 1
2019-04-11 15:30:41,896 INFO [stdout] (default task-57) ==> Parameters: 288541(String)
2019-04-11 15:30:41,900 INFO [stdout] (default task-57) <== Columns: TRAVEL_AGENT_NAME
2019-04-11 15:30:41,900 INFO [stdout] (default task-57) <== Row: null
2019-04-11 15:30:41,900 INFO [stdout] (default task-57) <== Total: 1
2019-04-11 15:30:41,900 INFO [stdout] (default task-57) Resetting autocommit to true on JDBC Connection [oracle.jdbc.driver.T4CConnection#6c08788f]
2019-04-11 15:30:41,900 INFO [stdout] (default task-57) Closing JDBC Connection [oracle.jdbc.driver.T4CConnection#6c08788f]
2019-04-11 15:31:00,788 INFO [stdout] (default task-60) Bad connection. Could not roll back
2019-04-11 15:31:00,788 INFO [stdout] (default task-60) Claimed overdue connection 1228464923.
2019-04-11 15:31:00,788 INFO [stdout] (default task-60) A bad connection (1228464923) was returned from the pool, getting another connection.
2019-04-11 15:31:00,820 INFO [stdout] (default task-60) Created connection 265625885.
2019-04-11 15:31:00,820 INFO [stdout] (default task-60) Setting autocommit to false on JDBC Connection [oracle.jdbc.driver.T4CConnection#fd5211d]
2019-04-11 15:31:00,820 INFO [stdout] (default task-57) Returned connection 1812494479 to pool.
Seeing the log, according to the timestamp, it seems happens during closing connection(which is transaction here)
But it takes 9s or 19s to close it. The second log is "Bad connection. Could not roll back". I can't locate where is the really cause. And which method takes so much time. This issue doesn't happen every time but randomly.
I thought to set <property name="poolMaximumActiveConnections" value="40" /> to increase connections. I'm not sure if it would help.
What would be the cause of failed to close connection/transaction? How can I avoid the failed of closing connection/transaction?
===========================
Update: I met this issue again and log comes something different:
2019-04-13 15:42:31,812 INFO [stdout] (default task-86) Opening JDBC Connection
2019-04-13 15:42:35,493 INFO [stdout] (default task-62) Execution of ping query 'SELECT COUNT(*) FROM RESORT' failed: IO Error: Socket read timed out
2019-04-13 15:42:35,493 INFO [stdout] (default task-62) Connection 1963609369 is BAD: IO Error: Socket read timed out
2019-04-13 15:42:35,493 INFO [stdout] (default task-62) A bad connection (1963609369) was returned from the pool, getting another connection.
2019-04-13 15:42:35,493 INFO [stdout] (default task-62) Checked out connection 195963529 from pool.
2019-04-13 15:42:35,493 INFO [stdout] (default task-62) Testing connection 195963529 ...
2019-04-13 15:42:54,448 INFO [stdout] (default task-62) Execution of ping query 'SELECT COUNT(*) FROM RESORT' failed: IO Error: Socket read timed out
2019-04-13 15:42:54,448 INFO [stdout] (default task-62) Connection 195963529 is BAD: IO Error: Socket read timed out
2019-04-13 15:42:54,448 INFO [stdout] (default task-62) A bad connection (195963529) was returned from the pool, getting another connection.
2019-04-13 15:42:54,479 INFO [stdout] (default task-62) Created connection 741137137.
Btw, I'll change the ping sql to SELECT 1 FROM DUAL.
What could cause this socket read timed out?

I can see several problems here:
potentially heavy ping query (as pointed by beny23)
long close connection operation
incorrect behaviour of the mybatis connection pool
You definitely need to use SELECT 1 FROM DUAL as a ping query. Otherwise you a doing some not so cheap operation on every connection open.
The long close and IO Error: Socket read timed out suggests that there is either some network connectivity issue or oracle server availability issue or both.
It makes sense to check oracle healthiness at the time when this issue happens. Does it respond to other queries at that time? What is the CPU/io/memory/swap usage etc. If the server is under very high load it may be that it does not respond in time.
Checking the issues with network connectivity is a very broad topic. The most reliable (and also complex) way I know is to capture network traffic (with tools like tcpdump or WireShark) on both ends and compare them.
Then there's an issue with mybatis connection pool.
First of all some background about how mybatis connection pool works.
One important and not obvious thing is that mybatis connection pool implementation forcefully returns connections to the pool if they are used for too long. Here's the quote from the documentation:
poolMaximumCheckoutTime – This is the amount of time that a Connection can be "checked out" of the pool before it will be forcefully returned. Default: 20000ms (i.e. 20 seconds)
It means that if the application tries to open new connection and all connections are busy then mybatis will close the oldest connection if it was in use for more than 20 seconds (by default).
It is by itself may be a very unexpected behaviour if you have some long running queries. Another and probably bigger problem is how this is implemented in mybatis. In order to grab a connection the request to rollback the transaction is done from the thread which requested new connection (In the example above thread default task-57 is holding the connection and thread default task-60 tries to get the connection from the pool).
This is the problem because oracle jdbc driver requires proper synchronization when accessing the connection from multiple threads and mybatis does not do that:
Controlled serial access to a connection, such as that provided by connection caching, is both necessary and encouraged. However, Oracle strongly discourages sharing a database connection among multiple threads. Avoid allowing multiple threads to access a connection simultaneously. If multiple threads must share a connection, use a disciplined begin-using/end-using protocol.
So this failure to synchronize access from multiple thread to the shared resource (the connection) may cause all kinds of consistency problems and I do not exclude the possibility that the problem with closing the connection is caused by the fact that connection had gotten into some inconsistent state earlier because of the lack of the synchronization.
Increasing the pool size removes this problem for the given load as the situation when the pool is exhausted does not happen (or happens less frequently).
Note that concurrency issues are very tricky to reproduce and positive synthetic test gives you virtually no guarantee. This a broad topic so recommend you to look to Goetz book for details.
I would change the connection pool implementation, namely use https://github.com/swaldman/c3p0 or https://commons.apache.org/proper/commons-dbcp/ or https://brettwooldridge.github.io/HikariCP/.

Jersey Client and CXF mixed up (multipart issue)

I have a legacy app that mixes both CXF and jersey-client.
When I am using the Jersey Client but CXF takes over.
Response response = client
.target("http://example.com")
.register(MultiPartFeature.class) //error when run this line
.request(MediaType.APPLICATION_JSON )accept type
.put(Entity.entity(request, mediaType), Response.class);
When using a jersey client to retrieve multipart from a jersey server, this action is handled by cxf and throw error:
java.lang.RuntimeException: java.lang.InstantiationException: org.glassfish.jersey.media.multipart.internal.FormDataParamValueFactoryProvider
21:09:51,574 INFO [stdout] (default task-31) at org.apache.cxf.jaxrs.impl.ConfigurationImpl.createProvider(ConfigurationImpl.java:208) ~[cxf-rt-frontend-jaxrs-3.1.5.jar:3.1.5]
21:09:51,574 INFO [stdout] (default task-31) at org.apache.cxf.jaxrs.impl.ConfigurationImpl.register(ConfigurationImpl.java:176) ~[cxf-rt-frontend-jaxrs-3.1.5.jar:3.1.5]
21:09:51,574 INFO [stdout] (default task-31) at org.apache.cxf.jaxrs.impl.ConfigurableImpl.register(ConfigurableImpl.java:91) ~[cxf-rt-frontend-jaxrs-3.1.5.jar:3.1.5]
21:09:51,574 INFO [stdout] (default task-31) at org.apache.cxf.jaxrs.impl.ConfigurableImpl.doRegister(ConfigurableImpl.java:117) ~[cxf-rt-frontend-jaxrs-3.1.5.jar:3.1.5]
21:09:51,574 INFO [stdout] (default task-31) at org.apache.cxf.jaxrs.impl.ConfigurableImpl.register(ConfigurableImpl.java:108) ~[cxf-rt-frontend-jaxrs-3.1.5.jar:3.1.5]
There is an issue
enter link description here

Use JerseyClientBuilder instead of ClientBuilder. The latter will default to using the CXF client. And don't use JerseyClientBuilder.newClient(). That is inherited from ClientBuilder (which JerseyClientBuilder extends), so it has the default behavior previously mentioned about defaulting to using CXF. Use JerseyClientBuilder.createClient() or instantiate the builder, call some methods on it, then call build(). You can look at the source code.

Entity not being persisted when using jpa

I am using the following field annotations:
#Id
#TableGenerator( name = "comment_sequence", pkColumnValue = "comment_sequence" )
#GeneratedValue( strategy = GenerationType.TABLE, generator = "comment_sequence" )
private Long id_comment;
The sql for creating the table is:
CREATE TABLE hibernate_sequences ( sequence_name VARCHAR(255) NOT NULL, next_val bigint, PRIMARY KEY ( sequence_name ) );
INSERT INTO hibernate_sequences VALUES ( 'comment_sequence', 1 );
But the entity simply is not persisting. Any idea of what could be happening? Am I doing something wrong with the code presented above?
EDIT:
I suppressed a few information in the original post, I'm sorry (asked in the middle of night almost sleeping =/).
The entity is being properly created, if I do change the strategy to SEQUENCE and add the SQL CREATE SEQUENCE hibernate_sequence everything works fine (it is persisted), but I want to use the TABLE strategy to hold each table sequence in a row on hibernate_sequences.
The only exceptions I have is the TransactionRolledbackException due to a NullPointerException caused by a failing test in the integration test. Nothing explicit for why it is not inserting the data.
I get the following hibernate output when using hibernate.show_sql = true:
...
12:38:48,753 INFO [stdout] (pool-5-thread-1) Hibernate:
12:38:48,754 INFO [stdout] (pool-5-thread-1) insert
12:38:48,755 INFO [stdout] (pool-5-thread-1) into
12:38:48,756 INFO [stdout] (pool-5-thread-1) cm_comment
12:38:48,757 INFO [stdout] (pool-5-thread-1) (cd_status, ds_message, dt_alt, dt_inc, id_user_alt, id_user_inc, id_problem, id_comment)
12:38:48,758 INFO [stdout] (pool-5-thread-1) values
12:38:48,759 INFO [stdout] (pool-5-thread-1) (?, ?, ?, ?, ?, ?, ?, ?)
12:38:48,766 INFO [stdout] (pool-5-thread-1) Hibernate:
12:38:48,766 INFO [stdout] (pool-5-thread-1) select
12:38:48,767 INFO [stdout] (pool-5-thread-1) commentent0_.id_comment as id1_6_,
12:38:48,768 INFO [stdout] (pool-5-thread-1) commentent0_.cd_status as cd2_6_,
12:38:48,770 INFO [stdout] (pool-5-thread-1) commentent0_.ds_message as ds3_6_,
12:38:48,771 INFO [stdout] (pool-5-thread-1) commentent0_.dt_alt as dt4_6_,
12:38:48,772 INFO [stdout] (pool-5-thread-1) commentent0_.dt_inc as dt5_6_,
12:38:48,773 INFO [stdout] (pool-5-thread-1) commentent0_.id_user_alt as id6_6_,
12:38:48,774 INFO [stdout] (pool-5-thread-1) commentent0_.id_user_inc as id7_6_,
12:38:48,775 INFO [stdout] (pool-5-thread-1) commentent0_.id_problem as id8_6_
12:38:48,776 INFO [stdout] (pool-5-thread-1) from
12:38:48,777 INFO [stdout] (pool-5-thread-1) cm_comment commentent0_
12:38:48,778 INFO [stdout] (pool-5-thread-1) where
12:38:48,779 INFO [stdout] (pool-5-thread-1) commentent0_.id_problem=?
12:38:48,840 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-5-thread-1)
...
java.lang.AssertionError: expected:<1> but was:<0>
...
I am not sure if this can be related but in a previous test I get the error:
12:50:36,510 INFO [org.jboss.as.ejb3] (pool-4-thread-1) JBAS014101: Failed to find SFSB instance with session ID {[-98, -17, -32, -33, 63, 107, 74, 59, -76, -127, -19, 29, 24, 45, -50, 5]} in cache
When I change postgresql.conf for log_statement = 'all' and check in the pg_log directory after running the app I dont see any logs. So I am not sure how I can enable that option.
I am also using Arquillian, arquillian persistence API, and a JBoss managed instance for integration testing. I am going to update the tags cause this could be related to any of those.

Your "declaration" of TableGenerator isn't given any info about which table it should look in / use, all you're giving it is a pkColumn name ....
Try:
#TableGenerator(
name = "comment_sequence",
table = "hibernate_sequences",
pkColumnName = "sequence_name",
valueColumnName = "next_val",
pkColumnValue = "comment_sequence",
allocationSize=1)
allocationSize=1 should probably be something larger than 1 ... when you've verified it is working.
(Down the line, be aware of potential locking problems if you use this strategy and put a lot of generators into the same table in the db - if you're application is creating "lots of" entities.)