> -----Original Message----- > From: Dennis Sosnoski [mailto:[email protected]] > Sent: Tuesday, November 02, 2010 3:00 PM > To: [email protected] > Cc: KARR, DAVID (ATTSI) > Subject: Re: How to specify wsdlLocation for wsdl bundled in jar? > > Hi David, > > I'd think the way to handle this would be to use the service > constructor > that takes a WSDL URL. You can find the URL at runtime for a file in > the > classpath by using the classloader getResource(String name) method.
Ok, good. That's simpler. I've verified this works. > On 11/03/2010 10:49 AM, KARR, DAVID (ATTSI) wrote: > >> -----Original Message----- > >> From: KARR, DAVID (ATTSI) > >> Sent: Monday, November 01, 2010 12:54 PM > >> To: [email protected] > >> Subject: How to specify wsdlLocation for wsdl bundled in jar? > >> > >> I'm trying to produce a "client" jar that includes my generated > >> > > classes > > > >> and my wsdl and schema. > >> > >> At the root of the jar file, where the "com" directory exists, I > also > >> have a "contract" directory, that has a subdir that specifies a > >> contract > >> version number. In that directory is my wsdl and schemas. > >> > >> In my call to "wsdl2java", I tried specifying > >> "classpath:contract/<versiondir>/<wsdlfilename>". > >> > >> When I generate this and then run it in the container, I see this in > >> the > >> console: > >> > >> "Can not initialize the default wsdl from > classpath:contract/..." > >> > >> What should the "wsdlLocation" value be? Do I just remove > >> > > "classpath:" > > > >> from it? I thought it had to be a URL, so that seems unlikely. > >> > > I've gotten past this for now, but there's at least one issue here > that > > is somewhat mystifying. From what I've read about the idea of having > a > > classpath-based URLStreamHandler, the two options are installing the > > handler into the JVM or calling the overloaded URL constructor, along > > with the instance of the overloaded stream handler. I'm not willing > to > > install it into the JVM at this point, although I might consider this > > later (perhaps just to avoid the innocuous "Can not initialize the > > default wsdl ..." message at load time). > > > > I now have a static block in a utility class that creates the Service > > subclass instance, and it uses the URL constructor that takes a URL, > > String, and URLStreamHandler. I pass "classpath:..." as the second > > parameter and an instance of my "ClasspathURLStreamHandler" which > gets > > the system classloader as a constructor argument. > > > > My ClasspathURLStreamHandler is just this: > > ------------------ > > public class ClasspathURLStreamHandler extends URLStreamHandler { > > private final ClassLoader classLoader; > > > > public ClasspathURLStreamHandler(ClassLoader classLoader) { > > this.classLoader = classLoader; > > } > > > > @Override > > protected URLConnection openConnection(URL url) throws > > IOException { > > final URL resourceUrl = > > classLoader.getResource(url.getPath()); > > return resourceUrl.openConnection(); > > } > > } > > ------------------ > > > > It now apparently finds my WSDL, because I can get the porttype and > call > > the operation. > > > > However, what's sort of odd is that it apparently never gets into the > > "openConnection()" method. So, it seems like this isn't doing > anything. > > > > On the other hand, I tried changing to use the "URL(String spec)" > > constructor, but that fails with a MalformedUrlException. > > > > So, somehow by specifying a URLStreamHandler, even though it's not > > actually using it, it causes some sort of default behavior that does > > exactly what I'm trying to do, which is looking up the "spec" in the > > classpath. > > > >
