I have written a java service. In this java service i am calling a method which is present in shared area. This method uses a varible which is declared as public static in shared area and the value of this variable is set here.
suppose if in shared area:
public static void fieldNotPresent = “”;
public static void verify(String fieldDesc){
try{
throw new Exception();
}
catch (Exception e){
fieldNotPresent = fieldNotPresent + " " + fieldDesc;
}
}
i invoke this function from my java service
static variables, by definition, never go away. So each and every time you are calling that (poorly formed) methods, you are appending " birthDate" to that string variable. If you run it 1000 times, you will have “birthDate” repeated a 1000 times.
Do some study on static variables. And try/catch blocks. What you are doing and what you are expecting to happen indicates you are very new to Java. Some study of the basics will help you tremendously.
Thanks for the reply. Thanks for throwing light on static variable’s nature.
Politely i wish to say My doubt here is…
I am running completely the service twice. I am not calling this function in the same run twice. Do you think even in subsequent runs also statics wont die… i had run this in Eclispse IDE. Here when i RUN TWICE i am seeing just a single “birthDate” getting printed even in the second run. Am i makin sense.
The behavior you see in Eclipse is because the JVM is getting run two separate times–and thus the static variable is created anew each time.
For IS, the JVM is constantly running. The static var is created when IS is started. When you call the service in IS, you are not doing separate JVM “runs”. It is one run. You are calling the Java service and your method multiple times within a single JVM run.
I think this is a webMethods pitfall. Why is that wM didnt give so much attention as it comes to java services. We dont even have a debugger for java services.
No it isn’t. It’s a lack of understanding JVM behavior on your part. Every JVM on the planet behaves this way. Do the same thing with WebSphere, WebLogic, JBoss, etc. and you’ll get the exact same behavior. When you run your test in Eclipse, it isn’t the garbage collector that throws away the static variable. You’re running the JVM multiple times. When the JVM shuts down, EVERYTHING goes away. You’re way off base on this one.
Because IS is not a Java app server. It is an integration server and it’s primary development language is FLOW. Java services are supported but are only needed occassionally. It would be nice to be able to step through Java services with a debugger but the lack of that feature isn’t a show stopper. For this specific case, a debugger would not have helped you in any way because you apparently don’t understand the concept of static variables and their behavior in a single JVM session.
The credibility of your complaint about IS support of Java is severely compromised by poor code such as what you posted. It uses a static variable for no descernible reason. It is not thread safe. And ultimately this “verification” method probably isn’t necessary to be written in Java.
I may appear to be coming across a bit harsh but one of my pet peeves is people criticizing a platform, or claiming to have found a bug, when it is clear they are very new and don’t understand the basic concepts.
Feel free to post additional question and queries to gain additional understanding. Myself and others will be more than glad to help. But you should probably drop the “pitfall” and or “bug” claims until you have more experience.
Let me ask this: you do understand the IS runs in a JVM (the Sun JVM by default)? And that “starting” IS means launching a JVM and running the IS code within it? And that the JVM continues to run until you shut it down (using Administrator or stopping it from the command-line)?
Easy… Dear reamon i am not claimin i found a “bug”. We keep writing java services often. After working with Eclipse/WebSphere this environment is a bit difficult for me to get adjusted to. Thanks for making things clear. Inside the verify method i doInvoke and validate the argument. Ok that goes with my logic. Nice advice though. Thanks.
however i need to explore on this further. let me ask this… we compile using javac and run using java. where exactly this is done with java service. when i save my program compilation takes place. when i press the run button my service is run. how exactly javac and java are triggered
Java services are compiled when you save the service.
When you run a service within Developer, Developer communicates with IS on the server to pass the inputs, the name of the service, etc… IS runs the service and the results are returned to Developer for display. A new JVM is NOT started. The service is run within the already running JVM in which IS is hosted.
No, but you claim that IS has a “pitfall.” IS has many pitfalls, but the handling of static vars isn’t one of them–IS doesn’t actually do anything with statics at all. They are managed completely by the JVM.
One of the threads on the forums here talks about how experienced Java programmers can negatively impact integration projects based on IS. This is because Java programmers try to do things the way they do things in WebSphere, WLS, etc. You need to change your mindset, and it sounds like you recognize this.
You should have very little Java in your integration solutions. I don’t know the specifics of why you’re using Java to do validation but I suspect that it has more to do with a comfort level with Java (and lack of comfort/familiarity with FLOW and the built-in services) than it has to do with real need. IMO, if you really want to stick with using a Java service for this, the service example you posted needs to be fixed–it is not thread safe and probably doesn’t need to be using a static var.
what is required is we have to validate fields present in a document list. there are many fields and we have to check if these fields are null or empty string.
earlier developer has writen a java service which would do this
for (number of times){
verify(field1, fieldDesc1);
verify(field2, fieldDesc2);
verify(field3, fieldDesc3);
verify(fieldN, fieldDescN);
}
in the shared
public static void verify(String field, String fieldDesc) throws Exception{
try{
Service.doInvoke();// calls a function that would throw exception if field //absent
}Catch(Exception e){
//exception rethrown to java service from shared
}
the java service captures the exception and throws exception at runtime if any field not present
instead of throwing expception i need to collect the fields that are not present and list them out
so in catch block instead of throwin it to java service i had written such a step by populatin a fieldNotPresent static variable…
and in the java service i put this fieldNotPresent variable in pipeline. i felt a bit lazy to modify the code completely. so i felt using a static variable would fix the need with minimal change.
Change the verify method to return a string. Don’t rethrow the exception. Simply return the error message of the offending field.
Collect all field failures in main service in an array, array list, hashtable, etc. Then place the list of offending fields in the pipeline.
But perhaps the validate service, which can check min lengths, presence/absence of fields, etc. would be a better option overall? No need to reinvent the wheel.
what you say is obsolutely correct and it is the best way too which came to my mind. Then in all the places where verfify function is present i need to get the value returned from this function and store it in a array. Since the code is already existing, I felt i need to make changes in all the place i call the verify function. So i went for a shared static variable and this drove me to start this thread and this made me know the jvm internals as far as wM is concerned. Thanks.
Good to hear, but these aren’t the JVM internals “as far as wM is concerned.” They are the JVM internals, period. This behavior is not unique to wM. It exists in all JVMs.
If you’re referring to “web method internals” as exemplified by this discussion of static vars, then I don’t know how I can make this any more clear–the handling of static vars within Java code is not a webMethods thing. It has nothing whatsoever to do with webMethods. webMethods does not create a JVM. They redistribute the JVM from Sun.
The behavior of a static var, including its lifecycle, is defined by the JLS. It does not vary from JVM to JVM (not accounting for JVM bugs, of course).
If you’re looking for information about the internal Integration Server behavior in general, I don’t believe anything like that is available. Are you looking for something in particular?
No sir not regarding this static issue. Sorry for not being so clear. Generally any animated presentation regarding wm Internals. How do i put it!! can you get me sir. As i have seen a presentation regarding the advantage of SOAP. IS, its capability, developer-IS interaction etc
The wM documentation and the training materials are all that is available. Some of the docs go into the internal operations at a high level. Some of the GEAR docs reveal some of the internals but you end up needing to read through quite a bit of material to find those nuggets.
If there is anything in particular that you’re looking for information about, feel free to post it. With the amount of experience represented here, someone is bound to have some helpful info.