This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi. I haven't recently used external generation of .wsld and .xsd files from web service implementation class, but last time when I did, it was working just fine. However, now when I try I get the exception :
The only differences between last time generation and now is a new system installation. I believe that some libraries are not in the classpath, but try to put them as environment variables but, still nothing is changed... What did I wrong???
Joined: Sep 26, 2008
Hi, the problem is resolved. Yesterday when I was setting "WSIT Installation Instructions", and the webservices-api.jar from wsit installation has been copied into JAVA_HOME/../lib/endorsed directory.
I have just erased it and it works fine. But what should I do if I need to generate those artifacts again, and in order to wsit works fine I need there webservices-api.jar?
Have you tried to include the JAR on the classpath using the -cp option of wsgen?
Joined: Sep 26, 2008
Hi Ivan, of course I did. But just as I said until I erase the webservice-api.jar from the mentioned location, the exception above raised over, and over again. When I erase it's ok everything.
Joined: Oct 04, 2006
I think it is a bad idea to store libraries in the endorsed directory in the Java installation. This means that they are available to all Java applications that run on your system. This may cause conflicts if you include another JAR with the same classes etc on the classpath of an application.
A quote from this article: http://www.ibm.com/developerworks/library/j-classpath-windows/
JAR files in the jre\lib\endorsed directory are also added to the classpath of all applications run with that virtual machine. The difference is that these files are actually added to the bootclasspath rather than the usual classpath and can replace the standard classes shipped with the JDK. This approach is especially useful for upgrading the XML parser and fixing bugs in the VM.
Once again, though, while this approach seems convenient, it is also a long-term mistake for the same reason. If you need to replace JDK classes, use the -Xbootclasspath/p option at runtime to avoid accidentally loading the wrong version of a class.
What I meant was that you, instead of storing the library in the endorsed directory could include it using the -cp option of wsgen, if the library is needed to generate artifacts.
I have successfully used WSIT but never installed anything in the endorsed directory.