I just loaded IS(6.5.1) & Developer on my laptop (xp pro) and tried creating a java service. This is what I got before I added any code.
Couldn’t compile
com.wm.app.b2b.server.ServiceException: [ISS.0026.9104] Missing class develop
When I go to the packages\develop\code\classes folder, I see a develop.class file.
The jvm paths appear to be setup okay, and the built-in java services work.
What am I missing?
Thanks
What is the package name in which you are attempting to create your java service? What is the folder/subfolder and service name where you are creating this service?
Is this your first attempt to create a java service? If so, you should consider completing the Developer 4.6 Tutorial avialalbe on Advantage (search wMUsers for a link to this document).
Mark
I’ve been developing java services on a unix server. I now have a need to do it on my laptop.
The package name is develop, the folder is called develop and the service name is called empList.
I will check the tutorial, hopefully it covers configuration issues.
The tutorial does not cover configuration issues.
Java service development is idential on Windows vs. UNIX servers except for obvious OS-specific things like pathnames.
If you started developing your empList service in another folder and then renamed or moved it, you might be confusing things.
You might also want to follow a more standard naming convention for folders. It is not a best practice to put flows, java services, adapter services, doc type defns, etc. into one top level folder.
I usually make a folder for each type of IS compenent under some reasonably clear folder/subfolder structure that identifies the functional domain of the package.
PackageName: = AcmeCoHR
Folder Structure:
acmeco
|–hr
|–employees
|— adapterServices (for JDBC, JMS, etc.)
|— adapterNotifications (for JDBC, JMS, etc.)
|— docs (document type definitions specific to this package)
|— flows (Flow services)
|— java (Java services)
|— triggers (IS triggers)
|— etc.
I’m sure others have their preferred method of naming folders. The main thing is to pick a logical structure, document it and follow it consistently.
One downside of my approach is that the source file that gets created from java services get called “java.java” which is a bit goofy. I supposed one could add addiitonal sub-folders under the “java” sub-folder to fix this side effect.
Mark
A search on Advantage for ISS.0026.9104 turned up this KB article:
[URL=“https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1612216262”]https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1612216262[/URL]
Based on this, the watt.server.compile property is either not set or is wrong.
Nice folder structure Mark. I’d like to weigh in on folder names. IMO, one should avoid naming a folder Java (or any capitalization variation). Why? Because the folder name is part of the namespace and using those names expose implementation details–which are none of the caller’s dadburned business. 
It shouldn’t matter that a service is implemented in Java. If you find that you could get a speed boost by rewriting a FLOW service in Java, then you’ll need to move the service to follow the naming scheme. Changing the namespace of a service, especially after it has been deployed and used by others, can be painful.
I usually also object (mildly) to using FLOW as a folder name. Again, what value does using that name add? Other, more descriptive names would be more helpful, both in anticipating what sort of services the folder contains (a design-time benefit) and again in not exposing implementation details to callers, especially external entities. Calling a folder “main” would be preferable, IMO, to using “flow.”
Of course, that’s just my opinion. I’m often wrong. 
Following Rob’s suggestion, the folder structure I proposed above would look like this:
PackageName: = AcmeCoHR
Folder Structure:
acmeco
|–hr
|–employees
|— adapterServices (for JDBC, JMS, etc.)
|— adapterNotifications (for JDBC, JMS, etc.)
|— docs (document type definitions specific to this package)
|— main (Flow and / or java services)
|— triggers (IS triggers)
|— etc.
I know that the discussion has diverted from the original question, but just to add on to the best practices as far as maintaining a clean and descriptive folder structure is concerned - I agree with the latest folder structure - I use similar approach too, however, there is one more thing that I like to do. I name my top level folder the same name as the package - so that when I see an error in the logs, I don’t have to search for the service.
In the example folder structure above by Mark, I agree - one could easily tell the package in which the service resides by looking at the complete name of the service, however, in a lot of cases this may not be possible, for instance, we implement a lot of RosettaNet PIPs and the packages are named after the PIPs
AcmePIP3A4
|–AcmePIP3A4
|----AcmePIP3A4v02_00
|------ Maps
|------ Records
|------ Connections
|------ Etc. etc. etc.
|----AcmePIP3A4v02_02
|------ Maps
|------ Records
|------ Connections
|------ Etc. etc. etc.
This was helpful, It led me to the solution, which was to add the path to my jdk in the server.bat file.
Thanks