For historical reasons. The deployment goes through the same code as
CMP (and does nothing unless java2db is executed), and CMP has JDO
message prefixes.
regards,
-marina
Tom Ware wrote:
> I have a quick indirectly related question.
>
> Why does the exception hava a JDO error code?
>
> -Tom
>
> Pramod Gopinath wrote:
>
>> Hi Sahoo
>> As far as Java2db is concerned no changes have been made to the code
>> base to not print out the error text when printing the error code.
>> Rest assured that any major changes like that would be announced to
>> the whole team well in advance. Now if there is a bug then I would be
>> very interested in isolating it and fixing it ASAP before any external
>> users run into it.
>>
>> I did a complete checkout (maven checkout bootstrap-all build
>> configure-runtime) and then tried to reproduce your problem. I have
>> tried to deploy an application using the application server
>> environment and then used a standalone j2ee app too, but so far have
>> not been able to reproduce the problem that you have reported. Can you
>> provide your application and the exact steps to reproduce this issue.
>>
>> When a SQL statement is being executed we rely on the jdbc driver to
>> execute the statement and return the result set. Currently we do not
>> have any infrastructure in place to catch the exception being thrown
>> by the jdbc driver and convert that into any other format. We can
>> discuss if there is any merit in going down this path. I would also be
>> interested in getting information from the team members who worked on
>> this feature during the 8.x days to get more input.
>>
>> Also could U try out Mitesh' s suggestion of adding the clause
>> "retrieveMessagesFromServerOnGetMessage=true?" to the jdbc url path.
>> This is just for Derby to see if U are getting any additional
>> messages. When running my tests I did not have this clause but it
>> still returned me messages about table not existing/table existing and
>> so on.
>>
>> Thanks
>> Pramod
>>
>> Sanjeeb Kumar Sahoo wrote:
>>
>>
>>> Pramod & the team,
>>>
>>> I have started to see that we are just printing the error code and
>>> not the error text. e.g. I got the following message in my console
>>> while trying to deploy with --dropandcreatetables=true:
>>>
>>> JDO76614: Deployment encountered SQL Exceptions:
>>> JDO76609: Got SQLException executing statement "DROP TABLE
>>> USERCREDENTIAL": org.apache.derby.client.am.SqlException: DERBY SQL
>>> error: SQLCODE: -1, SQLSTATE: XSAI2, SQLERRMC: 10560XSAI2.S
>>> JDO76614: Deployment encountered SQL Exceptions:
>>> JDO76609: Got SQLException executing statement "CREATE TABLE
>>> USERCREDENTIAL (NAME VARCHAR(255) NOT NULL, PASSWORD VARCHAR(255),
>>> PRIMARY KEY (NAME))": org.apache.derby.client.am.SqlException: DERBY
>>> SQL error: SQLCODE: -1, SQLSTATE: X0Y32, SQLERRMC:
>>> Table/ViewUSERCREDENTIALSchemaAPPX0Y32.S
>>>
>>>
>>> 1. I don't understand what this error means. If I were a SQL expert,
>>> I probably would not use Java Persistence. So for users like me, it
>>> is a bit unfriendly to refer to database manual.
>>>
>>> 2. I was able to use my application successfully. Now I see them not
>>> working. Is anything broken in Java2DB recently? If, is there a bug?
>>>
>>> Thanks,
>>> Sahoo
>>>
>
>