作者：沉醉不知归路1222 | 来源：互联网 | 2023-08-06 13:59
在c++中string类和vector类几乎是用的最多的两个标准库类，现对他们进行归纳比较如下：1.定义和初始化共同有的初始化类是这些strings1;vectorv1;默
问题背景：
用jenkins在持续构建：在从svn迁出代码，build成功，把jar/war上传私服nexus后，将项目直接部署到应用服务器中，曾经做过直接部署到tomcat中没有问题，这次需要部署到jboss中，我这里使用的是jenkins的一个插件Deploy to container Plugin，用它将打好的war部署到jboss5中，报错了。
错误：
org.codehaus.cargo.container.ContainerException: Failed to create deployer with implementation class org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer for the parameters (container [id = [jboss5x]], deployer type [remote]).
省略好多句
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.codehaus.cargo.generic.deployer.DefaultDeployerFactory.createInstance(DefaultDeployerFactory.java:206)
at org.codehaus.cargo.generic.spi.AbstractGenericHintFactory.createImplementation(AbstractGenericHintFactory.java:153)
... 19 more
Caused by: org.codehaus.cargo.util.CargoException: Cannot locate the JBoss deployer class! Make sure the jboss-deployer for your
JBoss version as well as all required JBoss JARs are in CARGO‘s classpath.
More information on: http://cargo.codehaus.org/JBoss&＃43;Remote&＃43;Deployer
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.(JBoss5xRemoteDeployer.java:91)
... 25 more
Caused by: java.lang.ClassNotFoundException: org.codehaus.cargo.tools.jboss.JBossDeployer
它的意思是部署到远程jboss出错了，错误是因为在CARGO的classpath下找不到 org.codehaus.cargo.tools.jboss.JBossDeployer
1、我的第一个想法就是，我配置deploy这个插件的时候出错了，导致它找的路径不对，这个时候我并没有考虑插件本身的问题，然后我找到jenkins wiki，找到deploy这个插件，看了它的介绍，想借助官方文档解决问题，了解到它是通过cargo调用jboss提供的接口将项目部署到jboss deploy下，但发现并没有使用说明和使用示例，无果。
2、然后在google搜寻jenkins deploy jboss 5.x等关键词，无果，有很多部署到tomcat的示例，也有部署到jboss 4和5.1的简单示例，但都不完整。
3、我又回去重新看了一下错误信息，这么一句引起了我的注意More information on: http://cargo.codehaus.org/JBoss&＃43;Remote&＃43;Deployer
在这里，我发现
JBoss 5.0.x, 5.1.x, 6.0.x and 6.1.x
Starting from JBoss 5.x, JBoss has a Deployment Manager that can be used for deploying things on the JBoss server. If you really want to know how it works under the hood, you can read about this feature on the JBoss Website. If you only want to remotely deploy
applications using CARGO to your JBoss server, you can of course ignore that document.
To connect to the JBoss Deployment Manager, CARGO uses JBoss‘ JMX RMI port; and that‘s what makes things get a bit complicated. For the connection to succeed, the following JARs need to be in the container classpath or in the current Java Thread‘s context classloader:
JBoss deployment manager JARs
JBoss remoting client JARs
Here is an example code for the users of the Java API:
这是介绍如何用cargo部署jars到jboss的，但我在jenkins中面向的是deploy Plugin，并不是cargo，所以这个方法还是不可行。
4、再回去从错误信息找解决方案，想到，既然cargo的classpath下缺少org.codehaus.cargo.tools.jboss.JBossDeployer，那么我直接找到这个jar拷贝过去，会不会起作用呢？于是我打开nexus，找到这个jar，下载，然后放到了deploy Plugin的lib下，重新构建，不幸地是，又报了另一个错误：
Caused by: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
省略很多句
... 24 more
javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]
用过jndi，或者ejb，或者使用jboss的朋友，肯定对这个错误非常熟悉，它缺少jboss client下的jar，如果我jenkins 部署在jboss中，我想容器会提供这些class，但现在不是，我必须把这些jar也放到cargo的classpath下，担心少拷贝jar，我把jboss client 下的jar全部拖了过去，重新构建，依然是相同的错误，但错误依旧，我想了想，两方面原因：1、我找到的目录并非cargo的classpath，2、类加载机制导致这些jar并没有加载。
5、我又从jenkins wiki找它的类加载机制，或者它是怎么初始化的，无果。放弃这个办法。
这时候我已经从下午2点坐到了5点多，抓狂了……
6、死马当活马医，不管了，直接将错误信息，复制到google中搜索，幸运地是，我竟然搜到了有人跟我遇到形同的错误，一个是在jenkins user论坛上，一个是在jenkins wiki deploy Plugin 目录下的评论，描述如下：
Gowtham An says:
Hi Everyone, I am using deploy plugin to deploy a file in JBOSS server but it sh...
Hi Everyone,
I am using deploy plugin to deploy a file in JBOSS server but it shows error and fails my entire build.
Do anyone has suggestion to configure the plugin? I have attached my configuration screenshot.
Any suggestion or replies ASAP is appreciated..
错误描述和我的一样
…………
我大喜过望，接着往下看，然后就是无尽地失望，无尽地失望，他提的这个问题没有人回复，竟然没有人回复！！
7、这个时候已经7点了，&＃30524;看我快要放弃了，在google上继续浏览，我发现了有人在构建结束后，用shell部署到远程linux的jboss中，既然shell可以，那么windows下是不是bat脚本也可以？我又看到了曙光。
我在jenkins构建结束后的选项中，的确发现了一个执行windows脚本，试了一个简单的输出语句，竟然成功执行了，那么，如果我直接写一个bat脚本，搜索到打好的jar，直接cp到jboss deploy，不就成了，于是果断放弃使用插件，改用自定义脚本。想到小崔（我的好伙伴）前些天写了好多关于jboss的bat脚本，直接电话call hime ，在他的帮助下，我迅速熟悉了bat语法，完成了这个脚本，而且我们一起做了优化，顺利解决了上述问题。
看看表8点40，这天我休假，如果解决不了这个问题，可想我的假期该多么沮丧，还好，还好，还好解决了，可以睡安稳了。
后来想了想，自己这么写自定义脚本，反而更灵活了，如果使用插件，在jar，war或者ear特别大的情况下，可能会造成jvm内存溢出，如果写bat，这个问题就轻松克服了，因为自定义，想怎么改怎么改，想怎么部署就怎么部署，其他优缺点还得在用的过程中发掘。
从我解决问题的过程中，不难看出，我也学到了很多东西，增加了解决问题的经验，锻炼了思路，复习了以前的东西，学到了新的东西，开阔了&＃30524;界等等。
不禁感慨一句：遇到问题，解决问题的过程，就是我们进步的过程。
c++中string类和vector类比较,布布扣,bubuko.com
京公网安备 11010802041100号