开始搞Web Service，用了CXF，下载了2.0.8和2.1.1，开始弄的是2.1.1，发现有问题：
java.lang.NoSuchMethodError: org.jaxen.BaseXPath.<init>(Ljava/lang/String;Lorg/jaxen/Navigator;)V
怎么也发布不成功，后来修改成2.0.8，发现可以了，通过浏览器访问什么的都没有问题，然后从wsdl生成stubs后，运行unit test有问题：
java.lang.IncompatibleClassChangeError
at org.apache.cxf.wsdl11.WSDLServiceBuilder.copyExtensionAttributes(WSDLServiceBuilder.java:120)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:228)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(WSDLServiceBuilder.java:153)
at org.apache.cxf.wsdl11.WSDLServiceFactory.create(WSDLServiceFactory.java:117)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:138)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:129)
at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:55)
at javax.xml.ws.Service.<init>(Service.java:57)
唉，步履维艰啊
2008年8月21日更新：
发现这些都是Classpath搞的，因为原来的工程中也包含了老版本的Web Service的包，我们这个工程在原来的工程里面，但是我发布的时候没有包含原来的jar，但是Eclipse工程里面是依赖的，所以Server运行没有问题，在Eclipse跑单元测试的时候有问题。
2.1.1的问题是DOM4J.JAR搞的，里面也包含了jaxen的类，把那些类从jar包里面去掉问题解决
新的项目其实是转向Web Service的，公司的整体架构将采用SOA，本来这一阶段只是个临时阶段，但是Web Service的任务要提前开始了，因为另外一个新的项目需要使用我们的Service，而现在的这个项目是基于一个老的项目，只使用EJB2，所以在原来的项目的EJB3和Web Service可以根据Annotation自动发布的基础设施都不存在了，而且架构师打算弃用JBoss，转向Tomcat，所以现在最简单的方案就是基于Axis自己写必须的东西了，还不是很清楚，要慢慢研究了。
去年到今年网上一个很热门的概念就是SOA（面向服务的架构），它真的是系统构建的最后的盛宴吗？日益复杂庞大的系统要求我们的各个部分都能够非常稳定的工作，在OO之后的组件，然后是构建之类的越来越大的封装，使得我们越来越想构建软件系统像构建楼房一样，但是建筑业经历了几千年的沉淀，其组件的结构和功能相对简单一些，而软件系统，其结构和功能千变万化，而且其需求的易变性往往是建筑不可比拟的，可以说需求随时在变化，使用大型的组件构建系统有它的好处：成熟、稳定，缺点是由于足够大，在可能不满足需求的情况下要进行修改几乎是不可能的；但是选用小的组件，需要学习的内容很多，没有足够的现成的功能，需要自己进行扩展，可能不够稳定，但是好处是在可控的范围内，遇到问题可能自己就可以解决。软件业总的趋势是组件越来越大可能是不可逆转的，但是决不是朝夕之间的事情，而且随着各种规范的出台，基于规范的系统构建将变得简单一些，不再需要对各种组件的不同特性分别学习，而是基于规范进行构建。在这个理想变成现实之前，我们还是需要自己来构建我们的系统，在开发的过程中我们可以有意识的将功能通用化，可以在其它的项目中公用或者给别人使用，apache基金会的做法是值得推荐的，在一些项目的开发过程中产生了很多更小的项目可以为其它的项目所用，jakarta的commons项目系列就是一个很好的例子，但是国内好像做得远远不够，最重要的是似乎并没有意识到这个问题，这个才是最可怕的。就我所参与过的一些项目而言就存在这个问题，而且很严重，每个人在遇到一个他不知道的功能时大部分情况下选择的是自己开发，而不是询问别人是否已经解决了，即使自己完成了，也仅仅是针对自己的问题，没有想到去通用化，即使做得比较通用，也不会写个文档或者邮件告诉别人如何用，在什么情况下用，而别人呢，可能也不大愿意用，这个实在是很多软件开发团队的最大的弊病：重复工作。我们首先应该从思想上解决这个问题，然后是从工具上解决，因为这样的共通功能太多了后如何查找需要的功能就是一个很大的问题。也许JR应该组织开发一个这样的知识管理系统？
© 2024 解惑
本主题由Anders Noren提供 — 向上 ↑