Well, this just proves it's (almost) never what you think.... The problem seems to be with how I'm constructing the StreamSource: I'm giving it the InputStream from the URL. The problem appears to be then that JAX-WS always expects a valid SystemId from the StreamSource, but it gets back null. The solution is to construct the StreamSource using the string form of the URL, something like this: new StreamSource(url.toString()).
Rich On Mon, Jan 10, 2011 at 11:14 AM, Steele, Richard <[email protected]>wrote: > I did that this morning: created a simple bundle with an activator that > uses Bundle.findEntries() to dump out everything it finds in META-INF. And > it works as expected. > > I'm beginning to think what I've stumbled across is a more general problem > trying to use JAX-WS inside an OSGi container. In particular, I suspect > that Endpoint.publish() is making assumptions about class loaders and such. > Some searching this morning seems to reinforce this viewpoint. (In fact, it > looks like Glassfish 3 uses OSGi-enabled versions of Metro/JAX-WS/JAXB, but > since these appear to import container-specific packages the don't do me > much good.) > > If this is correct, then this is obviously not an issue specific to Felix. > Still, if anyone has a specific solution to the problem I'd appreciate some > hints. > > Thanks, > Rich > > > On Mon, Jan 10, 2011 at 10:25 AM, Richard S. Hall <[email protected]>wrote: > >> If URL Handlers is enabled, then it should register a handler to deal with >> the bundle: protocol. You can create a simple bundle that tries to create >> such a URL to make sure it is working. >> >> -> richard >> >> >> On 1/7/11 14:05, Steele, Richard wrote: >> >>> I'm working on a prototype implementation of a bundle that publishes >>> JAX-WS >>> endpoints for specially marked services. (I realize there are off the >>> shelf >>> implementations of various tools that ought to do the same thing, but >>> right >>> now I'm just getting my feet wet.) >>> >>> I've actually been able to get the endpoint published just fine, using >>> something like this: >>> >>> private Object startEndpoint(ServiceReference reference) { >>> >>> Object service = getBundleContext().getService(reference); >>> if (service != null) { >>> ClassLoader originalClassLoader = >>> Thread.currentThread().getContextClassLoader(); >>> try { >>> Object instance = createEndpointImpl(service); >>> >>> >>> Thread.currentThread().setContextClassLoader(instance.getClass().getClassLoader()); >>> endpoint = Endpoint.create(instance); >>> endpoint.setMetadata(getMetadata(reference)); >>> // TODO: remove hard-coded port number >>> endpoint.publish("http://0.0.0.0:7001/hello/";); >>> } finally { >>> >>> Thread.currentThread().setContextClassLoader(originalClassLoader); >>> } >>> } >>> >>> return service; >>> } >>> >>> The problem I'm running to, however, is with setting the endpoint >>> metadata; >>> this is a list of the WSDLs and schema types used to generate the >>> endpoint. >>> (Without specifying this JAX-WS attempt to create one at runtime; it >>> manages >>> to get close, but close isn't enough.) >>> >>> What I've been trying to do is get these files from the API bundle using >>> Bundle.findEntries(), something like this: >>> >>> Enumeration<?> entryEnumeration = >>> serviceBundle.findEntries("/META-INF/wsdls", null, true); >>> // enumeration can be null if path isn't found >>> if (entryEnumeration != null) { >>> while (entryEnumeration.hasMoreElements()) { >>> URL entry = (URL)entryEnumeration.nextElement(); >>> try { >>> md.add(new >>> StreamSource(entry.openConnection().getInputStream())); >>> } catch (IOException e) { >>> // TODO: do something >>> } >>> } >>> } >>> >>> This actually works exactly what I want: I get a list of StreamSources to >>> the URLs' input streams. However, when the endpoint is published I'm >>> getting a MalformedURLException because the URL is using a bundle: >>> protocol, >>> which isn't known. >>> >>> Based on my searching I expect that Felix will start by default with the >>> URL >>> Handlers Service started, no? So why can't these URLs be resolved? I'm >>> guessing I'm missing something silly... >>> >>> Thanks, >>> Rich >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
