Topic
  • 13 replies
  • Latest Post - ‏2010-12-02T21:17:01Z by MANT
MANT
MANT
10 Posts

Pinned topic IBM WAS 7.0.0.13 + JPA 2.0 FP

‏2010-12-01T20:01:29Z |
we are trying to use the JPA 2.0 feature pack with the fix pack 13, the augmentation for feature pack is successful but we are getting below error...

**
Updated on 2010-12-02T21:17:01Z at 2010-12-02T21:17:01Z by MANT
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-01T20:04:17Z  
    Forgot to put the exception -

    [org.xml.sax.SAXParseException: cvc-complex-type.3.1: Value '2.0' of attribute 'version' of element 'persistence' is not valid with respect to the correspond
    ing attribute use. Attribute 'version' has a fixed value of '1.0'.]
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-01T20:25:54Z  
    • MANT
    • ‏2010-12-01T20:04:17Z
    Forgot to put the exception -

    [org.xml.sax.SAXParseException: cvc-complex-type.3.1: Value '2.0' of attribute 'version' of element 'persistence' is not valid with respect to the correspond
    ing attribute use. Attribute 'version' has a fixed value of '1.0'.]
    Hi MANT,
    Your posting indicated that you performed the augmentation for the feature pack. Augmentation is done on a per profile basis. If the application is question is running in an unaugmented profile, then you will see the message logged as you have posted.

    Here's what I think is happening... The persistence.xml that you are attempting to use has a version field of 2.0. But, the jpa runtime that is being used is still at the JPA 1.0 specification level. This older version of the jpa runtime only knew about the 1.0 spec level. Thus, when the persistence.xml file is parsed, and we come across the 2.0 level, it doesn't match the schema definition (xsd) for the 1.0 spec level, and the error message is logged.

    One thing to check is whether the profile you are using has the updated JPA runtime by executing the wsjpaversion command from that profile's bin directory. You should see versions that correspond to openjpa and wsjpa 2.0.x versions. Something like this:

    > .../profiles/<your profile>/bin/wsjpaversion.sh
    WSJPA 2.0.1-SNAPSHOT
    version id: WSJPA-2.0.1-SNAPSHOT-r1118:2100
    WebSphere JPA svn revision: 1118:2100

    OpenJPA 2.0.1-SNAPSHOT
    version id: openjpa-2.0.1-SNAPSHOT-r422266:980199
    Apache svn revision: 422266:980199
    :

    If you are not seeing the 2.0.x versions, then the profile has not been properly augmented. If you think you have performed the augmentation, then you should probably open a problem report (PMR) with IBM.

    If you have performed the augmentation, and you are seeing the 2.0.x versions with the wsjpaversion command, and you still see the error message you posted, then I'm stumped and you probably need to open a problem report (PMR) with IBM... :-)

    Hope this helps with deciphering the problem.

    Kevin
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-01T20:42:10Z  
    • sutter
    • ‏2010-12-01T20:25:54Z
    Hi MANT,
    Your posting indicated that you performed the augmentation for the feature pack. Augmentation is done on a per profile basis. If the application is question is running in an unaugmented profile, then you will see the message logged as you have posted.

    Here's what I think is happening... The persistence.xml that you are attempting to use has a version field of 2.0. But, the jpa runtime that is being used is still at the JPA 1.0 specification level. This older version of the jpa runtime only knew about the 1.0 spec level. Thus, when the persistence.xml file is parsed, and we come across the 2.0 level, it doesn't match the schema definition (xsd) for the 1.0 spec level, and the error message is logged.

    One thing to check is whether the profile you are using has the updated JPA runtime by executing the wsjpaversion command from that profile's bin directory. You should see versions that correspond to openjpa and wsjpa 2.0.x versions. Something like this:

    > .../profiles/<your profile>/bin/wsjpaversion.sh
    WSJPA 2.0.1-SNAPSHOT
    version id: WSJPA-2.0.1-SNAPSHOT-r1118:2100
    WebSphere JPA svn revision: 1118:2100

    OpenJPA 2.0.1-SNAPSHOT
    version id: openjpa-2.0.1-SNAPSHOT-r422266:980199
    Apache svn revision: 422266:980199
    :

    If you are not seeing the 2.0.x versions, then the profile has not been properly augmented. If you think you have performed the augmentation, then you should probably open a problem report (PMR) with IBM.

    If you have performed the augmentation, and you are seeing the 2.0.x versions with the wsjpaversion command, and you still see the error message you posted, then I'm stumped and you probably need to open a problem report (PMR) with IBM... :-)

    Hope this helps with deciphering the problem.

    Kevin
    Hi Kevin,
    Yes, we have done the augmentation successfully on the application profile and the deployment manager. we got below messages when we ran the augmentation -

    bash-3.00$ ./manageprofiles.sh -augment -profileName Dmgr01 -templatePath /opt/soft/was70/profileTemplates/JPA/cell.jpafep/dmgr
    INSTCONFSUCCESS: Profile augmentation succeeded.

    bash-3.00$ ./manageprofiles.sh -augment -profileName AppSrv01 -templatePath /opt/soft/was70/profileTemplates/JPA/cell.jpafep/default
    INSTCONFSUCCESS: Profile augmentation succeeded.

    and when I run the wsjpaversion i am getting below -
    bash-3.00$ ./wsjpaversion.sh
    WSJPA 2.0.1-SNAPSHOT
    version id: WSJPA-2.0.1-SNAPSHOT-r1118:2100
    WebSphere JPA svn revision: 1118:2100

    OpenJPA 2.0.1-SNAPSHOT
    version id: openjpa-2.0.1-SNAPSHOT-r422266:980199
    Apache svn revision: 422266:980199
    os.name: SunOS
    os.version: 5.10
    os.arch: sparc
    java.version: 1.6.0_20-rev
    java.vendor: Sun Microsystems Inc.
    java.class.path:
    /opt/soft/was70/feature_packs/jpa/dev/jpa_api.jar
    /opt/soft/was70/dev/JavaEE/j2ee.jar
    /opt/soft/was70/feature_packs/jpa/plugins/com.ibm.ws.jpa.jar
    /opt/soft/was70/plugins/com.ibm.ws.prereq.commons-collections.jar
    ---
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-01T21:58:43Z  
    • MANT
    • ‏2010-12-01T20:42:10Z
    Hi Kevin,
    Yes, we have done the augmentation successfully on the application profile and the deployment manager. we got below messages when we ran the augmentation -

    bash-3.00$ ./manageprofiles.sh -augment -profileName Dmgr01 -templatePath /opt/soft/was70/profileTemplates/JPA/cell.jpafep/dmgr
    INSTCONFSUCCESS: Profile augmentation succeeded.

    bash-3.00$ ./manageprofiles.sh -augment -profileName AppSrv01 -templatePath /opt/soft/was70/profileTemplates/JPA/cell.jpafep/default
    INSTCONFSUCCESS: Profile augmentation succeeded.

    and when I run the wsjpaversion i am getting below -
    bash-3.00$ ./wsjpaversion.sh
    WSJPA 2.0.1-SNAPSHOT
    version id: WSJPA-2.0.1-SNAPSHOT-r1118:2100
    WebSphere JPA svn revision: 1118:2100

    OpenJPA 2.0.1-SNAPSHOT
    version id: openjpa-2.0.1-SNAPSHOT-r422266:980199
    Apache svn revision: 422266:980199
    os.name: SunOS
    os.version: 5.10
    os.arch: sparc
    java.version: 1.6.0_20-rev
    java.vendor: Sun Microsystems Inc.
    java.class.path:
    /opt/soft/was70/feature_packs/jpa/dev/jpa_api.jar
    /opt/soft/was70/dev/JavaEE/j2ee.jar
    /opt/soft/was70/feature_packs/jpa/plugins/com.ibm.ws.jpa.jar
    /opt/soft/was70/plugins/com.ibm.ws.prereq.commons-collections.jar
    ---
    Kevin,

    I have a question, we are using the openjpa-all-2.0.0.jar for PCEnhancer at the build time, now that is not an IBM jar file but it is an Apache jar file, so our build is with it and when we are deploying the application on the WAS 7.0.0.13, we are using the IBM implementation of the JPA, do you think that would be an issue?
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-01T23:13:07Z  
    • MANT
    • ‏2010-12-01T21:58:43Z
    Kevin,

    I have a question, we are using the openjpa-all-2.0.0.jar for PCEnhancer at the build time, now that is not an IBM jar file but it is an Apache jar file, so our build is with it and when we are deploying the application on the WAS 7.0.0.13, we are using the IBM implementation of the JPA, do you think that would be an issue?
    Hi MANT,
    Hmmm... Your profile augmentation looks good. The wsjpaversion output looks good. But, somehow it seems that the persistence.xml file is still being validated against the JPA 1.0 xsd...

    Doing the build time enhancement with the openjpa-2.0.0-all.jar should not be causing a problem. The WebSphere JPA solution is using the OpenJPA binaries directly without modification, so it should be the same as running with the WebSphere JPA jar. Also, the enhancement processing should have nothing to do with the version field of the persistence.xml.

    I suppose as a quick test you could pull the jpa client jar from the runtimes directory (in a jpa 2.0 profile) and use that in your build environment. Or, you could pull the corresponding openjpa-2.0.1-snapshot jar file that matches up with the websphere version. I really don't think this will make a difference though.

    Could you post your persistence.xml and the complete call stack from the exception you are receiving? Maybe we can match up line numbers from the call stack to see what's going on. I have also posted this question to a few fellow developers to see what ideas they come up with.

    Thanks for your patience. This is probably going to turn out to be a very simple scenario, but right now I don't see the culprit...

    Thanks,
    Kevin
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T17:51:32Z  
    • sutter
    • ‏2010-12-01T23:13:07Z
    Hi MANT,
    Hmmm... Your profile augmentation looks good. The wsjpaversion output looks good. But, somehow it seems that the persistence.xml file is still being validated against the JPA 1.0 xsd...

    Doing the build time enhancement with the openjpa-2.0.0-all.jar should not be causing a problem. The WebSphere JPA solution is using the OpenJPA binaries directly without modification, so it should be the same as running with the WebSphere JPA jar. Also, the enhancement processing should have nothing to do with the version field of the persistence.xml.

    I suppose as a quick test you could pull the jpa client jar from the runtimes directory (in a jpa 2.0 profile) and use that in your build environment. Or, you could pull the corresponding openjpa-2.0.1-snapshot jar file that matches up with the websphere version. I really don't think this will make a difference though.

    Could you post your persistence.xml and the complete call stack from the exception you are receiving? Maybe we can match up line numbers from the call stack to see what's going on. I have also posted this question to a few fellow developers to see what ideas they come up with.

    Thanks for your patience. This is probably going to turn out to be a very simple scenario, but right now I don't see the culprit...

    Thanks,
    Kevin
    Kevin,

    We were able to address this issue, we found that the server class path had a old jar file and our classloading is parent last, so it was conflicting with the websphere one. Thanks anyways for your interest in the question and help.

    So we are using openjpa-2.0.0-all.jar for compilation for PCEnhancer and it is working well with the IBM jars during runtime..

    our main aim was to use the below tuning parameters that we are trying to test to improve the performance.

    Currently we are at 60% CPU without these parameters. Do you think it should help?
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T17:57:15Z  
    • MANT
    • ‏2010-12-02T17:51:32Z
    Kevin,

    We were able to address this issue, we found that the server class path had a old jar file and our classloading is parent last, so it was conflicting with the websphere one. Thanks anyways for your interest in the question and help.

    So we are using openjpa-2.0.0-all.jar for compilation for PCEnhancer and it is working well with the IBM jars during runtime..

    our main aim was to use the below tuning parameters that we are trying to test to improve the performance.

    Currently we are at 60% CPU without these parameters. Do you think it should help?
    property name="openjpa.QueryCache" value="false"
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T17:58:03Z  
    • MANT
    • ‏2010-12-02T17:57:15Z
    property name="openjpa.QueryCache" value="false"
    property name="openjpa.BrokerImpl" value="SuppressBatchOLELogging=true"
    property name="openjpa.DetachState" value="LiteAutoDetach=true"
    property name="wsjpa.ObjectCache" value="true(Types=xyz, MaxSize=10000, EvictionSchedule='+720')
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T19:35:07Z  
    • MANT
    • ‏2010-12-02T17:51:32Z
    Kevin,

    We were able to address this issue, we found that the server class path had a old jar file and our classloading is parent last, so it was conflicting with the websphere one. Thanks anyways for your interest in the question and help.

    So we are using openjpa-2.0.0-all.jar for compilation for PCEnhancer and it is working well with the IBM jars during runtime..

    our main aim was to use the below tuning parameters that we are trying to test to improve the performance.

    Currently we are at 60% CPU without these parameters. Do you think it should help?
    > Kevin,
    >
    > We were able to address this issue, we found that the server class path had a old jar file and our classloading is parent last, so it was conflicting with the websphere one. Thanks anyways for your interest in the question and help.

    Perfect. This was one of the ideas that we had come up with overnight as well. I'm glad that it turned out to be an easy fix.

    >
    > So we are using openjpa-2.0.0-all.jar for compilation for PCEnhancer and it is working well with the IBM jars during runtime.

    Good.

    >
    > our main aim was to use the below tuning parameters that we are trying to test to improve the performance.
    >
    > Currently we are at 60% CPU without these parameters. Do you think it should help?

    Depends on the application. I'll post more specific comments in your follow-on posts.

    Glad you got things running,
    Kevin
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T19:38:32Z  
    • MANT
    • ‏2010-12-02T17:57:15Z
    property name="openjpa.QueryCache" value="false"
    > property name="openjpa.QueryCache" value="false"

    The QueryCache is turned off by default now in the OpenJPA 2.x releases. In the past, the QueryCache was turned on automatically if the DataCache was enabled. The maintenance of this QueryCache turned out to be a performance hit if the application didn't execute similar queries over and over again. So, we decided to separate the enablement of these two caches so that the configuration could be more specific to the application.
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T19:55:40Z  
    • MANT
    • ‏2010-12-02T17:58:03Z
    property name="openjpa.BrokerImpl" value="SuppressBatchOLELogging=true"
    property name="openjpa.DetachState" value="LiteAutoDetach=true"
    property name="wsjpa.ObjectCache" value="true(Types=xyz, MaxSize=10000, EvictionSchedule='+720')
    > property name="openjpa.BrokerImpl" value="SuppressBatchOLELogging=true"
    This property may help with some performance concerns due to excessive logging of the OLE messages. But, this really depends on the application. If the application is not setup to process OLE's (ie. take recovery action), the logging these messages may help with debugging the application logic. But, if the application is setup to process OLE's, then this logging may be just excessive and causing some performance concerns.

    > property name="openjpa.DetachState" value="LiteAutoDetach=true"
    This property may provide some relief for you, again depending on your application. By default, OpenJPA's processing was optimized for re-attachment of Entities. That is, when an Entity was detached from a Persistence Context, OpenJPA would enable mechanisms within the Entity to continue to monitor the state. Thus, when the Entity was re-attached to another Persistence Context, we would have immediate knowledge of what had changed. But, there are many applications that will never re-use the Entities after they have been detached. So, why go through the overhead of setting up for this state monitoring, if it's just going to be thrown away. That's what this LiteAutoDetach provides.

    Another setting that may be of interest to you is the "openjpa.DetachState (DetachedStateField=false)". Similar type of idea, but not quite as "drastic" as the LiteAutoDetach. One of these may apply to your situation.

    > property name="wsjpa.ObjectCache" value="true(Types=xyz, MaxSize=10000, EvictionSchedule='+720')
    Definitely, if your application is using read-only entities, then the use of this read-only object cache can greatly improve your performance. Since you know about this configuration, you have probably already referenced the documentation [1]. But, there are some caveats with the use of this ObjectCache. Again, it's not for everybody. But, if your application fits within the parameters of usage, it's great for performance.

    [1] http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/com.ibm.websphere.jpafep.multiplatform.doc/info/ae/ae/tejb_jpaobjectcache.html

    One other property I would point you at is the "openjpa.MetaDataRepository (Preload=true)" property. If your persistence.xml file specifies all of the <class> files that your PU/PC will utilize, then we can load all of the necessary meta data up front and remove the locking that occurs in a more dynamic environment. This helped considerably with scalability on multi-core systems. Most applications can benefit for this change just by ensuring that the classes are all specified in the persistence.xml.

    Hope this helps,
    Kevin
  • sutter
    sutter
    94 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T19:56:40Z  
    The user discovered an errant jar file with the "older" JPA artifacts that were affecting the use of the new JPA 2.0 runtime.
  • MANT
    MANT
    10 Posts

    Re: IBM WAS 7.0.0.13 + JPA 2.0 FP

    ‏2010-12-02T21:17:01Z  
    I am fine with this question as there was a old OpenJpa jar in the class path which was conflicting with the websphere one and the classloading that we are using is parent last. so removed the jar and worked fine.