That would be an interesting exercise as I've seen similar questions before.
Let us know how it goes ;).
thanks,
-marina
Edson Carlos Ericksson Richter wrote:
> IT: there is some way to get the original exception (the one throws by
> the database driver)?
> Maybe I can write a small lib capable of translating (or, at least)
> treat the error throws by TopLink. Actually, I need to follow stack
> trace... Maybe is necessary to execute getCause() until returns null?
>
> Regards,
>
> Richter
>
> Marina Vatkina escreveu:
>
>> Hi,
>>
>> This is a complicated one. Not only the spec doesn't prescribe
>> on how to extract SQL exceptions, i.e. there is no guarantee
>> that it's a nested exception, or the level at which it is nested,
>> but the container can add more exceptions on top of the provider,
>> if you try to parse it on the client side.
>> And yes, if you want to guarantee the exact mapping between an
>> error code and the text message, you need to do it yourself (and
>> do it for all dbs that you plan to work with).
>>
>> thanks,
>> -marina
>>
>> Edson Carlos Ericksson Richter wrote On 09/09/06 11:09,:
>>
>>
>>> Hi!
>>>
>>> I'm creating a proof of concept for a first web app completely based
>>> on JPA and Glassfish.
>>> This app will relay heavy on CRUD operations, so first decision was
>>> design database first or entity beans (and relay database creation to
>>> persistence layer - Top Link, in this case). I choose create
>>> entities. Until now, this was a wise choice.
>>> Second decision is how many layers app will have, and what
>>> technologies will be there. Decision was made to:
>>>
>>> * View: JSP
>>> * Controller: Servlet
>>> * Model: Entities and specialized beans when necessary
>>> * Business logic: Singleton classes
>>> * High level persistence: Singleton broker classes
>>> * Low level persistence: TopLink essentials through annotations
>>> * Database: undefined. During development, JavaDB. For deployment,
>>> Oracle and MS SQL Server.
>>>
>>> In this architecture, all levels re-throw every exception to the
>>> Controller, who register on the log and prepare message for
>>> presentation (made by View layer).
>>> The problem is: how could the Controller capture the error message
>>> from persistence layer for treatment of, let's say, duplicate key?
>>> TopLink capture database exceptions and transform them into common
>>> "DuplicateKeyException"? Or I should deal with different error codes
>>> from each database and do it myself?
>>>
>>> Thanks,
>>>
>>> Richter
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net