同样的war包在tomcat下可以，在websphere下就不行了

[JavaRevolution]

我是新手。
项目是基于商业软件FIPER做二次开发的。FIPER服务部署在Websphere6.0.23上，包含一些EJB的东西，我不懂。。
我自己开发一个war包，该war包服务器端的代码使用了FIPER 提供的API。开发过程中一直使用的Tomcat5.5来部署我的war包，都没有问题，但由于项目的需要，要将我的war包和FIPER一起部署到Websphere上。结果问题就出来了，在使用FIPER某个API的时候报错如下：
javax.naming.NameNotFoundException: Context: fiperserverNode03Cell/nodes/fiperserverNode03/servers/server1, name: AdminMgr: First component in name AdminMgr not found. Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0

FIPER软件除了提供包含API的jar包之外，还提供了一个websphere的资源文件夹，该文件夹好像是调用其API时需要的。因为之前我尝试过Application的开发，需要将它提供的websphere资源文件夹包含进我的工程才行。但项目实际开发的是Web程序，而且工程里不必包含它提供的websphere资源文件夹也能正常运行，而且在我使用websphere部署自己的war包之前都没有出问题，所以我一直没在意。现在不行了。。。。
那个资源文件夹里包含很多jar包和一些xml文件，属性文件等等。

总之，就是同样的war包在tomcat下可以，在websphere下就不行了，有一个websphere资源文件夹但我不知道是干什么的。
也不知道我的问题描述清楚没，不清楚的我再补充。哪位高手帮帮我，先谢过了！

[JavaRevolution]

没人知道吗。。。唉，着急啊

[JavaRevolution]

在websphereTools网站上搜到和这个对应的，但我看不大明白

Exception: org.omg.CosNaming.NamingContextPackage.NotFound
Cause: javax.naming.NameNotFoundException

Below is an example stack trace as found in an Application Severs SystemOut.log file where an application (EAR) has been installed with in correct JNDI mappings.

Caused by: javax.naming.NameNotFoundException: Context: myCell001/clusters/cluster001, name: MyConnectionFactory_ENV01: First component in name
MyConnectionFactory_ENV01 not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
at com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4754)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1911)
at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1866)
at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1556)
at com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory$1.run(IndirectJndiLookupObjectFactory.java:372)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory.getObjectInstanceExt(IndirectJndiLookupObjectFactory.java:221)
at com.ibm.ws.naming.util.IndirectJndiLookupObjectFactory.getObjectInstance(IndirectJndiLookupObjectFactory.java:149)
at com.ibm.ws.util.ResRefJndiLookupObjectFactory.getObjectInstance(ResRefJndiLookupObjectFactory.java:144)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:316)
at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:896)
... 59 more

Solution:
The EAR files Resource References or EJB Resource References have binding issues. Usually this means, that direct jndi look-up is being used but the application, or indirect JNDI has been used and the mapping is incorrect, meaning that the application has resources mapped to JNDI that might not exist. Each Resource Reference or EJB Reference definition in the EAR file needs to map to an actual Resource Reference ie A Connection Factory, Queue or MQConnnectionFactory and use the correct JNDI name of that Resource

[JavaRevolution]

我顶顶顶顶顶顶顶顶上去

[javarevolution1]

我是马甲，我是来结贴的-_-