I am running OSGi framework through CLI by running command as below:
java -jar org.eclipse.osgi_3.6.2.R36x_v20110210.jar -console
My plugins run fine but while running my plugin that requires JAXB packages of system library (JavaSE1.6.xx) to parse xml file I am getting exception trace as below:
Exception in thread "DummyProgram" java.lang.ExceptionInInitializerError
at javax.xml.bind.DatatypeConverter.<clinit>(DatatypeConverter.java:78)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:262)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:260)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:260)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1100)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:143)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:202)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:376)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
at com.entities.conf.JAXBMTSConfig.unmarshalApps(JAXBMTSConfig.java:113)
20 more..
Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be cast to javax.xml.datatype.DatatypeFactory
at javax.xml.datatype.DatatypeFactory.newInstance(Unknown Source)
at javax.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:742)
I think there is a conflict with different versions of javax.xml.bind.* packages. I guess they are exported by the System library and a xerces (?) jar?
So you'll need to find out which bundle exports those packages, and resolve the conflict.
regards, Frank
A class-cast exception in OSGi is typically caused by the fact, that every bundle has it's own class loader.
It is possible that two bundles load the same class from other sources (because they are exported twice). Because every bundle has its own class loader, they are loaded by two different class loaders, so java doesn't accept this as the same class.
There are two workarounds:
- check if the class is exported twice. If this is the case, try to solve this by exporting it only once.
This may not be possible, because bundle a may need version 1.4, and bundle b 1.7.
if this is the case, import the exported class in the bundle.
So, for example:
Bundle A exports xyz-1.4 and imports xyz-1.4
Bundle B exports xyz-1.7 and imports xyz-1.7
Now the framework can decide which class is used. If bundle a runs alone, 1.4 will be used.
Otherwise, Bundle A and B are needed by a Bundle C, 1.7 will be used (in case that it is downward compatible to 1.4)
Related
recently i found this stackoverflow page enter link description here "JavaFx:Export TableView to excel with name of columns", i run this code and i got the following issue
import org.apache.poi.ss.usermodel.Row;
^
TableViewExample.java:13: error: package org.apache.poi.ss.usermodel does not exist
import org.apache.poi.ss.usermodel.Sheet;
^
TableViewExample.java:14: error: package org.apache.poi.ss.usermodel does not exist
import org.apache.poi.ss.usermodel.Workbook;
^
TableViewExample.java:42: error: cannot find symbol
Workbook workbook = new HSSFWorkbook();
^
symbol: class Workbook
location: class TableViewExample
TableViewExample.java:43: error: cannot find symbol
Sheet spreadsheet = workbook.createSheet("sample");
^
symbol: class Sheet
location: class TableViewExample
TableViewExample.java:45: error: cannot find symbol
Row row = spreadsheet.createRow(0);
^
symbol: class Row
location: class TableViewExample
6 errors
According to what is described there, a library named Apache poi is being used.
i used this library in order to run this code poi-3.0.2.jar in this way
javac -classpath ".:poi-3.0.2.jar" TableViewExample.java
using command line in linux ubuntu, i compiled archives.java before with great success using command line.
Other persons have used jakarta-poi-3.0.2.jar but this .jar file library does not exist anymore and i used poi-3.0.2.jar instead.
Now i used the new poi-5.1.0.jar and i got the following error message
library Exception in Application start method
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:389)
at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:328)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:767)
Caused by: java.lang.RuntimeException: Exception in Application start method
at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:917)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$1(LauncherImpl.java:182)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/io/output/UnsynchronizedByteArrayOutputStream
at TableViewExample.start(TableViewExample.java:42)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$8(LauncherImpl.java:863)
at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$7(PlatformImpl.java:326)
at com.sun.javafx.application.PlatformImpl.lambda$null$5(PlatformImpl.java:295)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$6(PlatformImpl.java:294)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at com.sun.glass.ui.gtk.GtkApplication.lambda$null$10(GtkApplication.java:245)
... 1 more
Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 10 more
Related to "java.lang.ClassNotFoundException: org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream"
any information about how to solve this issue and make this piece of code work?
Thank you in advance
The most recent apache poi library is 5.1.0, I do not recommend using old versions. The download is here, though I don't recommend directly downloading libraries either, instead add them as dependencies using a build tool like maven or gradle.
When you look at the project file for poi, it has lots of dependencies, so simply adding the poi jar to the classpath is not enough, instead, let your build tool work it out.
Modern JavaFX distributions (which you should be using) are modular, so you need to either have a module-info file or command-line arguments for the module path and modules added (which you don't have in your example).
If you have a module-info, then you may need to require modules for poi to work (I don't know the command for that).
It may be easier to run without a module-info as long as you have correct module specifications for JavaFX on your command line (as defined by the openjfx.io getting started doc for non-modular applications).
FAQ
i am thinking now in another solutions in how to convert a JavaFX tableview to excel
I agree, don’t use poi, instead write the data to a csv file. You can search for solutions on how to write data in csv format using Java. That is what I would do.
now i implemented the new poi library poi-5.1.0.jar and i got the error message
java.lang.ClassNotFoundException: org.apache.commons.io.output.UnsynchronizedByteArrayOutputStream
During execution, you are still missing the required transitive dependencies required to run the application.
If you use poi, one way to get the required dependencies is to ask maven to copy them to a lib directory:
Make Maven to copy dependencies into target/lib
then when you execute your app jar, have the lib directory for your app on your classpath and the JavaFX SDK lib directory on your module path.
i can create .csv files but unfortunately client ask .xls files
POI can create the xls files directly, or you could run an external tool to do the csv to xls conversion:
Convert .CSV to .XLSX using command line
The tool could be included in your application packaging and installation and invoked from java:
https://www.baeldung.com/run-shell-command-in-java
I'm using Eclipse 4.5 with the Groovy-Eclipse 2.9.2/4.5 plugin which I thought was supposed to have the Groovy 2.5 compiler. However, it didn't have any picocli support so I added the groovy-cli-picocli-2.5.2-indy.jar to my classpath and was able to compile. However #2, when trying to run the script via Eclipse I get:
java.lang.ClassNotFoundException: picocli.CommandLine$ParameterException
It looks like groovy-cli-picocli-2.5.2-indy.jar does not have CommandLine class at all.
I would just throw jars at this from the fullblown picocli distribution but I'm under the impression they all have to somehow wrap nicely into Eclipse Groovy library via groovy.cli.picocli.CliBuilder.
Is my Groovy 2.5.2 missing this or am I somehow missing the boat on how it's supposed to work because picocli is not working for me in this configuration. Thanks!
You are correct: groovy-cli-picocli-2.5.2.jar (and groovy-cli-picocli-2.5.2-indy.jar) do not contain the picocli classes.
You need to add the picocli jar to the classpath.
If you use Maven, the groovy-all POM should include all dependencies.
(My original answer mentioned picocli classes that are shaded into the groovy-2.5.x.jar under the groovyjarjarpicocli package but these are intended for use internally by Groovy and not meant to be used by applications.)
When JodaTime v. 2.5 library included into WAR file deployment fails in GF 5.0 with following error. It seems problem lies in hibernate-validator. FutureValidatorForReadableInstant is not loaded as ReadableInstant is not loaded by hibernate-validator bundle in GF5.0 while it is working GF 4.1.2.
Exception while loading the app : CDI deployment failure:Errornstantiating :org.hibernate.validator.cdi.internal.ValidationExtension
Caused by: java.lang.TypeNotPresentException: Type org.joda.time.ReadableInstant not present
at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.generics.repository.ClassRepository.getSuperclass(ClassRepository.java:90)
at java.lang.Class.getGenericSuperclass(Class.java:777)
at org.hibernate.validator.internal.util.TypeHelper.resolveTypeForClassAndHierarchy(TypeHelper.java:386)
at org.hibernate.validator.internal.util.TypeHelper.resolveTypes(TypeHelper.java:351)
at org.hibernate.validator.internal.util.TypeHelper.extractType(TypeHelper.java:327)
at org.hibernate.validator.internal.engine.constraintvalidation.ClassBasedValidatorDescriptor.(ClassBasedValidatorDescriptor.java:39)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorDescriptor.forClass(ConstraintValidatorDescriptor.java:49)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at org.hibernate.validator.internal.metadata.core.ConstraintHelper.putConstraints(ConstraintHelper.java:686)
at org.hibernate.validator.internal.metadata.core.ConstraintHelper.(ConstraintHelper.java:386)
at org.hibernate.validator.internal.engine.ValidatorFactoryImpl.(ValidatorFactoryImpl.java:155)
at org.hibernate.validator.HibernateValidator.buildValidatorFactory(HibernateValidator.java:38)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:322)
at org.hibernate.validator.cdi.internal.ValidationExtension.(ValidationExtension.java:116)
... 78 more
I think it might be a bug in Hibernate Validator. I created https://hibernate.atlassian.net/browse/HV-1490 to track this issue.
When we try to detect Joda Time in ConstraintHelper, we use the LoadClass mechanism which might fall back to using the Thread Context class loader if it does not find the class within the ConstraintHelper/HV CL.
In your case, I think the ReadableInstant class is accessible in the TCCL but not in the HV CL.
When we try to get the type from the ConstraintValidator, we only have the HV CL and so it fails to find the class.
So I think we should fix that in HV but I'm not sure it will help you as, once fixed, the Joda Time constraint validators won't be enabled anyway.
What might not help is that the OSGi bundle of HV looks a bit outdated regarding the Joda Time dependency (https://github.com/javaee/glassfish/blob/master/nucleus/packager/external/bean-validator/pom.xml#L124). I'll see with the GlassFish team if they can update it.
I created a PR https://github.com/hibernate/hibernate-validator/pull/857 to fix the issue on our side. You might be able to get this branch, build it (it's just a mvn clean install) and upgrade the jars in your GlassFish. As mentioned above, it won't allow you to use constraints on Joda Time types but, at least, you should be able to start your app. I'm interested in your feedback if you can try that.
About the GF part, I emailed the GF team and will let you know if there is some progress on that front.
Update: GF 5.0.1 will contain a fix for this issue. If you upgrade your current GF to HV 6.0.3.Final we released today, you should be able to start your app (but won't be able to put constraints on Joda Time types, this would have to wait for GF 5.0.1).
I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.
The important bit of the stack trace is this:
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
Even if I include a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).
I am using Gradle 4.1. Is there any way to restrict the scope of a
JDK provided module?
As you have correctly analyzed, the package org.w3c.dom.ls is present in the platform module java.xml. Any class on the class path that is in the same package will be ignored. That's called a split package and several fixes exist - the following two might help you.
Patch java.xml
You can add the classes of the Xerxes JAR to the java.xml module with --patch-module:
java --patch-module java.xml=xerxes-4.0.0.jar ...
I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.
Upgrade java.xml
Another hope is to replace java.xml with the upgrade module path:
The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).
You face two problems:
the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.
I work with Android Studio 2.1.1. I am writing a class which extends LinearLayout. This class has a string attribute which I try to parse with basic android JSON lib in the class constructor. The code seems fine as it compiles and installs to the device. But Android Studio cannot find the class in the Preview (see screenshot below).
What is the solution of problem?
How do I set 'JSON lib' of Android Studio Preview?
Android Studio Screenshot
Android Studio error stack:
java.lang.ClassNotFoundException: org.json.JSONException
at org.jetbrains.android.uipreview.ModuleClassLoader.load(ModuleClassLoader.java:154)
at com.android.tools.idea.rendering.RenderClassLoader.findClass(RenderClassLoader.java:52)
at org.jetbrains.android.uipreview.ModuleClassLoader.findClass(ModuleClassLoader.java:92)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2483)
at java.lang.Class.getConstructor0(Class.java:2793)
at java.lang.Class.getConstructor(Class.java:1708)
at org.jetbrains.android.uipreview.ViewLoader.createNewInstance(ViewLoader.java:396)
at ...
Using Android Studio 2.2.3, I had the same problem, and sky's workaround worked for me, but I looked deeper and discovered the ClassNotFoundException was caused specifically by a reference to JSONException in code not ever executed in the view draw code needed for the layout preview. Interestingly, non executed references to JSONObject do not cause a ClassNotFoundException, but apparently the compiler wants to load the JSONException class regardless.
My solution was to catch Exception instead of JSONException in my code (which would be unaffected by the change). I decided this was preferable to adding the otherwise unnecessary library.
I did found only the WORKAROUND for this kind of issue. I did download 'json-20160212.jar' from maven repo. Then placed it to project's root directory (or other directory you like), and did add the dependency in project's build.gradle:
dependencies {
provided files('json-20160212.jar')
}
I'm using 'provided' scope to avoid json library been compiled with my project, but have an ability to 'preview' my layout without ClassNotFoundException.