I have the following Jetty config:
<webAppConfig>
<defaultsDescriptor>${project.basedir}/configuration/webdefaults.xml</defaultsDescriptor>
<contextPath>/app</contextPath>
<baseResource implementation="org.eclipse.jetty.util.resource.ResourceCollection">
<resourcesAsCSV>${project.basedir}/src/main/webapp,/external/dir,/another/dir</resourcesAsCSV>
</baseResource>
</webAppConfig>
Now, both in my src/main/webapp and in /external/dir, I have a directory called static, and resources from both are accessible through URL /app/static just fine. Yet, in /another/dir, I have a directory that is called special-static and for some reason, resources in it are not accessible (or at least not using URL /app/special-static).
Any idea what I might be doing wrong?
The xml entry ...
<resourcesAsCSV>dir1,dir2,dir3</resourcesAsCSV>
Takes [C]omma [S]eparated [V]alues, use "," not ";" in your configuration.
What version do you use?
With version 8 or 9, I would do something like:
<webAppConfig>
...
<resourceBases>
<resourceBase>${project.basedir}/src/main/webapp</resourceBase>
<resourceBase>/external/dir</resourceBase>
<resourceBase>/another/dir</resourceBase>
</resourceBases>
</webAppConfig>
If you are using an outdated version (6 or 7), I encourage you to upgrade to the latest version 8.
Related
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 installed php7.0.15/apache2.4.25/phpMyAdmin 4.6.5.2 via xampp, but it turns out that the extensions xsl and intl are missing (need them to run Magento2).
I'm using Windows 8.1.
Both files php_xsl.dll and php_intl.dll exist in xampp/php/ext and I tried deleting the related ";" from extension=.. from in php.ini,
re-saving the php.ini and restarting apache server;
also copied in apache/bin folder the icu*.dll files from php;
BUT no success with that: still missing with magento2 Readiness Check.
Have any advise?
I have two suggestions for you---
No.1
Are you restarting the apache as administrator as I forget to do that most of the time.
No.2
Check your environment variable path. Did you set it properly.
Hope this can help!
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.
FAILED for project:
com.tenkinfo:b2g:war:1.1-SNAPSHOT
Reason:
/home/nrao/workspace15/mapnsav/src/main/java/com/tenkinfo/mapnsav/search/facade/ResourceServiceImpl.java:[5,-1] cannot access javax.ws.rs.core.UriBuilder
bad class file: /home/nrao/.m2/repository/com/sun/jersey/jersey-core/1.5/jersey-core-1.5.jar(javax/ws/rs/core/UriBuilder.class)
class file has wrong version 50.0, should be 49.0
That means you're using a Java version 5 compiler, but some of your class files have been compiled with Java 6. To work with Java 6 class files, you must use a Java 6 compiler. You probably have both installed on your machine, but either 1.5 is first on your PATH, or Maven is configured to use it.
I have a really simple web service which works fine in jetty 6:
java -Djetty.class.path=/path/to/webservices-rt.jar -jar start.jar
but the same commandline for jetty 7 fails with a ClassNotFoundException for WSServlet. I also tried adding the jar to lib/ext but that didn't work either.
I've tried an example "hello world" app (also requiring webservices-rt.jar) and it exhibits the same behaviour.
There doesn't seem to be much documentation on v7 yet, has anyone else come across this and found a solution?
Oops, found the answer. Although it's not mentioned in the documentation for porting/upgrading to jetty 7, there is a minor mention here that the syntax has changed and the new commandline should be:
java -jar start.jar lib=/path/to
(Note it's the parent path of the jar file above)