I'm in the process of upgrading a Vaadin Flow application from Vaadin 14 to Vaadin 22. I'm using Gradle 6.9.1 to build the application. When I run the application in Eclipse, I get warnings and errors in the logs identical to those documented in issue 11982. According to this issue, this initial warning about the vaadin-dev-server dependency is the most relevant message:
WARN [] [VaadinServletService] [qtp819245704-14] no DevModeHandlerManager implementation found but dev server enabled. Include the com.vaadin.vaadin-dev-server dependency.
I have included the dependency in my build.gradle file. Here are the dependencies that are relevant to Vaadin:
dependencies {
implementation "com.vaadin:vaadin-core:22.+"
implementation "com.vaadin:vaadin-dev-server:9.0.0"
}
I can see vaadin-dev-server-9.0.0.jar in my Referenced Libraries within Eclipse along with the other Vaadin .jar files. All of them are located in my Gradle cache.
Am I missing something, or is there anything I can do to resolve this issue? Let me know if there's any more information I can provide.
Edit: I'm now trying to upgrade the application to Vaadin 23 instead and I'm experiencing the same issue. I'm also getting the webpack error referenced in this question. If it helps, I'm running the project locally using embedded Jetty and I'm manually instantiating and invoking the initializers used by Vaadin as described in this answer.
Apache OfBiz is not installing correctly, and fails to compile in the command prompt.
After creating the system variable JAVA_HOME to C:\Program Files\Java\jdk1.8.0_40, and editing "Path" to be C:\Program Files (x86)\Java\jre7\bin;C:\apache-ant-1.9.4\bin, I downloaded OfBiz 13.07.01 to my C:\ folder and unzipped it there. In the command prompt, I typed the following:
C:\Users\CalS>cd C:\apache-ofbiz-13.07.01
C:\apache-ofbiz-13.07.01>ant load-seed
Then, after about 50 seconds, I get this:
BUILD FAILED
C:\apache-ofbiz-13.07.01\build.xml:229: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:248: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:39: the following error occurred while executing this line:
C:\apache-ofbiz-13.07.01\build.xml:91: compile failed; see the compiler error output for details.
Please note it has been years since I dealt with DOS, so I do not know how to access the error output.
This is after I get a few dozen errors like:
[javac16] class file for org.ofbiz.widget.ContentWorkerInterfaice not found
and
[javac16] warning: [options] bootstrap class path not set in conjunctions with -source 1.6
Under 'classes'.
Misc. I have tried 'ant run-install' and 'load-demo' commands without avail. I've followed step-by-step tutorials, but very likely missed something. Please let me know what I can do to fix this and run this program successfully. Thanks!
Please have a look at the following Apache Jira Tickets for OFBiz where your problem is addressed and was fixed, so that OFBiz could be build with java 1.8.
The build errors occur due to missing fileset entries in the build.xml for some applications (party, workeffort, product, order, ebay, and pos), see: OFBIZ-5835
A fix is available in related ticket: OFBIZ-6079
There was another bug in the current release branches (checked 14.12.01, 12.04.06, 13.07.02) that I fixed last week. The fix is already committed to the branches.
See: OFBIZ-6252
You have to compile/run with the same Java version.
Seems you have some inconsistencies: JAVA_HOME ist 1.8, Path is set to jre 7 and the warning states it is using an 1.6 compiler.
With the 13.07. Release, using Java 1.7 or 1.8 is recommended and supported.
Alright, so it looks like Apache OFBiz and Java JDK 1.8.XX don't get along. I found help on another forum that confirmed the discrepancy in compatibility between OFBiz 13.07.01/Apache ant 1.9.4 and JDK 1.8.XX. This will cause the compiling of the Apache Ant to fail (which seems to run off of JDK 1.6).
I remedied the problem by downloading the archived JDK 1.7.0_67 from Oracle, re-mapping the System Variables accordingly, and re-initializing the Command Prompt.
It works now! Thank you all for your contributions.
Though solved, let me add something important. JDK version is not always an issue in such errors. Ofbiz v13.X.X works well on JDK 1.7 and above. The error shown is a peculiar issue with Ofbiz v13.07.01 dist.
As Martin pointed out, one need to add widget jars in the classpath of order, party, product & workeffort. Add the below line
<fileset dir="../../framework/widget/build/lib" includes="*.jar"/>
in build.xml of order, party, product & workeffort under applications directory.
Using the requestContext demo example in my system
http://www.primefaces.org/showcase-labs/ui/requestContext.jsf
I am getting the following error
Caused by: java.lang.ClassCastException: org.primefaces.context.DefaultRequestContext cannot be cast to org.primefaces.context.RequestContext
at org.primefaces.context.RequestContext.getCurrentInstance(RequestContext.java:38) [primefaces-3.4.1.jar:]
the error occur when the java command running
RequestContext context = RequestContext.getCurrentInstance();
Using primefaces-3.4.1 under jboss seam 2.3.0.Final with Jboss AS 7.1
Amir
You've multiple different versioned PrimeFaces JAR files in your webapp's runtime classpath. For example, one PrimeFaces 3.3 and another PrimeFaces 3.4.1. They're conflicting with each other.
Cleanup the webapp's runtime classpath so that only the most recent version remains and this problem should disappear. Paths which are by default covered by the webapp's runtime classpath are the webapp's own /WEB-INF/lib folder, server's and/or JRE's own /lib and /lib/ext folders.
Update: another, actually more rare, cause is that you've multiple PrimeFaces JAR files of the same version which are loaded by different classloaders. The getClass() on the both classes would then never match the == check. You'd need to remove one of both.
I have a Grails app that uses the Rest plugin
When I drop my war into my JBoss deploy directory and start it up, the deployment of the app fails because of the following error:
2012-11-01 15:48:33,931 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] XML error parsing: context.xml
org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
I believe this refers to the grails app containing a version on xercesImpl as well as JBoss having it's own. We usually rectify this by removing xercesImpl from our apps or setting them to "provided" scope.
I'm trying to figure out how I fix this deploy issue. I'm assuming I have to edit the BuildConfig.groovy script and tell it, somehow, to exclude xerces right? How would I do that for this plugin? If this were a "dependency" that appears to be easy to specify the exclusions. But I'm not sure how to do it for this plugin...
any ideas?
In your BuildConfig.groovy add this:
inherits('global') {
excludes 'serializer'
}
It turns out, doing the following in the plugin section of my BuildConfig.groovy did the trick after all...
compile(":rest:0.7"){
excludes "xercesImpl"
}
Because of memory constraint i am trying to build a grails app with smaller memory footprint. I build the war with this argument "--nojars". I created a war file without all the jar and when i deploy within the glassfish i encounter this error
Exception while loading the app : java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: org.codehaus.groovy.grails.web.util.Log4jConfigListener
It seems like the application fail to find where is the jar file.
I had already indicates the path to the library before deploying the application in glassfish.
did i miss out somethinng?
It is commonly recommended to use GlassFish's Common Classloader. That means putting the shared JARS into the $domain-dir/lib folder (but not into a subfolder of that).
You're probably trying to use the Application Classloader with the asadmin deploy --libraries command. This is more complicated and error-prone. If you don't need different versions of the same JARs with different web applications, you should definitely go for the Common Classloader as specified above.
Also see The Classloader Hierarchy for a reference.
EDIT Updated as per the questioner's comment:
The domain/domain1/lib folder definitely works (I've tested that). To validate that, put log4j.jar into that folder and add a test.jsp to domain1/applications/$applicationName, that just contains:
<% out.println(
org.apache.log4j.Logger.getLogger(this.getClass())); %>
If that works but your other code does not, there may be another point to consider: Are you using Log4J's Logger.getLogger(..) or Apache Commons' LogFactory.getInstance(..) in your code?
See the article Taxonomy of class loader problems encountered when using Jakarta Commons Logging for related issues. - I'd also like to advise you to post your complete stacktrace.