[JBoss JIRA] (WFLY-144) Deploying WAR fails and UI does not reflect failure
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-144?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-144:
------------------------------
Fix Version/s: 8.0.0.Beta1
(was: 8.0.0.Alpha3)
> Deploying WAR fails and UI does not reflect failure
> ---------------------------------------------------
>
> Key: WFLY-144
> URL: https://issues.jboss.org/browse/WFLY-144
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: Catherine Robson
> Assignee: Heiko Braun
> Fix For: 8.0.0.Beta1
>
>
> When deploying a WAR in JBoss EAP 6.0 that fails, the UI does not reflect the failure well to the user.
> Current flow:
> 1. In UI, go to enable a WAR file.
> 2. Click "confirm" to enable the WAR file
> 3. Modal window saying Please Wait, your request is being processed window appears. In upper right hand side of UI, a small red message displays stating 'Unkown error'. The modal window continues to be front and center, and as a user I assume it is still trying to do something.
> In the meantime, in the CLI this appeared:
> 12:08:47,877 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "s-ramp-ui.war"
> ... (lots more messages) ...
> 12:08:49,209 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment s-ramp-ui.war in 51ms
> Expected behaviour:
> If the CLI has indicated that the deployment of the WAR has failed/stopped, the UI should reflect this in the modal window that states it is currently processing the request. The modal should change from "Currently processing your request..." to something like, "Enabling <filname.war> has failed. Please click below to see the full failure message." Which also enables the user to see the full message shown in the command line interface if they want to for getting help with the issue.
--
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
13 years
[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.Beta1
(was: 8.0.0.Alpha3)
> 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.Beta1
>
>
> 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
13 years
[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.Beta1
(was: 8.0.0.Alpha3)
> 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.Beta1
>
>
> 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
13 years
[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.Beta1
(was: 8.0.0.Alpha3)
> 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.Beta1
>
>
> 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
13 years