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?

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

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.

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

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

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;

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

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

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.

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