Hi Kim,
I am bit confused about your experiment. Can you please send me the
original persitence.xml that does not work on V3 and persitence.xml with
changes that makes it work.
Thanks,
Mitesh
Kim Haase wrote:
> I'm sorry, I led you astray. Actually, looking more closely, it
> appears that in the persistence.xml file for order, no ddl-generation
> property is specified. I didn't notice before that the properties
> element is actually commented out:
>
> <!--properties>
> <property name="ddl-generation" value="dropandcreate"/>
> </properties-->
>
> Commenting out the properties doesn't work for the other two apps,
> though. Why it works for order is not clear to me.
>
> Kim
>
> On 11/24/09 11:23, Kim Haase wrote:
>> On 11/23/09 21:19, Mitesh Meswani wrote:
>>>
>>> Kim Haase wrote:
>>>> Hello,
>>>>
>>>> The v3 Upgrade Guide (formerly the Upgrade and Migration Guide) is
>>>> available for review at
>>>>
>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=UpgradeAndMigrationGuide
>>>>
>>>> The book has been reviewed by the Upgrade Tool engineer, but we
>>>> need help from the rest of you to identify incompatibilities
>>>> between v2 and v3 applications that users are likely to encounter.
>>>>
>>>> Particular areas of concern are application clients (about which we
>>>> say something) and persistence (about which we say nothing so far).
>>>> It appears from some experimentation that even with the
>>>> compatibility property set to v2, users still have to provide a
>>>> persistence.xml file that specifies EclipseLink instead of TopLink
>>>> in order for applications deployed on v3 to run. Is this correct?
>>> A JavaEE app that used container managed EM/EMF should work
>>> transparently with V3. What kind of app you used in your experiments
>>> and what issues are you seeing?
>>>
>>> We should definitely mention following in the guide.
>>>
>>> 1. If an app is using JavaSE style to create EMF. That is it calls
>>> Persistence.createEntityManagerFactory(...), the app will need to
>>> be change the provider name to point to EclipseLink
>>> (org.eclipse.persistence.jpa.PersistenceProvider) and rename any
>>> property supplied to "eclipselink.*" from
>>> "toplink.*"
>>> 2. If user is using any Toplink specific code in his app and hence
>>> has cast to oracle.toplink.* in his code, the code will need to
>>> change to use org.eclipse.persitence.*. Tool mentioned here
>>>
>>> <http://wiki.eclipse.org/EclipseLink/Examples/MigratingFromOracleTopLink#Rename_Packages>
>>>
>>> can help with the process. Please note that we do not ship the
>>> tool with GlassFish.
>>
>> I can mention those -- thanks. However, these situations do not apply
>> to the applications I am testing. I'm working with 3 of the Java EE 5
>> tutorial examples, ejb/order, ejb/roster, and jms/clientmdbentity.
>> You can get them from the Download link at
>> http://java.sun.com/javaee/5/docs/tutorial/doc/index.html if you
>> don't have them already. You need to follow the instructions to run
>> them -- the EJB ones are in chapter 26 (Persistence in the EJB Tier),
>> and the JMS one is in chapter 32 (Java EE Examples Using the JMS API,
>> the second section, "A Java EE Application That Uses the JMS API with
>> an Entity").
>>
>> In my experience, if these apps were previously deployed to the EE 5
>> server (I'd used glassfish-installer-v2.1-b60e-sunos.jar), ejb/order
>> runs fine after an upgrade, but the other two fail. If I put in a new
>> persistence.xml file, though, they work fine. (The compatibility=v2
>> property is set in all cases.) I think the difference is that the
>> ones that fail specify
>>
>> <property name="toplink.ddl-generation" value="drop-and-create-tables"/>
>>
>> while the persistence.xml file for the order app just has
>>
>> <property name="ddl-generation" value="dropandcreate"/>
>>
>> It is pretty common to have the toplink-specific property -- it is
>> what NetBeans automatically created, as I recall, just as it now
>> creates an EclipseLink-specific one.
>>
>> Kim
>>
>>>
>>> Thanks,
>>> Mitesh
>>>>
>>>> What other problems are possible? Please let me know by *Tuesday,
>>>> December 1, 2009.* As Dixie said, email, the comments wiki, or
>>>> phone are fine. I'm in Massachusetts, so other methods work less
>>>> well for most of you.
>>>>
>>>> Thank you very much.
>>>>
>>>> Kim Haase
>>>> x20747
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net For
>>> additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: quality-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>