Thought inc.

The Dynamic O/R Mapping Company
     

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Bug Reports
Can't find getPropObjectData method
< Previous Thread     Next Thread >
Author
Thread    Post New Thread     Post A Reply
jebrick
Member

Registered: May 2001
Posts: 6

I generated a generic CMP(2.0) and moved it into our project. when I try to compile( with jikes) I get an error

Error: No method named "getPropObjectData" was found in type "com/brick/javaatg/catd/ejb/cocobase/AtdPatient".

It comes from this line.

if(stateInstance instanceof thought.CocoBase.CBProp)
(new CocoProxyM(this)).setPropObjectData(stateInstance.getPropObjectData().getFieldValues());

Is jikes too sesitive or is there a problem here?

05-11-2001 01:26 PM
Click Here to See the Profile for jebrick    Find more posts by jebrick        Edit/Delete Message    Reply w/Quote    IP: Logged
support
Super Moderator

Registered: Apr 2001
Posts: 1

Did you double check that jikes has CocoBase classes in
your classpath, and that your AdtPatient has that method
implemented properly?

It's always possible it's jikes, but just make sure that
the class was also generated properly. Also we generate
a batch file that does a javac command. Maybe you can just
change the generated .bat file since it sets up the classpath
and necessary compilation settings. Did you try that?

THOUGHT Support

05-11-2001 01:29 PM
Click Here to See the Profile for support    Find more posts by support        Edit/Delete Message    Reply w/Quote    IP: Logged
jebrick
Member

Registered: May 2001
Posts: 6

I have the CocoBase classes in the classpath. I made a jar out of the thought.CocoBase.* classes. I added the jar to the jre/lib/ext directory.

I'm worried because I can not run javac. I have a reported and unresolved bug that causes and exception in javac. So Jikes is the only answer.

I may try to break that line down to see if I can get it to run.

05-14-2001 08:59 AM
Click Here to See the Profile for jebrick    Find more posts by jebrick        Edit/Delete Message    Reply w/Quote    IP: Logged
support
Super Moderator

Registered: Apr 2001
Posts: 1

Actually you should only need to add the CocoBase classes
directory to your classpath that you use with jikes. So
for example

set CLASSPATH=c:\thought\cocodemo3tier31\classes;%CLASSPATH%

Jikes should work better for you then.

Hope that helps!

THOUGHT Support

05-14-2001 12:03 PM
Click Here to See the Profile for support    Find more posts by support        Edit/Delete Message    Reply w/Quote    IP: Logged
jebrick
Member

Registered: May 2001
Posts: 6

I need to make the CocoBase classes visible to our Application server. This will have to be in a jar.

05-16-2001 08:09 AM
Click Here to See the Profile for jebrick    Find more posts by jebrick        Edit/Delete Message    Reply w/Quote    IP: Logged
jebrick
Member

Registered: May 2001
Posts: 6
possible bug with generated code

I think I have found the bug in your code. The code below is from the retreiveState() method from a generic CMP EntityBean. The key is the bean uses the CBDrop interface.

So with the code below it will see that the bean does not use CBProp and go to the else. Now the problem. CBDrop does not have a setPropObjectData or a getPropObjectData method.

The call might want to be to getObjectData() but the setObjectData takes a Vector which needs to be generated.

if(stateInstance instanceof thought.CocoBase.CBProp)
stateInstance.setPropObjectData((new CocoProxyM(this)).getPropObjectData().getFieldValues());
else
(new CocoProxyM(stateInstance)).setPropObjectData((new CocoProxyM(this)).getPropObjectData().getFieldValues());
return stateInstance;

05-16-2001 09:00 AM
Click Here to See the Profile for jebrick    Find more posts by jebrick        Edit/Delete Message    Reply w/Quote    IP: Logged
support
Super Moderator

Registered: Apr 2001
Posts: 1

We're confused by what you mean here. CocoBase classes can
easily be included in a jar file. In fact the mkcocodirs*.bat
and mkcocodirs*.sh scripts copy the necessary runtime and
related files for various servers. So for example the generic
runtime can be placed in a jar file with:

cd \thought\cocodemo3tier31\demos
mkcocodirs.bat
jar cfM CocoDeploy.jar thought resources/license.properties

This will create a deployable jar file with the core runtime
and support classes. If you are using a server such as the
Inprise/Borland servers or Sybase EAServer platform they have
their own batch fils that include the additional files they
need.

THOUGHT Support

05-16-2001 12:44 PM
Click Here to See the Profile for support    Find more posts by support        Edit/Delete Message    Reply w/Quote    IP: Logged
support
Super Moderator

Registered: Apr 2001
Posts: 1
possible bug with generated code

Use the CBProp instead. It's more useful and more flexible.

The CBDrop interface was an original interface that we
supported and it's mainly there for backward compatibility...

THOUGHT Support

05-16-2001 12:44 PM
Click Here to See the Profile for support    Find more posts by support        Edit/Delete Message    Reply w/Quote    IP: Logged
jebrick
Member

Registered: May 2001
Posts: 6
Your kidding!

So what you are saying is that the documents and the program give you the choice between two interfaces but only one is accually usable? I really only have the choice of using Enumerations and not Collections.

I would suggest that you either remove CBDrop from the Cocobase program choices and from the documentation or that you fix this bug. If we truely do not have a choice then please do not let us think that we do.

05-17-2001 06:08 AM
Click Here to See the Profile for jebrick    Find more posts by jebrick        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19
Your kidding!

The CBDrop interface is less flexible than CBProp which is
based on java.util.Properties and keeps a key/value pair
combination. That means it isn't positionally sensitive
and therefore can be used more flexibly.

As for the Enumerations versus collections, that doesn't
really make sense to us. The CBDrop stores values positionally
in a Vector and requires a bit more 'careful' programming by
the developer. You can certainly use it, but we don't use it
by default in ANY of our EJB related examples and none of our
EJB code templates are built for it.

You can certainly modify the templates to use CBDrop, but as
we stated before it's probably easier if you just generate
your java class as CBProp. We don't consider this a bug, we
consider it a default behavior based on our recommended
interface. We do list in the documentation that the CBProp
is the 'preferred' interface, perhaps we should be a little
more emphatic about this...

Sorry for the confusion!

THOUGHT Support

05-17-2001 10:56 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread     Next Thread >

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.