persistence@glassfish.java.net

Re: Code review for 1218?

From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
Date: Thu, 05 Oct 2006 12:31:35 -0700

9.0 UR1 is already done, so no change will happen there. The 9.1 change
results in using "toplink.application-location" property value if specified
inside the container the same way as outside the container.

If not specified, outside the container, it defaults to the current directory;
inside a container, the files are generated into the same location as other
artifacts generated by our application server during deployment process.

HTH,
-marina

Rebecca Parks wrote:
> I've read through the thread and am still not sure exactly how the
> behavior will change. Also, will it change for 9.0 UR1 as well?
>
> June
>
> Marina Vatkina wrote On 10/04/06 19:09,:
>
>> We all seem to agree that this is a better option.
>> Luckily, this is exactly what I did :). I'll check
>> in my changes tomorrow.
>>
>> June,
>>
>> Please note that the behavior will change for 9.1.
>>
>> thanks,
>> -marina
>>
>> Rochelle Raccah wrote On 10/04/06 15:56,:
>>
>>
>>> My opinion is that if a user bothered to specify the property, we
>>> should use it. The only reason it would be specified and they
>>> wouldn't care is if it used to be a Java SE application and it was
>>> converted to be used in the container or they got the application
>>> from somewhere else (example, etc.). Otherwise, (and I think this is
>>> the more common case,) the user explicitly said they care about where
>>> it goes, so we should pay attention to that.
>>>
>>> Thanks,
>>> Rochelle
>>>
>>> Marina Vatkina wrote:
>>>
>>>
>>>
>>>
>>>> Tom Ware wrote On 10/04/06 10:06,:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Marina,
>>>>>
>>>>> I guess that's a question for the Sun team to decide.
>>>>>
>>>>> Ignoring that setting is only a problem is the user has set the
>>>>> value with the intent of either looking at or using the generated
>>>>> files. If the file does not appear where they expect it to be, it
>>>>> could cause them problems.
>>>>>
>>>>
>>>> That's what I'm also concerned about.
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -Tom
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> Do you see a problem if GF ignores its value and uses internal
>>>>>> directories
>>>>>> instead?
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Tom Ware wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Marina,
>>>>>>>
>>>>>>> toplink.application-location is by our ddl generation independant
>>>>>>> of where we are deployed.
>>>>>>>
>>>>>>> -Tom
>>>>>>>
>>>>>>> Marina Vatkina wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Pramod,
>>>>>>>>
>>>>>>>> Then we have another bug, as currently the user's value is used
>>>>>>>> to create
>>>>>>>> the files, but not used when the files are read for processing :(.
>>>>>>>>
>>>>>>>> Tom,
>>>>>>>>
>>>>>>>> Do you use this property in TopLink integration with other app
>>>>>>>> servers? (It
>>>>>>>> might be strange if the users have different behavior when using
>>>>>>>> the same
>>>>>>>> JPA impl on different app servers).
>>>>>>>>
>>>>>>>> June,
>>>>>>>>
>>>>>>>> Is it documented in the docs?
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> -marina
>>>>>>>>
>>>>>>>> Pramod Gopinath wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Marina/Jielin
>>>>>>>>> The way java2db was designed and implemented the property -
>>>>>>>>> "toplink.application-location" was available for a user only in
>>>>>>>>> the javaSE environment.
>>>>>>>>>
>>>>>>>>> In the container environment this property value was maintained
>>>>>>>>> by the container. If the user specified a value in
>>>>>>>>> "toplink.application-location" this would be ignored. This
>>>>>>>>> information is also documented at
>>>>>>>>> http://blogs.sun.com/java2dbInGlassFish/entry/automatic_table_generation_feature_in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Pramod
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marina Vatkina wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Jielin,
>>>>>>>>>>
>>>>>>>>>> Good question.
>>>>>>>>>>
>>>>>>>>>> Team,
>>>>>>>>>>
>>>>>>>>>> Does anybody have a strong opinion about this?
>>>>>>>>>> Should "toplink.application-location" be ignored by GF
>>>>>>>>>> deployment and an
>>>>>>>>>> internal location be used instead? Or should the location
>>>>>>>>>> where to put the
>>>>>>>>>> generated files (the property name is probably confusing, but
>>>>>>>>>> that's a
>>>>>>>>>> different story) be preserved?
>>>>>>>>>>
>>>>>>>>>> I would think that if the user specified the location, they
>>>>>>>>>> cared about
>>>>>>>>>> it. The only problem would be a /tmp where files would
>>>>>>>>>> disappear after
>>>>>>>>>> reboot, but this may be a documentation note.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> -marina
>>>>>>>>>>
>>>>>>>>>> jielin wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi, Marina,
>>>>>>>>>>>
>>>>>>>>>>> The code seems okay.
>>>>>>>>>>> I have one question for my own learning: for the application
>>>>>>>>>>> location defined in persistence.xml, should this location be
>>>>>>>>>>> overrided by appserver specified dir in glassfish environment
>>>>>>>>>>> ( I mean in EJB container)?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Jielin
>>>>>>>>>>>
>>>>>>>>>>> Marina Vatkina wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Jielin,
>>>>>>>>>>>>
>>>>>>>>>>>> See https://glassfish.dev.java.net/issues/show_bug.cgi?id=1218.
>>>>>>>>>>>>
>>>>>>>>>>>> Can you please review the attached? TopLink allows you to
>>>>>>>>>>>> specify location of the drop/create files, and before this
>>>>>>>>>>>> fix, GF code ignored such property
>>>>>>>>>>>> when constructing file name for the execution of the jdbc file.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> -marina
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>