如何同时使用同一类的不同版本
我必须为一组 Web 服务提供一个接口，我已为其生成了代码存根和对象绑定。许多事务共享一个公共对象模型，因此生成的代码很大一部分是重叠的。通常这不会是一个问题，因为我只会重复使用相同的代码，因为 wsdl 将链接相同的 xsd 文件。
不幸的是，这些服务的提供商已将 xsd 分开，以便每个服务绑定到相同文件的单独集合（基本上是副本）。在他们的规范中，他们指出客户端的实现应该隔离每个 Web 服务以便于维护。基本上，他们希望能够修改单个 Web 服务的 xsd，同时保持所有其他服务不变。
问题如下：
如何将这些不同的生成类集集成到同一个程序中，以便每个服务公开其功能而不干扰其兄弟？
我认为的一个解决方案是为每个对象创建一个外观，以公开所需的功能和对象模型，以便实际的实现保持隐藏。然后，尽管巧妙地使用自定义类加载器，每个外观都会加载一个特定的 jar，其中包含为此特定服务生成的代码。
有什么想法吗？想法？您遇到类似问题的经历是什么？
谢谢
I have to provide an interface to a set of web services for which I have generated the code stubs and object binding. Many of the transactions share a common object model and thus a large part of the generated code overlaps. Normally this would not be a concern as I would just re-use the same code since the wsdl would link the same xsd files.
Unfortunately here the provider of these services has separated the xsd so that each services binds to a separate set (basically a copy) of the same files. In their specification they state that the implementation of the client side should isolate each web-services for easier maintenance. Basically they want to be able to modify the xsd for a single web service while leaving all others untouched.
The question is as follows :
How could I integrate these different set of generated classes in the same program so that each services exposes their functionality without interfering with their brethren ?
One solution I thought was to create a facade for each of them that would expose the desired functionality and object model so that the actual implementation remains hidden. Then though clever use of custom class loaders each facade would load a specific jar containing the generated code for this particular service.
Any thought ? ideas ? what was your experience facing a similar problem ?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否考虑过使用基于 OSGi 的捆绑包（例如 Eclipse Equinox 运行时）？使用基于 OSGi 的实现，每组生成的类将位于一个单独的包（.jar 文件）中，该包具有自己的类加载器，并且可以有选择地将其 API 的一部分导出到应用程序的其余部分。因此它提供了您提出的解决方案的现成实施。
Have you considered using OSGi based bundles (e.g. Eclipse Equinox runtime)? Using an OSGi based implementation each set of generated classes would be in a separate bundle (.jar file) that gets its own class loader and can selectively export parts of its API to the rest of the application. So it provides a ready implementation of the solution you proposed.
一般来说，处理此问题的最简单方法是使用 jaxb 绑定文件（或 CXF 的 wsdl2java 工具的 -p 参数）将生成的代码映射到特定于特定服务的包中。因此，每个服务都有自己的对象可以使用。
如果您必须集成各种服务，那么复杂性就会随之而来。就像从一个返回来调用另一个一样。由于对象完全不同，您需要编写代码将数据从一个对象复制到另一个对象。可能不好玩。 :-(
In general, the easiest way to handle this is to use a jaxb binding file (or the -p param to CXF's wsdl2java tool) to map the generated code into a package specific for the particular service. Thus, each service would have it's own objects to work with.
The complexity would come if you have to integrate the various services. Like take the return from one to call into another. Since the objects would be completely different, you would need to write code to copy data from one to the other. Possibly not fun. :-(
对于 Java 来说，当两个类由不同的类加载器加载时，它们是不同的。您可以通过从 2 个 URLClassLoaders 自行加载类的 2 个版本来利用这一点，这些 URLClassLoaders 获取相应 jar 的 URL 作为类路径。如果两组对象实现相同的接口，您可能不需要构建 2 个外观。
更新
是的，jar 不应该位于主应用程序的类路径上。如果您将主应用程序的类加载器设置为 URLClassLoader 的父级，则加载的类仍然可以访问应用程序使用的类路径的其余部分。
对于静态，如果它们是常量，它们可能会被编译器内联。对于静态变量，每个加载的 jar 都会得到 2、1。如果这些变量在 jar 的上下文之外使用，您可能必须通过其类对象的反射来访问它们。您是否需要选择一个或组合它们取决于应用程序，我猜测如果您可以在 1 个应用程序中加载和使用 2 个版本，则任何静态变量都将仅在相应 jar 的上下文中使用。
For Java two classes are different from eachother when they are loaded by separate classloaders. You can take advantage of this by loading the 2 versions of the classes yourself from 2 URLClassLoaders which get the URL of the respective jars as classpath. You might not need to build 2 facades if both sets of objects implement the same interfaces.
update
Yes, the jars should not be on the classpath of the main application. If you set a classloader of the main application as parent to your URLClassLoaders, the classes loaded still will have access to the rest of the classpath your application uses.
For
statics if they are constants they will probably be inlined by the compiler. For static variables you will get 2, 1 for each jar loaded. If those variables are used outside of the context of the jars, you will probably have to access them via reflection off their class objects. Wether you need to select one over the other or combine them depends on the application, it would be my guess that if you can load and use 2 versions in 1 application that any static variables would only be used in the context of the respective jars.