Anirvan Majumdar

Hello,

I've been working on a SAAJ-based client, and am almost done except for the handling of attachment. What i've managed to figure out is that the attachment data does get appended to the SOAP message, but the structure is NOT conforming to the MTOM specs. By intercepting the HTTP request, I was able to see that the entire request body's content-type is set to 'text/xml'. as per the MTOM specs, this should 'application/xop+xml'. Is there any specific way to enable MTOM for dispatching SOAP requests using SAAJ's SOAPConnection object?

Something like the way we can do so using Apache Axiom's 'Options' instance. [i can't use axiom migrating to a third party library is not an option at this point of development].

thanks

so it seems.

but any suggestions as to how can one deal with a scenario where the serialised instances can be of any class adhering to a contract specified by an interface, where the de-serialiser isn't aware of which particular implementation has been used to serialise. And since the de-serialiser relies only on the contract, there's no need for it to have all available implementation classes in its classpath.

Hello,

I'll try and explain my problem as concisely and clearly as possible. I feel that what I'm trying might inherently be wrong, but somehow I believe it should work. So please feel free to treat this post as a mere clarification about the Serialization mechanism.

So, I have an Interface implemented by a class [it's implied they exist in separate files].
// ----- SomeInterface.java public interface SomeInterface extends Serializable { public void setMsg(String msg); public void printMsg(); } // ----- SomeImpl.java public class SomeImpl implements SomeInterface { private String msg; public void setMsg(String msg) { this.msg = msg; } public void printMsg() { System.out.println("Msg is: " +msg); } }
Now I serialize an instance of SomeImplclass:
... public void SomeMethInSomeClass() { FileOutputStream fos = new FileOutputStream(new File("c:/test.ser")); ObjectOutputStream oos = new ObjectOutputStream(fos); SomeInterface si = new SomeImpl(); si.setMsg("blah blah"); oos.writeObject(test); oos.close(); fos.close(); System.out.println("------ done -------"); }
Now in a separate project, I have a JAR of the application above which contains the interface SomeInterface, but not the implementation class SomeImpl. In this application if I try to do the following:
.... .... public void deserialiserMethod() throws Exception { FileInputStream fis = new FileInputStream(new File("c:/test.ser")); ObjectInputStream ois = new ObjectInputStream(fis); SomeInterface si = null; System.out.println("------ reading ----------"); si = (SomeInterface) ois.readObject(); si.printMsg(); System.out.println("------- done ----------"); ois.close(); fis.close(); } ....
... I get a ClassNotFoundException [for SomeImp]. Now I know that my other project does NOT have the SomeImpl class in its classpath. But shouldn't casting into a reference of the parent interface take care of that dependency?

thanks for your inputs!

Try setting up the <security-constraint> and <web-resource-collection> in your web descriptor. That should work just fine.

Weell, for starters you will need to understand a bit of programming. Jython is a sort of alternative based on the Python language implemented for the Java VM. You can read more about it here.
However, if you want to stay completely away from programming, Grinder does offer the option of recording test scripts using a TCPProxy. But that works only in case you want to load test a web based application. Otherwise, you'll have to get your hands dirty if you wish to test a desktop based, standalone Java application.

Grinder is another option you can take a look at. I've used it for quite some time now, and particularly in case of huge concurrent user loads it's quite effective.

As is quite apparent, 800 options does make the whole thing quite unusuable. In fact, I think that beyond a reasonable number like 20, the options become quite hard to scroll and find.
If you don't want to do things at the server side, you can probably use an AJAX based lookup solution. Ask the user to type a few characters, and retrieve a small list of values which partially/completely match the typed in value.

I don't think you need to restart Tomcat to reload the context. Undeploying and re-deploying the web application will work just as well. However, you can't do so programmatically from within your web application.
And if I'm not wrong, Tomcat has the ability to detect a change in the web descriptor [web.xml] of any deployed application and automatically re-deploys it.

I am assuming by changing the value of context variables you mean changing them in the web.xml.

Otherwise, if you're changing attribute values using the ServletContext interface, then I think the change is visible to all servlets instantaneously. Though you need to have the mechanism present in your servlets to keep a check on any changes. Alternatively, you can put to use the ServletContextAttributeListener to update the value of attributes in a common lookup data-structure, which all servlets use to retrieve attribute values.

I second Bear's opinion on that. IDEs are after all abstractions built to speed up things. You can only use an IDE to its full potential if you know the underlying mechanisms pretty well.

Now, why would you think that making your application 'synchronized' will have anything to do with the number of servlet instances that get created? I'm sorry to break it to you, but synchronized or not, even then there will be ONLY one servlet instance for any number of user requests. Making your app synchronized will only help in keeping the threads [for every request] from interfering with each others data.

As for the number of users, you've got to realise that Tomcat as a server is capable of handling a really large number of parallel requests. I'm quite sure that the number is much >> 1000 concurrent requests. The exact number I am not sure of. However, if your application processes a really large amount of data for every request, then you can witness an awful response time even for 10 concurrent users.

Firstly - yes, there will be only one instance of your servlet catering to all 100 user requests. However, there will be 100 threads representing each of the requests. So you will have to be careful about shared data. To be on the safe side, avoid using or be extra careful about any data that you define as a member/class variable.

Secondly - Tomcat can handle a load of 100 concurrent users without any fuss. I don't think you really need to bother about clustering, or for that matter load-balancing for a user load like that. The upper limit of the user load is subject to the kind of data structures you're using, and the hardware capabilities of your setup.

weeeelll - at least I can assure you that I wasn't 'angry' in the least :] And please accept my apologies for making such a grossly presumptuous mistake.
I at least hope you got your answer.

He probably meant 'struts', but yeah, like David mentioned - JSON is a JavaScript notation which is independent of any underlying server side technology. So using ASP, JSP, Servlet, etc - won't make any difference!

A similar query was answered in a thread before. You can take a loot at it here.

Is your Tomcat launching without any issues? Take a look at the Tomcat console during startup. Perhaps there's some exception that's occurring.