Java service in my package is not compiling with updates after save… It is reflecting the updates only on server restart.
I tried reloading the package, disabling/ enabling the package but nothing helps. only on server restart changes are reflecting

Hi Vignesh,

are there any messages in the server.log related to this?
Might be an issue with the watt.server.compile* settings.

Which version of wM are you using?

Regards,
Holger

This is issue is with one particular package. java services in other packages are working fine. nothing in server log though.

Can you share info about the Java code throughout that package? There may be a naming conflict or dependency issue of some sort.

Relatedly, there is a principle that some follow that may be applicable here – the 3 rules of Integration Server development:

1. Don’t write it in Java.
2. Don’t write it in Java.
3. Don’t write it in Java.

Java should be limited, in general, to small and focused utilities. Small utility-like services may be the case here, but given the symptom, seems like it might be a “too much Java” item.

Thanks for your response!

I have added log4j-2 jars in the classpath(buildpath) and there are log4j-1 available in code/jars/static folder of that package. I suspect this conflict is causing the issue. I can’t remove the jars under static since it might be referred in any other package. not sure how to mitigate this.

That seems like a reasonable possibility to investigate. It’s been a while since we have ever added a jar to a package so I don’t recall the details but I don’t think we needed to add the jar to the build path. Also, you might consider removing any log4j jars from the package altogether. Review the About page for your IS. You’ll likely see the log4j jars are already part of the environment.

And an extreme option: don’t use log4j at all and instead leverage other facilities. We use a combination of

• pub.prt.log:logActivityMessages – works great in conjunction with the audit logs viewable in MWS
• com.wm.app.b2b.server.ServerAPI.getLogStream/com.wm.app.b2b.server.LogOutputStream - Same components that write and rotate stats.log; wrote a couple of wrapper services to make it easy to write to a custom log file; not as flexible as log4j but not as complex nor bloated as log4j.
• pub.flow:debugLog (rarely).

You can check the error log on the IS side, or the error logs on the designer as well(Window->Show View->Error Log).
If the problem is limited to a particular package , you can also try to move a few java services at a time to another package and check to narrow down the compilation issue.

-NP

You cannot add log4j jars to static class path, you will definitely get conflicts as we already have log4j in the product.
You should try as much as possible to only put jars in the code/jars directory of your package so that it loaded via a private class loader associated with the package (advantage also that you don’t need to restart the server!). You can then create java services to expose features from your library to other package. It’s bad practice to write java services in other packages that depend on a jar in a different package. Primarily because its a non determinable dependency that will bite you on the bum later

@reamon - I would not say that java services are a bad idea, personally I’m a fan. What I think you are referring to, is the case where developers use it in appropriately, often because they are not aware that the same functionality has already been implemented as part of the platform. i.e. I would not develop a top level service in java, nor try to build business logic or do complex transformation. However if you want to do some complex number crunching it can often give much better performance results. Again if I have a flow service that has to iterate over large data sets I will often write the block code in java and then delegate the individual processing to a child service that is a flow service. Albeit that last one is normally frowned upon. Java services should not invoke services, unless it is configured in some way (rather than hard coded). Trading Networks is good example of this.

Sorry for the long text, I couldn’t resist

regards
John.

Agreed. Not a bad idea per se. Just something to try to keep to a minimum. It seems people drop to Java because its familiar, not because of any real advantage. Or perceived efficiency benefit – “it will run faster in Java”. Likely so, but does that really matter? 99% of the time, it does not IME.

Of course there are times Java is needed/useful. And Java libraries can be plugged in to be leveraged. The intent of the extreme “Don’t write it in Java” is to emphasize that the majority of integration scenarios are likely to be written in FLOW, with help from Java where appropriate.

Hi

Try removing watt.server.compile extended setting it should work for you. I would like to join @John_Carter4’s club of Java Services. I always loved writing Java services to get things done faster.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/9ee365738fea51d245075de5cb3ed2709b74ede4_2_1035x270.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/9ee365738fea51d245075de5cb3ed2709b74ede4_2_1380x360.png 2x" data-dominant-color="F5F6F6">

image1531×400 32.2 KB

Do you mean code development is faster? Are there metrics you can share about FLOW vs. Java efforts?

(I’m not against Java services – I’m against using Java as the primary language within Integration Server. Java is a necessity. But should not be the first choice.)

Hi @reamon - I dont have any metrics with me. But I do know compiled Java code runs faster than flow services. I usually use it when I have large documents and complex looping to avoid slowness.

Most likely, but in the vast majority of cases, that additional speed does not matter. In the time that I’ve been working in Integration Server, I’ve never had to redo something from FLOW to Java due to speed.

The 3 rules of optimization are:

1. Don’t.
2. Don’t yet.
3. Profile before optimizing.

If you don’t measure, you don’t know if the approach is actually faster. And depending upon the specifics of the integration, an additional 5 seconds of processing (or even minutes) may not matter in any way. For example, unattended data sync interactions where there is not a user waiting for a screen, it matters not at all if the data arrives 15 minutes later.

Runtime speed is not the only factor to consider when developing a solution. IME, runtime speed is almost never a constraining factor.