Hi Craig, I'm experiencing the same problem that you are, and have been for a while now. Here is what the examples on the wiki neglect to mention:
A stand-alone client cannot execute the code posted there without having JBOSS running locally (i.e. on the same machine). Once you assume this architecture to be ideal for your situation (definitely not ideal for me), go ahead and deploy the j2ee client jar just as the wiki suggests, but make sure your stand-alone client and jboss running the j2ee client jar are actually on the same computer. Your stand-alone client should then pull the WS artefacts off the local JNDI, and execute them locally. The work of connecting to your remote web service, running on a different computer with yet another instance of JBOSS, will be performed by the j2ee client jar on your local JBOSS instance. Sounds convoluted? I agree. Looks like an academic exercise? I agree. Not something you'd exactly present to a customer who wants to run your stand-alone client, right? To work around this I've spent sleepless nights trying all sorts of configurations to get a true stand-alone client without the need for a JBOSS install on a client machine. My stand-alone client is deployed via JWS, as a requirement. So obviously deploying JBOSS at each download of the client is out of the question. In this dark, obscure and lonely quest, I've experienced the classcastexception issues you've come across. The classcast exceptions are probably because you have jwsdp jars in your classpath, particularly the jaxrpc ones, as well as Jboss jars. The client runtime seems to get confused between sun and jboss based classes at so many different levels that it's easier to simply isolate the two types of jars. You might say lets cast the darn things, but trust me, if you intend to actually spend your developing your application, isolate the files one by one. Run your app with either JBOSS or Sun jars. There will be one or two sun classes that you cannot do without as your classloader complains, but pick them out of the jar and stick them in a new sanitized jar. I tried running just Sun based jars for my app, got some different type of problem, so now I'll try and run against just the JBOSS based jars, with a few selective Sun classes. I've read the responses that talk about the bane of using implementation specific solutions for the stand-alone client. Guess what folks, my customers do not really care whether or not the stand-alone client is J2EE compliant or not. The interoperability thing is cool, but if we have to include JBOSS on every single client computer to get the thing to work, how can this be a portable solution? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3902700#3902700 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3902700 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
