[JBoss JIRA] (WFLY-145) User insn't properly informed that APR is used
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-145?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-145:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> User insn't properly informed that APR is used
> ----------------------------------------------
>
> Key: WFLY-145
> URL: https://issues.jboss.org/browse/WFLY-145
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Reporter: Rostislav Svoboda
> Assignee: Remy Maucherat
> Fix For: 8.0.0.CR1
>
>
> AS7 log doesn't show sufficient information that APR is used or not. Currently the only clue is that org.apache.coyote.http11.Http11AprProtocol is used instead of org.apache.coyote.http11.Http11Protocol. But it's implementation details and many users can miss that.
> Add log message to inform users if APR is used or not!
> For example APR affect https connector definition which must use openssl based keys and not keystore. And if users do not know APR is used they can be easily confused and blame AS7 as broken.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-131) Seam2Processor will not have permissions to its added resource loader
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-131:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Seam2Processor will not have permissions to its added resource loader
> ---------------------------------------------------------------------
>
> Key: WFLY-131
> URL: https://issues.jboss.org/browse/WFLY-131
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: David Lloyd
> Assignee: Ales Justin
> Labels: security
> Fix For: 8.0.0.CR1
>
>
> The {{Seam2Processor}} class adds a {{VFSResourceLoader}} to the deployment in order to copy certain Seam classes into it. The problem is that the {{VFSResourceLoader}} will fail at runtime with a permission exception because there is no corresponding {{VirtualFilePermission}}.
> For this type of resource loader, it is better just to add the JAR using {{JarFileResourceLoader}}, which does not require permissions at load time and is much faster anyway.
> If you must use {{VFSResourceLoader}}, then instead of creating and adding the resource loader yourself, add a {{ResourceRoot}} to the deployment context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-143) Improve testing of Infinispan subsystem management features
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-143?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-143:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Improve testing of Infinispan subsystem management features
> -----------------------------------------------------------
>
> Key: WFLY-143
> URL: https://issues.jboss.org/browse/WFLY-143
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 8.0.0.CR1
>
>
> We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
> From the documentation:
> {noformat}
> Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
> into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
> from executing the results of that describe operation, and compare that model to first model.
> {noformat}
> Over and above these tests, we need more specific tests which cover use cases such as:
> - every attribute can be read/written as required and that the subsequent reload-required state is as expected
> - operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
> - validating that the XML configuration specified gets translated into the desired Infinispan configuration
> - and many others
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-156) Unable to start jboss AS on windows if installed on path containig non-ascii characters
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-156?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-156:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Unable to start jboss AS on windows if installed on path containig non-ascii characters
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-156
> URL: https://issues.jboss.org/browse/WFLY-156
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: windows 2008 x64
> Reporter: Ales Kolenc
> Assignee: Tomaz Cerar
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> 1.) Install jboss into a folder containing non-ascii characters. (i.e. "C:\Testチ").
> 2.) run standalone.bat
> C:\Test?\jboss-as-7.1.1.Final\bin>set JAVA_HOME=C:\Program Files\Java\jre7
> C:\Test?\jboss-as-7.1.1.Final\bin>standalone.bat
> Calling "C:\Test?\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: C:\Test?\jboss-as-7.1.1.Final
> JAVA: C:\Program Files\Java\jre7\bin\java
> JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Error: Unable to access jarfile C:\Test?\jboss-as-7.1.1.Final\jboss-modules.jar
> Press any key to continue . . .
> C:\Test?\jboss-as-7.1.1.Final\bin>
> 3.) pleas note that: "Testチ" used in path -> 'チ' does not bellong to system locale code page. E.g.: char 'チ' is in CP 932, system locale code page used 437/1252,..
> 4.) i would also like to add that jboss does not start if it installed in "normal" folder, but JBOSS_CONFIG_DIR && JBOSS_LOG_DIR are set to folder with non-ascii characters:
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_LOG_DIR=c:\Test?
> c:\test\jboss-as-7.1.1.Final\bin>set JBOSS_CONFIG_DIR=c:\Test?\configuration
> c:\test\jboss-as-7.1.1.Final\bin>dir %JBOSS_CONFIG_DIR%
> Volume in drive C has no label.
> Volume Serial Number is 2C2F-FA6F
> Directory of c:\Test?\configuration
> 01/04/2013 02:34 AM <DIR> .
> 01/04/2013 02:34 AM <DIR> ..
> 01/04/2013 01:42 AM 634 application-roles.properties
> 01/04/2013 01:42 AM 812 application-users.properties
> 01/04/2013 01:42 AM 2,042 logging.properties
> 01/04/2013 01:42 AM 836 mgmt-users.properties
> 01/04/2013 01:42 AM 27,024 standalone-full-ha.xml
> 01/04/2013 01:42 AM 20,794 standalone-full.xml
> 01/04/2013 01:42 AM 20,358 standalone-ha.xml
> 01/04/2013 01:42 AM 15,372 standalone.xml
> 01/04/2013 02:34 AM <DIR> standalone_xml_history
> 8 File(s) 87,872 bytes
> 3 Dir(s) 20,185,866,240 bytes free
> c:\test\jboss-as-7.1.1.Final\bin>standalone.bat -Djboss.server.config.dir=%JBOSS_CONFIG_DIR%
> Calling "c:\test\jboss-as-7.1.1.Final\bin\standalone.conf.bat"
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: c:\test\jboss-as-7.1.1.Final
> JAVA: C:\Program Files\Java\jre7\bin\java
> JAVA_OPTS: -XX:+TieredCompilation -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djb
> oss.server.default.config=standalone.xml
> ===============================================================================
> Unable to read the logging configuration from 'file:c:\Test?\configuration/logging.properties' (java.io.FileNotFoundException: c:\Test?\configuration\logging.properties (The filename, directory name, or volume label syntax is incorrect))
> java.lang.IllegalStateException: JBAS018701: Configuration directory does not exist: c:\Test?\configuration
> at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:371)
> at org.jboss.as.server.Main.determineEnvironment(Main.java:242)
> at org.jboss.as.server.Main.main(Main.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.jboss.modules.Module.run(Module.java:260)
> at org.jboss.modules.Main.main(Main.java:291)
> Press any key to continue . . .
> c:\test\jboss-as-7.1.1.Final\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-146) "HHH000231: Schema export unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed" on clean shutdown
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-146?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-146:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> "HHH000231: Schema export unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed" on clean shutdown
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-146
> URL: https://issues.jboss.org/browse/WFLY-146
> Project: WildFly
> Issue Type: Bug
> Reporter: Radoslav Husar
> Fix For: 8.0.0.CR1
>
> Attachments: server.log
>
>
> Just saw this when I was closely looking through clustering testsuite logs.
> Affected version: master 8a6aac3c8eb6bc94b7eddfa4d090c9ac05c7e37b
> Seems like the connection pool closes earlier than the entiti manager shutdown?
> {code}15:09:34,473 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 54) HHH000231: Schema export unsuccessful: org.h2.jdbc.JdbcSQLException: Database is already closed (to disable automatic closing at VM shutdown, add ";DB_CLOSE_ON_EXIT=FALSE" to the db URL) [90121-168]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at org.h2.message.DbException.get(DbException.java:135)
> at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1384)
> at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1359)
> at org.h2.jdbc.JdbcConnection.setAutoCommit(JdbcConnection.java:403)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:880)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:1589)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:298)
> at org.hibernate.tool.hbm2ddl.DatabaseExporter.<init>(DatabaseExporter.java:54)
> at org.hibernate.tool.hbm2ddl.SchemaExport.execute(SchemaExport.java:367)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:318)
> at org.hibernate.tool.hbm2ddl.SchemaExport.drop(SchemaExport.java:314)
> at org.hibernate.internal.SessionFactoryImpl.close(SessionFactoryImpl.java:1386)
> at org.hibernate.ejb.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:194)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$2.run(PersistenceUnitServiceImpl.java:124)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122){code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-174) Missing JSP or EL privileged action(s)
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-174?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-174:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Missing JSP or EL privileged action(s)
> --------------------------------------
>
> Key: WFLY-174
> URL: https://issues.jboss.org/browse/WFLY-174
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Reporter: David Lloyd
> Assignee: Remy Maucherat
> Fix For: 8.0.0.CR1
>
>
> When running with a security manager, we're seeing an access control problem with this stack trace:
> {noformat}
> 18:21:08,471 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/web-secure].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366) [rt.jar:1.7.0_15]
> at java.security.AccessController.checkPermission(AccessController.java:560) [rt.jar:1.7.0_15]
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) [rt.jar:1.7.0_15]
> at java.lang.Thread.getContextClassLoader(Thread.java:1451) [rt.jar:1.7.0_15]
> at javax.el.FactoryFinder.find(FactoryFinder.java:130) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:185) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
> at javax.el.ExpressionFactory.newInstance(ExpressionFactory.java:156) [jboss-el-api_2.2_spec-1.0.2.Final.jar:1.0.2.Final]
> at org.apache.jasper.runtime.JspApplicationContextImpl.<init>(JspApplicationContextImpl.java:48) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.runtime.JspApplicationContextImpl.getInstance(JspApplicationContextImpl.java:77) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.runtime.JspFactoryImpl.getJspApplicationContext(JspFactoryImpl.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jsp.login_jsp._jspInit(login_jsp.java:22)
> at org.apache.jasper.runtime.HttpJspBase.init(HttpJspBase.java:51) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:151) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:320) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:242) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final.jar:1.0.2.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_15]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_15]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_15]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_15]
> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:263) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:261) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) [rt.jar:1.7.0_15]
> at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:295) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:155) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:288) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:59) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:197) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:832) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:620) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:553) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:69) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:84) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:474) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:372) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:265) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:447) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-8.0.0.Alpha1-SNAPSHOT.jar:8.0.0.Alpha1-SNAPSHOT]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {noformat}
> It looks like javax.el should probably be getting TCCL from a privileged block, or else org.apache.jasper.runtime.JspApplicationContextImpl.<init> should be executing in a privileged context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (WFLY-166) Clearing server environment in bootstrap breaks embedded server restart
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-166?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-166:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Clearing server environment in bootstrap breaks embedded server restart
> -----------------------------------------------------------------------
>
> Key: WFLY-166
> URL: https://issues.jboss.org/browse/WFLY-166
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Thomas Diesler
> Assignee: Bartosz Baranowski
> Fix For: 8.0.0.CR1
>
>
> Recursively deleting tmp directories as part of Bootstrap.bootstrap() prevents multiple embedded server restarts. I believe it has to do with how directories are crated as part of static VFS initialisation.
> TempFileProvider has this static code
> {code}
> static {
> String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
> if (configTmpDir == null)
> configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
> try {
> TMP_ROOT = new File(configTmpDir, "vfs");
> TMP_ROOT.mkdirs();
> }
> catch (Exception e) {
> throw new RuntimeException("Can't set up temp file provider", e);
> }
> }
> {code}
> which creates the vfs directory only once that [this patch|https://github.com/jbossas/jboss-as/commit/ad3e878098] removes. As a consequence on server restart with jboss-vfs on the boot classpath hte vfs directory is missing an no tmp file can be created.
> Generally, the server should only remove state on shutdown that it creates itself on startup/run. Alternatively, jboss-vfs should support a start/stop lifecycle in the TempFileProvider and possibly in other entities that also use static initialisers.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months