openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: Unexpected 'right truncation' issue
Date Thu, 28 Apr 2016 08:14:44 GMT
Hi Sergey,
I have made some further changes to my POC at github, including more 
classes from CXF and adding a specific test case in attempting to 
replicate your original issue.

The additional test case is

https://github.com/ilgrosso/cxf-openjpa-poc/blob/master/src/test/java/net/tirasa/ilgrosso/cxfopenjpapoc/entity/BaseTest.java#L75

where, as you can see, I am removing first c1 then c2, with no issues.
I am not sure, though, if the various UserSubject instances involved are 
created by the test case in the way which resemble the real OAuth 2 
interaction or not.

Also, consider that I had to change the last lines of addClient (now 
provider.setClient returns the entity after merge).

Please note that I had to rework a bit with cascades and merges, maybe 
it is necessary to review your original merge order strategy.

Finally, I have tried to report the main entities involved in the 
following diagram:

https://drive.google.com/file/d/0B54ZHVmTeFXTeXBTX2plQlVVMjQ/view?usp=sharing

AFAICT, the relationships between BearerAccessToken and UserSubject are 
quite involved, especially when it comes to CASCADE, which might trigger 
some unwanted interactions.

HTH
Regards.

On 27/04/2016 18:25, Sergey Beryozkin wrote:
> I haven't made any progress today so I'll do something else for the 
> next few days to make me feel I can still do something and then return 
> to this issue :-)
>
> Thanks, Sergey
> On 27/04/16 10:39, Sergey Beryozkin wrote:
>> Hi Francesco
>>
>> many thanks, I'm sorry for involving you into this project :-), but it
>> is much appreciated you trying to help. I also hope my query is not off
>> topic for this list - as there might be some OpenJPA issue hiding there
>> (though the high chance is it is the way I misconfigured JPA mappings
>> that causes it).
>>
>> I've experimented for few days by trying to emulate this issue locally
>> in CXF JPAOAuthDataProviderTest/JPACodeDataProviderTest, but could not.
>> Perhaps your project will make it easier as it is closer to the real
>> deployment case.
>>
>> FYI, this test fails:
>>
>> https://github.com/apache/cxf-fediz/blob/master/systests/oidc/src/test/java/org/apache/cxf/fediz/systests/oidc/OIDCTest.java#L412

>>
>>
>>
>> This test preloads a packaged Fediz OIDC war and sends actions to it
>> remotely.
>>
>> Disabling all other tests and running only this test does the following
>> (which is what I described earlier) :
>> - create client1 and client2, get a code for Client 2 and exchange for a
>> token (i.e BearerAccessToken with a link to Client2 is saved), finally
>> start deleting clients starting from Client 1 and it fails
>> (DELETE triggers an insert)
>>
>> This is reproducible against the embedded Tomcat and a standalone Tomcat
>> though when I try to repeat the same sequence manually it is all OK.
>>
>> So I will spend some time on trying to narrow it down further. and
>> update you and what I have found.
>>
>> Many thanks for trying to help and sorry in advance for the noise (when
>> I report later it proved to be the misconfiguration :-))
>>
>> Sergey
>>
>>
>> On 27/04/16 08:24, Francesco Chicchiriccò wrote:
>>> Hi Sergey,
>>> I have created a (kind of) nailed-down version of your application at
>>>
>>> https://github.com/ilgrosso/cxf-openjpa-poc
>>>
>>> Essentially, I have grabbed few classes from CXF's
>>> cxf-rt-rs-security-oauth2 and injected in my own OpenJPA template
>>> project: as you can see, this imply using Spring and build-time
>>> enhancement.
>>>
>>> When you run 'mvn -Psqlgen' on it, you will get the full SQL schema
>>> under target/database.sql
>>>
>>> When you run 'mvn clean test' on it, you will get
>>>
>>> https://github.com/ilgrosso/cxf-openjpa-poc/blob/master/src/test/java/net/tirasa/ilgrosso/cxfopenjpapoc/entity/BaseTest.java

>>>
>>>
>>>
>>>
>>> executed, where I have grabbed some methods from CXF's
>>> JPAOAuthDataProviderTest
>>>
>>> As you can see, at the moment the only test case available works fine:
>>> please add another one which shows the problem you are experiencing,
>>> thanks.
>>>
>>> Regards.
>>>
>>> On 26/04/2016 17:33, Sergey Beryozkin wrote:
>>>> Hi Francesco, thanks, so this is what I get.
>>>>
>>>> I see Client references being removed first from various tables 
>>>> (Client
>>>> has @ElementCollection Lists of String for properties like
>>>> allowedGrantTypes, etc):
>>>>
>>>> 31896  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5]
>>>> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt
>>>> 969065640
>>>> DELETE FROM Client_allowedGrantTypes WHERE CLIENT_CLIENTID = ?
>>>> [params=?]
>>>> ......
>>>> omitting few ones...
>>>> 31897  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5]
>>>> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt
>>>> 583592238
>>>> DELETE FROM Client_registeredAudiences WHERE CLIENT_CLIENTID = ?
>>>> [params=?]
>>>>
>>>> *And Finally* DELETE from the Client table itself, which triggers that
>>>> INSERT:
>>>>
>>>>
>>>> 31898  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5]
>>>> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt
>>>> 2036246172
>>>> DELETE FROM Client
>>>>     WHERE clientId = ?
>>>> [params=?]
>>>> 31898  testUnitOpenJPA  TRACE  [http-bio-50025-exec-5]
>>>> openjpa.jdbc.SQL - <t 593160440, conn 570232632> executing prepstmnt
>>>> 890014212
>>>> INSERT INTO BearerAccessToken_parameters (BEARERACCESSTOKEN_TOKENKEY,
>>>>         propName, value)
>>>>     VALUES (?, ?, ?)
>>>> [params=?, ?, ?]
>>>>
>>>> I can't explain in, as I said I can only think that the fact there's a
>>>> Many to One relationship from AccessToken to Client causes an
>>>> auto-refresh of BearerAccessToken & related tables...
>>>>
>>>> I will experiment with moving few properties around...
>>>>
>>>> Cheers, Sergey
>>>>
>>>>
>>>> On 26/04/16 12:22, Francesco Chicchiriccò wrote:
>>>>> On 26/04/2016 11:44, Sergey Beryozkin wrote:
>>>>>> Hi All
>>>>>>
>>>>>> This is my first post to the list, I've tried to solve the issue
>>>>>> myself by checking StackOverflow, etc. I thought I'd give it a 
>>>>>> try at
>>>>>> OpenJPA users list, given that I do work with OpenJPA 2.4.0.
>>>>>>
>>>>>> I have the following class hierarchy (listing the most relevant
>>>>>> details):
>>>>>>
>>>>>> @Entity
>>>>>> public class Client {
>>>>>>    private String clientId;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Entity
>>>>>> public class BearerAccessToken extends ServerAccessToken {
>>>>>> }
>>>>>>
>>>>>> @MappedSuperclass
>>>>>> public abstract class ServerAccessToken extends AccessToken {
>>>>>>
>>>>>> @ManyToOne
>>>>>> private Client client;
>>>>>> }
>>>>>>
>>>>>> @MappedSuperclass
>>>>>> public abstract class AccessToken {
>>>>>>
>>>>>> @Id
>>>>>> String tokenKey;
>>>>>>
>>>>>> @ElementCollection
>>>>>> @MapKeyColumn(name="propName")
>>>>>> private Map<String, String> parameters = new LinkedHashMap<String,
>>>>>> String>();
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Now, after initializing the DB as follows:
>>>>>>
>>>>>> - Create Client instance (ex, "Client1"), add it to DB:
>>>>>>   Client c1 = new Client("Client1"); // and save
>>>>>> - Create another Client instance (ex, "Client2"), add it to DB:
>>>>>>   Client c2 = new Client("Client2"); // and save
>>>>>> - add a new BearerAccessToken associated with Client2 to DB:
>>>>>>   BearerAccessToken at = new BearerAccessToken();
>>>>>>   at.setClient(c2); // and save
>>>>>>
>>>>>> (Note no tokens are associated with Client1)
>>>>>>
>>>>>> the following sequence works OK:
>>>>>>
>>>>>> 1. delete Client2 (c2)
>>>>>> 2. delete Client1 (c1)
>>>>>>
>>>>>> This is OK, but if I start from deleting Client1 (the one with no
>>>>>> tokens) I immediately see:
>>>>>>
>>>>>> Caused by: <openjpa-2.4.0-r422266:1674604 fatal general error>
>>>>>> org.apache.openjpa.persistence.PersistenceException: data exception:
>>>>>> string data, right truncation;  table: BEARERACCESSTOKEN_PARAMETERS
>>>>>> column: VALUE {prepstmnt 453026232 INSERT INTO
>>>>>> BearerAccessToken_parameters (BEARERACCESSTOKEN_TOKENKEY, propName,
>>>>>> value) VALUES (?, ?, ?)} [code=3401, state=22001]
>>>>>>     at
>>>>>> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:5001).

>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I honestly do not know where to start looking. I've seen plenty of
>>>>>> StackOverflow messages about the "string data, right truncation",
in
>>>>>> this case AccessToken.parameters map is never touched by my code,
it
>>>>>> is empty. And the most confusing thing why this is even happening

>>>>>> when
>>>>>> I delete a Client with no tokens associated with it.
>>>>>>
>>>>>> I suspect when the Client is deleted, given a Many to One 
>>>>>> relationship
>>>>>> from ServerAccessToken to Client (but no OneToMany from Client to
>>>>>> ServerAccessToken), the mapping table gets refreshed in order to

>>>>>> find
>>>>>> any tokens which may be linking to Client being deleted). But 
>>>>>> that is
>>>>>> as far as I can get.
>>>>>>
>>>>>> Can someone please suggest why the above might be occurring, is it
a
>>>>>> mapping issue, or possibly OpenJPA issue ?
>>>>>
>>>>> Hi Sergey,
>>>>> I'd start by trying to understand exactly which SQL statement 
>>>>> generates
>>>>> the error above, so adding
>>>>>
>>>>> <property name="openjpa.Log" value="SQL=TRACE"/>
>>>>> <property name="openjpa.ConnectionFactoryProperties"
>>>>>      value="PrettyPrint=true, PrettyPrintLineLength=72"/>
>>>>>
>>>>> to your persistence.xml and trying again.
>>>>>
>>>>> HTH
>>>>> Regards.

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/



Mime
View raw message