Java Open Client 11.2

this is the actual error... and it happens when creating a new ProDataGraph using a prepared metadata

java.lang.NoClassDefFoundError: Could not initialize class org.apache.tuscany.sdo.api.SDOUtil

     at com.progress.open4gl.ProDataGraph.(ProDataGraph.java:99)

just in case someone else go that route before they get to update the documentation...

what need to be deployed as part of open client seems now to be this

dlc/java

     - o4glrt.jar

     
     /ext
     - common-2.2.3.jar 
     - ecore-2.2.3.jar 
     - ecore-xmi-2.2.3.jar 
     - tuscany-sdo-api-r2.1-1.1.1.jar 
     - tuscany-sdo-impl-1.1.1.jar 
     - tuscany-sdo-lib-1.1.1
     - xsd-2.2.3

I had the same type of error, trying to return a DataSet from the AppServer.  I included the extra Progress .jar files your mentioned (and also added tuscany-sdo-tools-1.1.1.jar) - thanks for that!

Did adding these .jars solve your problem?

I still get an Open4GLException when calling the Procedure Object that is supposed to return the DataSet as a ProDataGraphHolder:

java.lang.NoClassDefFoundError: org/apache/tuscany/sdo/api/SDOUtil

I did find org.apache.tuscany.sdo.api.SDOUtil in tuscany-sdo-lib-1.1.1.jar.  So, if I added them to the classpath (and runtime path) correctly, it should work?

Nickols wrote:
I had the same type of error, trying to return a DataSet from the AppServer.  I included the extra Progress .jar files your mentioned (and also added tuscany-sdo-tools-1.1.1.jar) - thanks for that!

Thing is those are the only jar's you need to include... if still having the ones mentioned in the doc in the classpath it might not to work... depending on the order of the jar's in classpath, although classloader in java can be more complicated than that

With some help from my collegue Kenneth, we managed to solve my problem!

When I included the extra JARs from the OpenEdge installation folders, I had them in the wrong order in the Java Classpath.  Being a OpenEdge developer and not seasoned with Java this very important aspect was lost to me.

I adjusted the Java Build Path (in my eclipse plugin project) to the following (in the correct order):

o4glrt.jar
common-2.2.3.jar
ecore-2.2.3.jar
ecore-xmi-2.2.3.jar
tuscany-sdo-api-r2.1-1.1.1.jar
tuscany-sdo-impl-1.1.1.jar
tuscany-sdo-lib-1.1.1.jar
xsd-2.2.3.jar
tuscany-sdo-tools-1.1.1.jar
ecore.change.jar

Now I just have to figure out how the Java Build Path relates to a plugin's bin.includes in the build.properties file and also the Bundle-ClassPath in the MANIFEST.MF file.

Hi,

I seem to be having a similar issue on OpenEdge 11.3.

I have an open client that worked fine on OpenEdge 11.1, but after upgrading to 11.3 I can't get it to work anymore.

After regenerating with the proxy generator, and deploying the jars mentioned in your reply I still get the following error:

NativeException: java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/xmi/XMLOptions

org/apache/tuscany/sdo/impl/FactoryBase.java:366:in `<clinit>'

org/apache/tuscany/sdo/model/ModelFactory.java:41:in `<clinit>'

org/apache/tuscany/sdo/helper/TypeHelperImpl.java:62:in `getBuiltInModels'

org/apache/tuscany/sdo/helper/TypeHelperImpl.java:80:in `<init>'

org/apache/tuscany/sdo/helper/HelperContextImpl.java:65:in `<init>'

org/apache/tuscany/sdo/helper/DefaultHelperContextImpl.java:31:in `<init>'

org/apache/tuscany/sdo/helper/HelperProviderImpl.java:37:in `createDefaultHelpers'

org/apache/tuscany/sdo/spi/HelperProviderBase.java:82:in `<init>'

org/apache/tuscany/sdo/helper/HelperProviderImpl.java:30:in `<init>'

sun.reflect.NativeConstructorAccessorImpl:-2:in `newInstance0'

sun.reflect.NativeConstructorAccessorImpl:-1:in `newInstance'

sun.reflect.DelegatingConstructorAccessorImpl:-1:in `newInstance'

java.lang.reflect.Constructor:-1:in `newInstance'

java.lang.Class:-1:in `newInstance'

commonj/sdo/impl/HelperProvider.java:166:in `loadImplementation'

commonj/sdo/impl/HelperProvider.java:135:in `getInstance'

commonj/sdo/impl/HelperProvider.java:69:in `<clinit>'

org/apache/tuscany/sdo/api/SDOUtil.java:48:in `<clinit>'

com/progress/open4gl/ProDataGraph.java:141:in `<init>'

ProxyBridge.java:83:in `retrieveSingleObject'

E:/Workspace/AppserverDataFetcher/lib/appServer.rb:65:in `getAllFieldsForRecord'

./spec/appserver_spec.rb:27:in `(root)'

I'm running some rspec tests over jruby, hence the last two lines...

Any hints on what the problem could be?

This XMLOptions class is included in the ecore-xmi-2.2.3.jar file. Is your 11.3 classpath the same as in 11.1?

Using 11.3,  i am also getting similar issue with the stack as,

Thread [Thread-0] (Suspended (exception ExceptionInInitializerError)) 

                Unsafe.throwException(Throwable) line: not available [native method] [local variables unavailable]       

                Class<T>.newInstance0() line: 357          

                Class<T>.newInstance() line: 308             

                HelperProvider.loadImplementation(ClassLoader, String) line: 166          

                HelperProvider.getInstance(ClassLoader) line: 135          

                HelperProvider.<clinit>() line: 69             

                SDOUtil.<clinit>() line: 48             

                ProDataGraph.<init>(ProDataGraphMetaData) line: 141               

                damip.exec_oe_proc(StmtInfo) line: 1275          

                damip.build_result_rows(StmtInfo, int) line: 1393           

                damip.ipExecute(long, int, long, xo_int) line: 404             

Do we have any suggestion to fix this in OE 11.3 environment?

Thanks,
Nagaraju

With help from my collegue Devesh, I am able to resolve the below issue in my integrated environment.

"Could not initialize class org.apache.tuscany.sdo.api.SDOUtil "

For this, I have changed code as,

try

{

      ClassLoader cl = Thread.currentThread().getContextClassLoader();

      if (cl == null)

      {

             ClassLoader currentClassesLoader = getClass().getClassLoader();

             Thread.currentThread().setContextClassLoader(currentClassesLoader);

      }

      newDG= new ProDataGraph(pStmtDA.mDataGraphMetaData);                              

}

catch (Throwable t)

{                                

      jdam.trace(m_tmHandle, UL_TM_ERRORS, "exec_oe_proc() failed. Throwable :" + t.getMessage() + "\n");

      jdam.dam_addError(0, pStmtDA.dam_hstmt, DAM_IP_ERROR, 0, t.getMessage() );

      throw new Exception(t.getMessage());                                

}

The problem resolved after setting the currentThread's class loader.

Well, while it did worked at some point in 11.2 the fun is back on 11.3 upgrade... that open client thingy used to work flawlessly but lately it's like you guys got a special person in that works hard to trash it to the toilet :(

Input result set error:  com.progress.open4gl.Open4GLException: java.util.Vector cannot be cast to java.util.GregorianCalendar (7176)

Get this on some cases where a dataset is returned, first though it's because of a date/datetime field defined in the dataset but in other cases it works just fine returning datasets with date/datetime fields so it must be something special.

I even regenerated the proxy classes (which can now only be done with java 1.7 which leads me to change the minimum version to 1.7 and recompile the whole app) but same result :(

Found a mention of the error number in this release note - knowledgebase.progress.com/.../000046467 but somehow it's not the same error, anyone else experiencing this or have managed to get java open client to work in 11.3?

Thanks Brian,

will do that today, let's see if I can isolate that in a small test case.

Regards,
Marian

On 05/28/2014 09:59 PM, Brian K. Maher wrote:
>[collapse] From: Brian K. Maher
> Post: RE: Java Open Client 11.2
> Posted in: OpenEdge General
> Link: http://community.progress.com/technicalusers/f/26/p/7432/39306.aspx#39306
>
> Marian,
>
>
>
> Please open a support case with Tech Support. We need to do
> more analysis than can be done here.
>
>
>
> Thanks, Brian Maher
>
>
> --
> You were sent this email because you opted to receive email notifications when someone created a new thread.
>
> To unsubscribe[collapse] from:
> - ...only this thread, disable notifications at http://community.progress.com/technicalusers/f/26/p/7432/39306.aspx#39306.
> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>
>


--
m.edu
keep it simple
http://www.ganimede.ro
http://ro.linkedin.com/in/marianedu
medu@ganimede.ro
mobile: +40 740 036 212
skype: marian.edu[/collapse][/collapse]

OK, have found the issue and now the I think of it the message does
seems obvious :)

The issue is with extent fields, in that case it happens to be a date
therefore the exception on cast from a vector (extent) to gregoriancalendar.

If I empty the temp-table the rest of the dataset gets through but the
result set only contains one field of type Date, when data comes it
comes probably as a list of dates.

Now, as far as I know the default access model is 'flat', meaning for
each extent field there will be a number of columns in the result set
equals to the field extent... using getColumn methods will use this
access more but it doesn't seems to be true. First if no data is sent in
that temp-table I was still expecting to get more columns for that
extent field but there is only one. When data is there it looks like
it's using the array model while methods getColumn*** is said it should
use the flat one.

I do expose everything as a standard JDBC and have wrappers for
ProResultset/MetaData but no 'array access model' method is being used
there and it doesn't even get to the point where the result set is
returned to Java, the exception is being thrown when the method is being
called on the generated proxy.



[collapse]On 05/29/2014 08:18 AM, Marian Edu wrote:
>[collapse] From: Marian Edu
> Post: Re: Java Open Client 11.2
> Posted in: OpenEdge General
> Link: http://community.progress.com/technicalusers/f/26/p/7432/39318.aspx#39318
>
> Thanks Brian,
>
> will do that today, let's see if I can isolate that in a small test case.
>
> Regards,
> Marian
>
> On 05/28/2014 09:59 PM, Brian K. Maher wrote:
>>[collapse] From: Brian K. Maher
>> Post: RE: Java Open Client 11.2
>> Posted in: OpenEdge General
>> Link: http://community.progress.com/technicalusers/f/26/p/7432/39306.aspx#39306
>>
>> Marian,
>>
>>
>>
>> Please open a support case with Tech Support.We need to do
>> more analysis than can be done here.
>>
>>
>>
>> Thanks, Brian Maher
>>
>>
>> --
>> You were sent this email because you opted to receive email notifications when someone created a new thread.
>>
>> To unsubscribe[collapse] from:
>> - ...only this thread, disable notifications at http://community.progress.com/technicalusers/f/26/p/7432/39306.aspx#39306.
>> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>>
>>
>


--
m.edu
keep it simple
http://www.ganimede.ro
http://ro.linkedin.com/in/marianedu
medu@ganimede.ro
mobile: +40 740 036 212
skype: marian.edu[/collapse][/collapse][/collapse][/collapse]

I had previously entered doc issue PSC00287684 (back in January) that the Java Open Client doc was not updated with the new SDO  jar files.

Also, Brian is correct in asking that you enter a bug for this particular issue and we will look into then.

if anyone else stumble upon the same issue TS released a hotfix that can take the pain away... thanks guys.