hi,

I installed Release 9 and then integrated the same to VAJ.
Now in release 8, cocovaj.bat file was present in demos
folder as well as in ides/vajava folder and i had run both
of them, in the same order, for my integration purpose. I
had gone thru the contents of both the files and they did
not contain the same stuff. But in release 9, cocovaj.bat
was not present in demos folder. I went ahead with the
integration and faced a problem. When i clicked on generate
java button in generate source code screen, pop up box
came asking me the folder where the files are to be created!!!
Please look into it as i had to rollback my entire team's
integration. Please check it out at your end.

There's a VAJ-Readme.txt in the \ides\vajava directory that
tells you how to install the latest integration. Did you
find that readme?

The cocovaj.bat in the \ides\vajava is the correct one to
run, but please read the readme, it will contain the latest
instructions for installation of the integration...

THOUGHT Support

Hi,

Thanks for the reply. I followed the readme.txt completely.
In release 8, the readme.txt was the same as this one. And
I have already integrated COcoBase with VAJ once. Please
check at your end.

You should re-run the script. It changed in SR9 even
though the steps didn't...

We also have newer version of the tools and runtime, so
if you're running with an SR8 integration, please rerun
the script...

THOUGHT Support

Hi,

Following are the steps that I have followed for CocoBase VAJava Integeration. CocoBase version is 3.1 release 8 with an upadte patch (update321.zip) sent by THOUGHT Support. Please validate the following steps:
1. Go to <drive>\thought\cocodemo3tier31\demos folder and open the file cocovaj.bat in Notepad. Change the value of VAJ_HOME to the path where Visual Age for Java is installed on the machine. You will only need to change the drive letter.
2. Run cocovaj.bat file.
3. Go to <drive>\thought\cocodemo3tier31\ides\vajava folder and change the value of VAJ_HOME to the path where Visual Age for Java is installed on the machine. You will only need to change the drive letter. Similarly change the value of COCO_HOME to the path where CocoBase is installed. Here too, only drive letter change will be required.
4. Run this cocovaj.bat
5. Open build.bat and modify VAJAVACLASS_HOME and COCO_HOME (if required) and run the file.
6. Copy the VAJCodeGen.class into <drive>\thought\cocodemo3tier31\classes\thought\CocoBase folder.
7. Copy the VAJInstaller.class into <drive>\thought\cocodemo3tier31\classes11\com\thought\VAJ folder.
8. Now in <drive>\Program Files\IBM\VisualAge for Java\ide\tools, 2 folders are visible, com-thought-CocoAdmin and com-thought-vaj.
9. In com-thought-vaj folder, open homedir.properties file in Notepad. The existing content of the file, for example, may look like: COCO_HOME=d:\thought\cocodemo3tier31. Please change the same to COCO_HOME=d:\\thought\\cocodemo3tier31. notice the change from \ to \\ at 2 places. Do the same changes in com-thought-CocoAdmin\resources\homedir.properties.
10. In com-thought-CocoAdmin\resources folder, in CocoAdmin.properties file, for Oracle, modify the default values of Oracle_Thin_COCODBURL from jdbc:oracle:thin:@localhost:1521:ORCL to jdbc:oracle:thin:@<servername>:1521:ORCL, Oracle_Thin_COCOUSERID from SCOTT to the your database username and Oracle_Thin_COCOPASSWORD from TIGER to your database user password. In Oracle.properties file in the same folder, change the SCHEMANAME from default to your database schema.
11. Start Visual Age for Java. Select Window -> Options -> Resources. Add <drive>\Oracle\Ora81\jdbc\lib\classes111.zip (or classes12.zip, if available)(for Oracle 8i client), <drive>\thought\cocodemo3tier31\classes; <drive>\thought\cocodemo3tier31\classes11; <drive>\thought\cocodemo3tier31\demos in the classpath. Also, add all the zip and JAR files in <drive>\thought\cocodemo3tier31\lib in the classpath.
12. Select Workspace -> Tools -> THOUGHT INC Cocobase Enterprise OR -> Install Cocobase runtime libraries. This should not give any errors.

When I followed above steps, my integration was working absolutely fine but when I applied the same steps for integration of SR9 of CocoBase with VAJava, I faced problems.
When tried to generate source code from CocoBase(invoked from within VAJ), after clicking on 'Generate Java' button, a window popped up asking me the directory path where to generate the source code.

Please look into this issues urgently as because of this we haven't been able to migrate to SR9.

Here are some things to look at

(steps 1 and 2)
The cocovaj.bat file in the demos directory has been moved
to run only from the ides\vajava directory. If you see a
cocovaj.bat file in the demos directory it will be from an
older release. We've started keeping these batch installer
files exclusively in the ides directories themselves.

(steps 6 and 7)
These are no longer necessary, and instead the cocovaj.bat
script in ides\vajava directory automatically copy these
files to the correct location.

(step 9)
This should no longer be necessary for Service Release 9 of
CocoBase. The installer correctly creates the homedir file
with the correct settings.

Also as for editing the resource files such as the one for
Oracle, if you edit the file in the demos\resources directory
of CocoBase, then re-running the cocovaj.bat will transfer
those changes automatically into the vajava environment.

Hope that helps!

THOUGHT Support

Hi,

All the suggestions by you have already been taken care of. But still the problem exists(as already described). What do i do now??

Feedback:
---------
Some of the steps mentioned by me, as specified by you, have already been taken care of in your SR9 but still your readme.txt in ides/vajava folder doesn't mention anything about it.

Our last suspicion is that your workspace entry is including
the CocoBase demos directory and that is somehow being seen
before the resources included in the VAJava directory. Have
you tried removing the demos directory from your VAJava
workspace to see if that resolves your issue?

You should be able to have installed the CocoBase runtime and
resource files exclusively out of the VAJava classes directory
and if all of the necessary files are placed there, you should
be able to remove the CocoBase directories from your additional
workspace classpath.

THOUGHT Support

Hi,

My VAJ resources classpath includes following files/folders:

D:\Oracle\Ora81\jdbc\lib\classes12.zip;
D:\thought\cocodemo3tier31\lib\activation.jar;
D:\thought\cocodemo3tier31\lib\javax_ejb.zip;
D:\thought\cocodemo3tier31\lib\javax_jta.zip;
D:\thought\cocodemo3tier31\lib\javax_jts.zip;
D:\thought\cocodemo3tier31\lib\javax_rmi.jar;
D:\thought\cocodemo3tier31\lib\jaxp.jar;
D:\thought\cocodemo3tier31\lib\jdbc2_0-stdext.jar;
D:\thought\cocodemo3tier31\lib\jndi.jar;
D:\thought\cocodemo3tier31\lib\jspengine.jar;
D:\thought\cocodemo3tier31\lib\jta101.jar;
D:\thought\cocodemo3tier31\lib\mail.jar;
D:\thought\cocodemo3tier31\lib\parser.jar;
D:\thought\cocodemo3tier31\lib\providerutil.jar;
D:\thought\cocodemo3tier31\lib\RmiJdbc.jar;
D:\thought\cocodemo3tier31\lib\rmiregistry.jar;
D:\thought\cocodemo3tier31\lib\servlet.jar;
D:\thought\cocodemo3tier31\lib\swingall.jar;
D:\thought\cocodemo3tier31\lib\webserver.jar;
D:\thought\cocodemo3tier31\lib\xml.jar;

Do I need to remove/add anything here?

"Our last suspicion is that your workspace entry is including the CocoBase demos directory and that is somehow being seen before the resources included in the VAJava directory."
I didn't get what do u mean by workspace entry? Do u mean workspace classpath?
Later I removed following paths from the classpaths:
D:\thought\cocodemo3tier31\classes\;
D:\thought\cocodemo3tier31\classes11\;
D:\thought\cocodemo3tier31\demos\;
But that didn't help...
Also when the pop up window comes, it points to com-thought-Cocoadmin folder. See whether it is useful.

"You should be able to have installed the CocoBase runtime and resource files exclusively out of the VAJava classes directory and if all of the necessary files are placed there, you should be able to remove the CocoBase directories from your additional workspace classpath. "
Can you be more clearer on this part? Didn't really get what you mean here.

Can you look under the com-thought-CocoAdmin folder of VAJava
and make sure that the CocoGenBundle.properties has a property
value of:
GENERATEFILTER = thought.CocoBase.VAJCodeGen

It should also have
REQUESTBASENAME = false

These two values govern this popup, and somehow they are
different than they should be. If this file is valid then
the only thing we can guess is if the classpath is pointing
to the version of this file in the demos\resources directory
of the CocoBase distribution. If this is true you can test
this by saving a copy of the CocoGenBundle.properties in the
demos\resources directory and copying the VAJava version of
this file over that filename and restarting VAJava. If the
VAJava works after this change, then it means that either
your workspace or system classpath is somehow finding the
CocoBase demos directory when it shouldn't be.

The source of the CocoGenBundle.properties for VAJava is found
under a slightly different name in the \ides\vajava directory
of the CocoBase distribution.

Hope this answers your question.

THOUGHT Support

Hi,

Thanks for the response.
When i integerated SR8 + update patch with VAJ, i found that in com-thought-CocoAdmin\resources folder there are 3 files CocoGenBundle-VAJAVA.properties, CocoGenBundle.properties and CocoGenBundle_VAJAVA.properties. Same 3 files were present in demos\resources folder.
And here are the contents of the 3 files:

CocoGenBundle-VAJAVA.properties
-------------------------------
UseJavaNaming = true
NameSeparator = _
GenODBMS = false
debug = false
overwrite = false
defaultDirectory = .
GENERATEFILTER = thought.CocoBase.VAJCodeGen
GENERATEPROPERTIES = USEPKGPREFIX,USEPKGDIR,AUTOCOMPILE
USEPKGPREFIX = false
USEPKGDIR = false
AUTOCOMPILE = false
REQUESTBASENAME = false

CocoGenBundle.properties
------------------------
UseJavaNaming = true
NameSeparator = _
GenODBMS = false
debug = false
overwrite = false
defaultDirectory = .
GENERATEFILTER = thought.CocoBase.VAJCodeGen
GENERATEPROPERTIES = USEPKGPREFIX,USEPKGDIR,AUTOCOMPILE
USEPKGPREFIX = false
USEPKGDIR = false
AUTOCOMPILE = false
REQUESTBASENAME = false

CocoGenBundle_VAJAVA.properties
-------------------------------
UseJavaNaming = true
NameSeparator = _
GenODBMS = false
debug = false
overwrite = false
defaultDirectory = .
GENERATEFILTER = thought.CocoBase.CompileCodeGen
GENERATEPROPERTIES = USEPKGPREFIX,USEPKGDIR,AUTOCOMPILE
USEPKGPREFIX = true
USEPKGDIR = false
AUTOCOMPILE = true
REQUESTBASENAME = false

I didn't make any changes in the above files and my integration is working perfectly.

When I integrated SR9 with VAJ, i only found CocoGenBundle.properties in com-thought-CocoAdmin\resources folder and in demos\resouces folder. And here are the contents of the same:

UseJavaNaming = true
NameSeparator = _
GenODBMS = false
debug = false
overwrite = false
defaultDirectory = .
GENERATEFILTER = thought.CocoBase.CompileCodeGen
GENERATEPROPERTIES = USEPKGPREFIX,USEPKGDIR,AUTOCOMPILE
USEPKGPREFIX = true
USEPKGDIR = false
AUTOCOMPILE = false
REQUESTBASENAME = true

You are asking me to change the GENERATEFILTER value which is same in SR8 and Sr9. Do I really have to change it?
If so then how is the same thing working in SR8? Also, this adds another item in my integration steps that after integration, change the parameter values. So please confirm this.

That appears to be the source of your issue. We'll look at
the installer to find out why but your CocoGenBundle.properties
in the VAJava com-thought-CocoAdmin\resources should contain:

UseJavaNaming = true
NameSeparator = _
GenODBMS = false
debug = false
overwrite = false
defaultDirectory = .
GENERATEFILTER = thought.CocoBase.VAJCodeGen
GENERATEPROPERTIES = USEPKGPREFIX,USEPKGDIR,AUTOCOMPILE
USEPKGPREFIX = false
USEPKGDIR = false
AUTOCOMPILE = false
REQUESTBASENAME = false


If you set it to contain these values instead of the default
values your integration will work properly. On the surface
it looks like we didn't properly copy the CocoGenBundle-VAJava
from our integration directory over the CocoGenBundle file,
and that's why you were getting this strange behavior. We'll
have a look at our installation scripts to see how this might
have happened.

This should resolve your issue for you - and thanks for your
help in identifying this!

THOUGHT Support