I have same EAR deployed in JBoss EAP 6.4 in windows and linux env. I am getting below exception in windows but not in linux.
Caused by: java.lang.NoClassDefFoundError: com/bp/gp/addfilters/CMnAddQueryConverter
at com.bp.dw.sales.datacache.CMnDataCacheHelper.getDataSourceCriterion(CMnDataCacheHelper.java:649)
com.bp.dw.sales.datacache.CMnDataCacheHelper.applyFiltersToDataCache(CMnDataCacheHelper.java:429)
com.bp.dw.sales.datacache.CMnDataCacheHelper.applyFiltersToDataCache(CMnDataCacheHelper.java:407)
com.bp.dw.sales.datacache.CMnBaseDataCacheMgr.initiateDataCachePopulate(CMnBaseDataCacheMgr.java:211)
com.bp.dw.sales.datacache.CMnPopulateDataCacheCommand.execute(CMnPopulateDataCacheCommand.java:199)
at com.bp.gp.wb.CMnWorkbookPriceCommand.executeUnit(CMnWorkbookPriceCommand.java:76)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.spawnCache(CMnDataCachePoolMgr.java:628)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.processCache(CMnDataCachePoolMgr.java:571)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.processCache(CMnDataCachePoolMgr.java:537)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:466)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:461)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:456)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:451)
com.ac.gp.wb.CMnWorkbookWizardComp.actionFinishHook(CMnWorkbookWizardComp.java:367)
com.ui.wizard.CMnWizardComp$4.actionPerformed(CMnWizardComp.java:500)
com.ui.fw.CMnBaseWidgetComp.fireActionListeners(CMnBaseWidgetComp.java:699)
com.ui.fw.CMnBaseRequestComp.fireActionListeners(CMnBaseRequestComp.java:422)
com.ui.fw.CMnBaseWidgetComp$1.clientEvent(CMnBaseWidgetComp.java:92)
com.ui.fw.client.CMnFormClientEventDispatcher.dispatch(CMnFormClientEventDispatcher.java:97)
... 22 more
Caused by: java.lang.ClassNotFoundException: com.bp.gp.addfilters.CMnAddQueryConverter from [Module "deployment.pharma.ear.pharma.war:main" from Service Module Loader]
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
... 41 more
I have jaxb-api.jar, jaxb-impl.jar and jaxb-xjc.jar getting loaded from code but not from JBoss default modules as they are getting used in my code.
Any pointer for the possible cause of this exception?
Regards,
I had two folder with same name in different case and hence the issue.
My EAR had folder structure like:
com.bp.gp.addfilters and com.bp.gp.addFilters.
Looks like, JBoss uses underlying OS's search method to look for folder.
Linux search is case sensitive by default, hence it never gave this error.
Since windows search is case insensitive by default, it was always trying to search inside com.bp.gp.addFilters package whereas the class was present in com.bp.gp.addfilters package.
Related
I am new to the Modelica world and installed JModelica2.14 on win10 via the binary file provided from the offical webpage. From the console I call setenv.bat, start the 64bit python envrionment and import '.\install\Python_64'. However, running the example files already throws an error. The minimal code example throwing the error is provided below. I assume that the binaries do not have a bug without anyone mentioning it. It would be great if someone could give a hint about what I am missing. Thanks a lot!
import modelicacasadi_wrapper
modelicacasadi_wrapper.OptimicaOptionsWrapper()
RuntimeError Traceback (most recent call last)
<ipython-input-11-ce2bcdfa3f06> in <module>()
----> 1 modelicacasadi_wrapper.OptimicaOptionsWrapper()
C:\JModelica.org-2.14\install\Python_64\modelicacasadi_wrapper\modelicacasadi_wrapper.pyc in __init__(self, *args)
3472 __init__(ModelicaCasADi::OptimicaOptionsWrapper self, OptimicaOptionsWrapper other) -> OptimicaOptionsWrapper
3473 """
-> 3474 this = _modelicacasadi_wrapper.new_OptimicaOptionsWrapper(*args)
3475 try:
3476 self.this.append(this)
RuntimeError: java.lang.NoClassDefFoundError org/jmodelica/optimica/compiler/ModelicaCompiler
Caused by: java.lang.ClassNotFoundException: org.jmodelica.optimica.compiler.ModelicaCompiler
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
This function is only given in binary format compiled from c++ code. therefore, I can not change the function without recompiling the library (I already tried). To me it seems like the org.jmodelica.optimica.compiler.ModelicaCompiler should have been a org.jmodelica.optimica.compiler.OptimicaCompiler. This would mean that I have to install the package from source and I haven't been sucessful with that yet.
I still use JModelica 2.14 in Python 2 and then have installed virtual environment with Conda to create a Python 3 environment where I then run the FMUs with the latest PyFMI package in Python 3.10 and Jupyter notebook. It all works very fine, but as Imke Kreuger indicated you have MSL 3.2.2 build 3 and there has been development in the Modelica Standard Library since then.
During installation you are asked whether you want "Graybox OPC Automation wrapper" and I usually say "NO" there. You may have said "YES" though, right? See Chapter 2.2.1 in the User guide.
The JModelica installation actually provide you with two different compilers.
One is for standard Modelica brings as output an FMU of CS or ME type. The other compiler is for Modelica extended with Optimica and does not bring any FMU and you are bound to work in Python 2.
Tried to reproduce your error (with my installation without the "Graybox OPC..."). If I (in the Python 2 environment) literally do the two commands, I get "Press any key to continue...." and when I press key the IPython window collapse.
However if you skip the two brackets at the end of the second command, then it is accepted!
If you write a question mark at the end you get information about what arguments you should have.
If you describe better what you want to do, we likely can help you better.
Note, it seems you want to use Optimica and that is an extension of Modelica that is only partially supported by OpenModelica, what I understand. The Optimica extension is well integrated in JModelica and originated in this context. For "ordinary" Modelica use I do not think you need to use this wrapper.
Current jetty version is 9.4.6, I tried to upgrade 9.4.44, I got the error. Could you please help me?
WebAppContext:554 -Failed startup of context o.e.j.w.WebAppContext#163f1cd{passwd-change,/passwd-change,file:///run/opt/corp/gsec/7.0.0/java-service/gsec-jetty-base/temp/jetty-gsec-2443-passwd-change.war-_passwd-change-any-6326268666909012254.dir/webapp/,UNAVAILABLE}{/passwd-change.war}
Caused by: java.lang.IllegalAccessError: tried to access method org.eclipse.jetty.server.handler.ContextHandler$StaticContext.createInstance(Ljava/lang/Class;)Ljava/lang/Object; from class jetty.webapp.StandardDescriptorProcessor
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.newListenerInstance(StandardDescriptorProcessor.java:1945) ~[apacheds-service-2.0.0-M24.jar:2.0.0-M24]
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.visitListener(StandardDescriptorProcessor.java:1900) ~[apacheds-service-2.0.0-M24.jar:2.0.0-M24]
The jetty files in your apacheds-service-2.0.0-M24.jar needs to be upgraded as well.
List the contents of the apacheds-service-2.0.0-M24.jar file and you'll see classes in the org.eclipse.jetty. namespace.
Those are conflicting with your efforts to upgrade Jetty via the jetty-distribution zip.
I had a different setup that triggered a similar stacktrace: using cargo-maven2-plugin 16.1 in a spring 5 project, mvn cargo:run would fail because of a conflict with javafx.base-11.0.0-SNAPSHOT.jar files.
Upgrading to cargo-maven3-plugin 1.9.9 fixed the matter.
I'd encourage who ever uses cargo-maven2-plugin to migrate to cargo-maven3-plugin as the doc states:
Please be aware that the Maven 2 / Maven 3 plugin of Codehaus Cargo has been retired with our version 1.9.0 and has been superseded by a Maven 3 only plugin.
I have deleted the earlier class and .ear-files, cleaned the workspace, compiled the code with JavaSE 1.6, set the system library to 1.6 then compiled and created the .ear. I am getting this error when I have installed the ear on server and try to open with url:
WebApp E [Servlet Error]-[Bad version number in .class file]: java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:577)
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:529)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:403)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader._loadClass(JSPExtensionClassLoader.java:103)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.loadClass(JSPExtensionClassLoader.java:70)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.loadClass(JSPExtensionClassLoader.java:52)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
This error happens when your VM has another version (a lesser version) than the compiled class files.
Could it be that your server still run with java 1.5?
I have a Django application using django-mssql to communicate w/ SQL Server.
This works just fine in the dev server (runserver) but under Apache/mod-wsgi, I get a error related to it trying to find a .dll which does exist:
Exception Type: ImportError
Exception Value: No system module 'pywintypes' (pywintypes27.dll)
Exception Location: C:\Python27\lib\site-packages\win32\lib\pywintypes.py in __import_pywin32_system_module__, line 98
Python Executable: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\bin\httpd.exe
I used ActivePython2.7.2, mod_wsgi, pywin32 Build 216 and Django1.3.1, all of 32 bits
pywintypes27.dll exists in C:\Windows\SysWOW64 instead of C:\Windows\System32 as expected in my 64 bit windows 7
Thanks in advance
This is the same question as django-mssql not working in Apache w/ mod-wsgi, but works fine in dev server but that answer didn't help me cause I have installed 32 bits pywin32, I am new to stackoverflow and hope it is right to ask as a new question rather than hijack people's thread.
Move files:
pythoncom27.dll
pythoncomloader27.dll
pywintypes27.dll
from "C:\Python27\Lib\site-packages\pywin32_system32"
to
"C:\Python27"
Hope it helps.
Install pywin32-218.win32-py2.7.exe in machines of 32 or 64 bits.
For those who installed pywin32 via pip : check that you have done it outside a virtualenv.
If you've done it inside virtualenv, we can get this kind of error.
Prefer binarie installation : See Mark Amery response here
I am new in jetty. I am trying to run Jetty with IKVM. However, it throws exception. I am not sure what should I do.
alex#AlexUbuntu:/usr/share/jetty$ ikvm -jar start.jar
5 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:
at org.mortbay.start.Main.invokeMain(Main.java:179)
at org.mortbay.start.Main.start(Main.java:508)
at org.mortbay.start.Main.start(Main.java:439)
at org.mortbay.start.Main.main(Main.java:99)
Caused by: cli.System.TypeLoadException: Could not load type 'org.apache.xerces.util.NamespaceSupport' from assembly 'ikvm_dynamic_assembly__40326550, Version=2011.611.1039.16726, Culture=neutral, PublicKeyToken=null'.
at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.<init>(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:517)
at java.lang.Class.newInstance0(Class.java:333)
at java.lang.Class.newInstance(Class.java:320)
at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:68)
at org.mortbay.xml.XmlConfiguration.initParser(XmlConfiguration.java)
at org.mortbay.xml.XmlConfiguration.<init>(XmlConfiguration.java:105)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:958)
... 5 more
It seems that I need to install some external libraries in order to make it works. But what should I need to install.
The environment is fresh and clean:
Ubuntu 11.04
IKVM 0.40.0.1
Java 1.6.0_22
Mono 2.6.7
Update on 28 June 2010
I think I make it works. But I haven't try loading .NET classes in jetty. By the way, I used a dirty method that I replaced /usr/bin/java and /usr/lib/jvm/default-jvm/java with ikvm.exe. So everytime when I type java that actually is IKVM.
I will try to load .NET classes in jetty. But I am not familiar with jetty so I may take sometime.
Update on 1 July 2010
I have tried to load a .NET class. However, finally I got an error message.
HTTP ERROR 500
Problem accessing /hello/servlet. Reason:
ikvmstub generated stubs can only be used on IKVM.NET
Caused by:
java.lang.UnsatisfiedLinkError: ikvmstub generated stubs can only be used on IKVM.NET
at cli.CSharpClass.<init>(Unknown Source)
at HelloServlet.doPost(HelloServlet.java:28)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Can you run Jetty with 'java -jar start.jar'?
I suspect you need at least a few base JAR files for jetty even if it's classloader dynamically loads everything that is needed. It looks like it is failing in the log initialization.
Add the xerces JAR file to the classpath when running IKVM.
ikvm -cp .:xerces.jar -jar startup.jar
Update
I just looked through jetty.sh and there are a few things the script file sets up. You'll need to go through that file and determine what you need out of it, or replace all the instances of java with ikvm and be aware that Jetty also uses tools.jar
The jar files that you generate with ikvmstub are only for the java compiler and not for the runtime. The java compiler can nor work with .NET dlls. For the runtime you need to use the dlls directly.
We use the jetty without problems with IKVM but we use a newer version 0.46. The simplest is you build all jar files in one step with a shared classloader. See the ikvm wiki for details.