Hi All,
I am creating a java service that will return the service name from which it is called, compatible with log4j logging. It basically replaces the ‘:’ with a ‘.’.

[highlight=java]
String loggerName = null;

NSService myService = (NSService) Service.getCallingService();
loggerName = myService.getNSName().getFullName();
loggerName.replaceAll(“:”,“.”);

// pipeline out
IDataCursor pipelineCursor = pipeline.getCursor();
IDataUtil.put(pipelineCursor, “loggerName”, loggerName);
pipelineCursor.destroy();

[/highlight]
I don’t want to invoke the pub.string:replace service in here. There is a policy against using existing java services in new java services here.

This is the error I get.
Method replaceAll(java.lang.String, java.lang.String) not found in class java.lang.String. loggerName.replaceAll(“:”,“.”);

Help!!

Thanks in advance,
Zafar.
^

Method replaceAll(char, char) not found in class java.lang.String.
loggerName.replaceAll(‘:’,‘.’);
^
This is the error…

The replaceAll method was introduced in JDK 1.4. Looks like IS is being run under an older JVM.

Interesting that there’s a restriction on calling built-in services from Java services–seems a bit strange. What’s the policy on using unpublished methods (myService.getNSName().getFullName() uses undocumented methods)?

Rob,
I am developing using the JVM that comes default with IS 6.5.
I compiled this with HP JVM 1.4 and it works. Maybe its something in the JVM provided with the IS that is causing this error.

Still investigating.

The restricion is more against invoking other services.
The policy is, if you can do something by just using a single java call, do it that way. That would not only keep the code simple, but also reduces the dependency on other packages/services.

In this case, replaceAll() should do what you can also do by invoking the pub.string:replace service, and deal with all the lines of code you would have to write for the same. FYI.

Does anyone know of any known issues with the JVM webMethods provides?

Thank you,
Z

Got it working. The java environment variable on the server was set to an older version of java. When it was changed to point to the JDK 1.4, the service compiled successfully.