J2EE explicitly denies modifying handler chains. We actually don't agree with that, but that is the specification.
You are forced to externalize it with using the webservices.xml file. If you want dynamic behavior I recommend building an abstraction in your static handler to call its own chain of dynamic handlers.
Do it declaritively via application-client.xml and you will be happy.
I would like to use the application-client.xml file but I do not know how to use it in a client application (Java Swing). How do I specify that it should be used?
I am not using a JNDI lookup for the service stub! I am using the wsdl file at runtime to dynamically generate the stub.
URL url = new URL(wsdl); QName qname = new QName(ns,service); ServiceFactory factory = ServiceFactory.newInstance(); Service service = factory.createService(url,qname); Stub stub = (Stub)service.getPort(PublisherClient.class);
How can I use the application-client.xml file?
Lets preach this again: Your fat clients or non trivial cmd line apps should run on JBoss. At its bare minimum this buys you naming/lookup (JNDI) and managment (JMX). These two every non trivial app would need anyway. On top of that you can deploy preconfigured WS4EE clients and don't have to use the ugly DII.
I don't agree. I do not need JNDI or JMX. I actually feel reluctant to use it in a client application. The benefit of using webservices is being able to transfer complex communication over HTTP (eg. port 8080). If I have to look up the service (using JNDI) over another port (eg. 1099) I will have to open up that port in my firewall.
It must be possible to do this with pure HTTP traffic?
I don't know why you are saying that my client application should run on JBOSS. What do you mean by that? Do you mean I should use the JBOSS libraries or I should really startup JBOSS on the client side?
Why are you saying that DII is ugly? In my opinion this looks like the cleanest way to consume a webservice.
Can anyone explain to me how they would implement a Fat client (java swing) - Webservice communication. But take in account that I prefer not to open up to many ports on my firewall (preferably only port 8080).