I am writing a web application that uses Apache Commons config to read/write a system.properties file. The file itself is placed in WEB-INF/classes/config. Reading is no problem, and I can write to it when I deploy using Apache Tomcat. When I deploy the application using JBoss, however, I cannot write (using cofig.setProperty(...). I get the following error (JBoss only):
2012-01-06 12:53:48,879 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/flint].[flint]] (http-0.0.0.0-8080-1) Servlet.service() for servlet flint threw exception
java.net.UnknownServiceException: protocol doesn't support output
at java.net.URLConnection.getOutputStream(URLConnection.java:792)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:449)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:377)
at org.apache.commons.configuration.AbstractFileConfiguration.possiblySave(AbstractFileConfiguration.java:750)
at org.apache.commons.configuration.AbstractFileConfiguration.clearProperty(AbstractFileConfiguration.java:789)
at org.apache.commons.configuration.AbstractConfiguration.setProperty(AbstractConfiguration.java:481)
at org.apache.commons.configuration.AbstractFileConfiguration.setProperty(AbstractFileConfiguration.java:782)
at com.talecris.flint.server.config.SystemConfiguration.setResultInvalidColor(SystemConfiguration.java:571)
at com.talecris.flint.controller.SystemAdminController.setSystemColors(SystemAdminController.java:496)
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 org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
As I said, it all works fine in Tomcat. The system.properties permissions look fine (owner=Jboss). I even opened the permissions up to rw for everyone just to test, but I still get the same error. Is there some JBoss setting that is preventing my application from writing to the path in which it is deployed?
I can write files and subfolders to the deployment directory, but I cannot write changes to system.properties (via apache commons config).
The problem had to do with using VFSFileChangedReloadingStrategy when on JBoss.
Here's a problem that frustrated me for a bit: When using Apache Commons Configuration under JBoss 5, I kept running into the following error when attempting to save to my configuration file (which was a resource under the deployed /classes path):
ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/xxxx].[xxxx]] (http-0.0.0.0-8080-1) Servlet.service() for servlet flint threw exception
java.net.UnknownServiceException: protocol doesn't support output
at java.net.URLConnection.getOutputStream(URLConnection.java:792)
at org.apache.commons.configuration.AbstractFileConfiguration.save(AbstractFileConfiguration.java:449)
What the heck? This error happened every time I attempted to save to my configuration file. It worked fine in Tomcat 6.x, but any time I tested on JBoss, while I could read from the configuration file, the above error was thrown every time I attempted to write to it.
JBoss 5.x VFS (virtual file abstraction) for the files that it deploys, and this causes problems with Commons Config's default FileChangedReloadingStrategy. So the fix is to do something like this instead:
VFSFileChangedReloadingStrategy f = VFSFileChangedReloadingStrategy();
((FileConfiguration) config).setReloadingStrategy(f);
It turns out that we really want to use VFSFileChangedReloadingStrategy (which means using Apache Commons Config 1.7) . This also requires that the Apache Commons VFS API be on your classpath. The good news is that VFSFileChangedReloadingStrategy works well even with non-VFS deployments (i.e. plain old Tomcat and Jetty). Problem solved!
Related
I deployed have build the .war file on centos with eclipse and then deployed it on tomcat 8.5 on centos(Linux). It is working with that. But when I deployed the same ".war" or build a new ".war" file with eclipse on windows It is not working on Tomcat8.5 and it throws BeansInCreation Exception. Having the same Java1.7 and Tomcat8.5 version windows7.
The build was also working on windows on the previous version(before updating)
and there are nothing major changes done in the latest code.
Here are the logs from localhost :
Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name '': Bean with name '' has been injected into other beans ['','',''] in its raw version as part of a circular reference, but has eventually been wrapped (for example as part of auto-proxy creation). This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:553)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:169)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:170)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:268)
... 98 more
I think the problem may be because of "large file path" as Linux support more large file path than windows. I have changed in the regedit also to support but that doesn't need to have changed.
If it works on linux but not on windows i assume that there is a class loading issue (order of classes) while your war is deployed. I would recommend to check /lib directory inside your .war file.
Maybe it contains different versions from the same jar.
Edited:
You can track the class loading of tomcat (or any java application) on linux and windows. For this you need to start it with a special vm paramter (-verbose:class). take a look here:
Java verbose class loading
Hello everyone long story short,i'm using hibernate in my project,i try to deploy my project on WebSphere but it's giving me the error you see in the question title
,as you see in my jars there is no trace of a lower version of jpa 2.0
jars included in my project
but i know that all servers have a version of jpa,and websphere 7 is using 1.0 that i found among it's jars,here is a picture of it,
WebSphere 7 jars
if anyone please knows how to resolve this problem or found this problem before i will be so thankful,thank you in advance, i will leave the full stack trace for more infos :
Caused by: java.lang.NoSuchMethodError: javax/persistence/spi/PersistenceUnitInfo.getSharedCacheMode()Ljavax/persistence/SharedCacheMode;
at org.hibernate.ejb.util.LogHelper.logPersistenceUnitInfo(LogHelper.java:39)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:516)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:288)
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1547)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1485)
... 61 more
I had a similar problem deploying my application with jpa 2.1 in Websphere 7.
If is the same problem, you have to tell Websphere to use Hibernate persistance provider instead of Default Persistance provide.
I wrote a guide with the solution that worked for me in this answer:
https://stackoverflow.com/a/38505479/6503002
EDIT: (Explain step 1 and 2 of the guide)
Step 1: To create a folder you have to access to server machine (through ssh) and create it in the file system (e.g. /usr/sharedHibernate assuming your server runs on linux). Then copy hibernate libraries in the folder you created (from your local machine to the server, with Filezilla or WinScp or Putty).
Step 2: In Websphere console on the left you have Environment section that contains Shared Libraries subsection:
Here create a new shared library, give it the name you want and in classpath textarea insert the path of the folder you created before (e.g. /usr/sharedHibernate)
I am trying to run the Spring 4 example given # https://spring.io/guides/gs/messaging-stomp-websocket. When I try to connect to socket, it throws me following exception. As per the example you need tomcat 7.0.50 and I checked the executable jar which has right version of tomcat. Any pointer would be helpful.
java.lang.IllegalArgumentException: No 'javax.websocket.server.ServerContainer' ServletContext attribute. Are you running in a Servlet container that supports JSR-356?
Check that you have tomcat7-websocket.jar and websocket-api.jar bundled in your executable jar - perhaps you're just getting vanilla tomcat without the extra websocket bits.
I got the same error message in another use case: I deactivated auto configuration and added WebSocketConfig manually to the configuration. Then I got the abovementioned error message.
Fixing the problem was easy: just adding WebSocketAutoConfiguration to the configuration.
I know that this is an ancient thread but I ran into this error and resolved it in modern times by adding implementation("org.springframework.boot:spring-boot-starter-tomcat") explicitly to my project.
I've got into a scenario where I have to get an Axis2 based ws consumer working within WebMethods as a java service. I've implemented the ws consumer first in netbeans just to see if it works and thus i found that the minimal amount of jars I'll require are the following:
[ xmlschema-1.4.7.jar, apache-mime4j-core-0.7.2.jar,
axiom-api-1.2.13.jar, axiom-impl-1.2.13.jar, axis2-adb-1.6.2.jar,
axis2-kernel-1.6.2.jar, axis2-transport-http-1.6.2.jar,
axis2-transport-local-1.6.2.jar, commons-codec-1.3.jar,
commons-httpclient-3.1.jar, commons-logging-1.1.1.jar,
httpcore-4.0.jar, mail-1.4.jar, neethi-3.0.2.jar, wsdl4j-1.6.2.jar ]
I've uploaded these jar files under the IS/packages/{package_name}/code/jars folder. Whenever I try to execute the java service that would send the request and process the response I get the following exception:
java.lang.reflect.InvocationTargetException:
org.apache.axiom.om.OMFactory.getMetaFactory()Lorg/apache/axiom/om/OMMetaFactory;
From the IS error log file I found that the actual error message is as follows:
org.apache.axiom.om.OMFactory.getMetaFactory()Lorg/apache/axiom/om/OMMetaFactory;
Caused by: java.lang.reflect.InvocationTargetException: null Caused
by:
java.lang.NoSuchMethodError:org.apache.axiom.om.OMFactory.getMetaFactory()Lorg/apache/axiom/om/OMMetaFactory;
The platform is WebMethods 8.2 under Linux environment. The JDK version is 1.6.0_32 and the application server under WebMethods is Jetty.
Actually the solve of this problem was a bit more tricky. First of all I manually had to configure the manifest file of the package on the IS server to use the jars provided in the package abnd thus it wouldn't get in conflict with the Axis used by the IS itself. On the other hand I had to manually add the ClassLoader because WebMethods can't use META-INF based information from jar files as it seems. To solve this problem simply use:
System.setProperty("org.apache.axiom.om.OMMetaFactory", "org.apache.axiom.om.impl.llom.factory.OMLinkedListMetaFactory");
That solves all the problems.
I'm having problems migrating from jboss 4.2.1 to jboss 5.1.0
This is the exception i got when I try to deploy my .ear file
WARN [Scanner] could not read entries
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:131)
at java.util.zip.ZipFile.<init>(ZipFile.java:148)
at org.jboss.seam.deployment.Scanner.handleArchive(Scanner.java:151)
at org.jboss.seam.deployment.Scanner.scan(Scanner.java:132)
at org.jboss.seam.deployment.NamespaceScanner.getPackages(NamespaceScanner.java:39)
at org.jboss.seam.init.Initialization.addNamespaces(Initialization.java:787)
at org.jboss.seam.init.Initialization.create(Initialization.java:85)
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
and so the error is larger than that.
It says is a WARN but it doesn't unzip the .ear/.war files and of course it doesn't deploy anything.
I've checked the file isn't corrupt.
Any help would be apreciated.
Thanks & cheers
This is caused by spring's context:component-scan feature incompatibility with JBoss5 Virtual File System (VFS). There's a lib (called snowdrop, provided by JBoss) you can drop into the project that contains a VFS-enabled application context implementation.
You can find it here - http://www.jboss.org/snowdrop
Problem solved. It was a couple of libraries out of date of the seam framework. Apparently they changed some things from seam version for jboss4 to jboss5.
Just update seam libraries and thats all.
Thanks everybody for your interest.
Hope my solution helps others
Cheers