Bug report read and agreed, that's what I'm facing!
If helps, I voted for 3235.
Thanks!
Edson Richter
Sahoo escreveu:
> Yes, TopLink is definitely mixing things up. See issue 3235 [1] where
> this exact problem is discussed recently. As you pointed out, closing
> the emf during undeployment won;t avoid the class linking issue. I was
> thinking that you actually deploy the same app (with same war/ear
> name) twice.
>
> In any case, you should add the code that closes the emf - that makes
> it a better app.
>
> Thanks,
> Sahoo
>
> [1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=3235
>
> Edson Carlos Ericksson Richter wrote:
>> Ok, I'll create a lifecicly listener capable of doing that.
>> But I don't see how this could make difference for my
>> ClassCastException problem.
>>
>> Step by step:
>>
>> 1) Create an application that uses JPA
>> 2) Build the WAR distro, and make two copies: MyApp1.war, MyApp2.war
>> 3) Edit MyApp1.war and modify persistence.xml to point do DB1. PU
>> name stay "MyAppPU".
>> 4) Edit MyApp2.war and modify persistence.xml to point do DB2. PU
>> name stay "MyAppPU".
>> 5) Deploy MyApp1
>> 6) Deploy MyApp2
>> 7) Access MyApp1, everything works fine. Objects
>> info.everest.entities.Customer are loaded from DB1 and HTML table
>> full of data is shown.
>> 8) Access MyApp2. Exception is thrown: ClassCastException on
>> info.everest.entities.Customer.
>>
>> So, to me appear being:
>> a) Problem related to single JVM and two apps with same PU name -
>> TopLink (or JPA) is mixing things;
>> b) A cache problem, since both applications use same class
>> (info.everest.entities.Customer) - probable a TopLink issue.
>>
>>
>> I expect this help a little...
>>
>> Regards,
>>
>>
>> Edson Richter
>>
>>
>>
>> Sahoo escreveu:
>>> Hi Edson Richter,
>>>
>>> TopLink maintains a map of PU names to EMF (this is actually a bug
>>> in the current implementation). This map is global for all the
>>> applications in the JVM, because TopLink is loaded by a class loader
>>> which is the parent of all application class loaders. You are
>>> probably *not* closing the EMF when the app gets undeployed. So,
>>> when the app is re-deployed, the old EMF is used. Try doing
>>> emf.close() in the code that gets called when the app is undeployed.
>>> The relationship between undeployment and redeployment is that an
>>> app first gets undeployed when it is redeployed. You should be able
>>> to find some hooks in the app which gets called during undeployment.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Edson Carlos Ericksson Richter wrote:
>>>>
>>>>> Why can't you have 2 different PU names in 2 different
>>>>> persistence.xml files (that reference the same Entities - this
>>>>> shouldn't be the problem)?
>>>>>
>>>>> thanks,
>>>>> -marina
>>>> Actually, I don't have 2 different persistence.xml... It's only 1
>>>> app being deployied twice - only connection setting is changed on
>>>> final WAR, just before deployment (much like if I open the WAR with
>>>> WinZip, edit Persistence.xml to set new connection settings, then
>>>> update WAR).
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Edson 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>