[JBoss JIRA] (AS7-5744) JRE logging.properties file in a jar fails the deployment of an application
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/AS7-5744?page=com.atlassian.jira.plugin.s... ]
James Perkins commented on AS7-5744:
------------------------------------
What does your logging.properties file look like? Is it in the JUL format?
> JRE logging.properties file in a jar fails the deployment of an application
> ---------------------------------------------------------------------------
>
> Key: AS7-5744
> URL: https://issues.jboss.org/browse/AS7-5744
> Project: Application Server 7
> Issue Type: Bug
> Components: EE, Logging
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Windows 7 pro
> JBoss 7.1.3
> Reporter: Francois MESSIAEN
> Assignee: James Perkins
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: logging.properties
>
>
> If a logging.properties file, as described in the java.util.logging.LogManager, is in a jar file of the ear, the application fails to be deployed. An Exception is thrown:
> {noformat}
> 11:38:03,842 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."fullear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fullear.ear".POST_MODULE: JBAS018733: N'a pas pu traiter la phase POST_MODULE de deployment "fullear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011555: N'a pas pu configurer la connexion par le fichier de configuration 'logging.properties'
> at org.jboss.as.logging.LoggingConfigurationProcessor.deploy(LoggingConfigurationProcessor.java:125)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
> ... 5 more
> Caused by: java.lang.IllegalArgumentException: className is null
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:52) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.config.HandlerConfigurationImpl.<init>(HandlerConfigurationImpl.java:54) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.addHandlerConfiguration(LogContextConfigurationImpl.java:138) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:477) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:379) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:92) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.as.logging.LoggingConfigurationProcessor.deploy(LoggingConfigurationProcessor.java:122)
> ... 6 more
> 11:38:03,845 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Rapport de statut de service
> JBAS014777: Services qui n'ont pas pu démarrer : service jboss.deployment.unit."fullear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fullear.ear".POST_MODULE: JBAS018733: N'a pas pu traiter la phase POST_MODULE de deployment "fullear.ear"
> {noformat}
> The content of the fullear.ear I use for this test is:
> * lib
> ** myejbClient.jar
> * META-INF
> ** application.xml
> ** jboss-app.xml
> ** jboss-deployment-structure.xml
> ** jboss-ejb-client.xml
> ** management-trackfolder-hornetq-jms.xml
> ** MANIFEST.MF
> * myejb.jar
> * web.war
> I put the logging.properties files in myejbclient.jar file. The content of that jar file is :
> * org
> ** mapp
> *** ejb
> **** logging.properties
> **** Greeter.class
> * META-INF
> ** MANIFEST.MF
> The logging.properties file is a copy of the [JRE_HOME]/lib/logging.properties
--
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
12 years, 8 months
[JBoss JIRA] (AS7-5744) JRE logging.properties file in a jar fails the deployment of an application
by Florian Beckamann (JIRA)
[ https://issues.jboss.org/browse/AS7-5744?page=com.atlassian.jira.plugin.s... ]
Florian Beckamann commented on AS7-5744:
----------------------------------------
I get the same error with JBoss EAP 6.1.0.Beta1 (linux kernel 3.8). The -Dorg.jboss.as.logging.per-deployment=false workaround seems to be ignored.
[0m[0m21:35:06,238 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.1.0.Beta1 (AS 7.2.0.Final-redhat-4) started in 4889ms - Started 170 of 227 services (56 services are passive or on-demand)
[0m[31m21:35:43,402 ERROR [stderr] (http-/0.0.0.0:8080-1) java.lang.IllegalArgumentException: className is null
[0m[31m21:35:43,403 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:59)
[0m[31m21:35:43,404 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.config.HandlerConfigurationImpl.<init>(HandlerConfigurationImpl.java:54)
[0m[31m21:35:43,405 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.config.LogContextConfigurationImpl.addHandlerConfiguration(LogContextConfigurationImpl.java:144)
[0m[31m21:35:43,406 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:606)
[0m[31m21:35:43,406 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:487)
[0m[31m21:35:43,407 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:96)
[0m[31m21:35:43,408 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.as.logging.logmanager.ConfigurationPersistence.configure(ConfigurationPersistence.java:128)
[0m[31m21:35:43,408 ERROR [stderr] (http-/0.0.0.0:8080-1) at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:300)
[0m[31m21:35:43,409 ERROR [stderr] (http-/0.0.0.0:8080-1) at edu.cmu.sphinx.util.props.ConfigurationManagerUtils.configureLogger(ConfigurationManagerUtils.java:195)
[0m[31m21:35:43,409 ERROR [stderr] (http-/0.0.0.0:8080-1) at edu.cmu.sphinx.util.props.ConfigurationManagerUtils.configureLogger(ConfigurationManagerUtils.java:165)
[0m[31m21:35:43,410 ERROR [stderr] (http-/0.0.0.0:8080-1) at edu.cmu.sphinx.util.props.ConfigurationManager.<init>(ConfigurationManager.java:64)
So I guess the bug has to be re-opened!?
> JRE logging.properties file in a jar fails the deployment of an application
> ---------------------------------------------------------------------------
>
> Key: AS7-5744
> URL: https://issues.jboss.org/browse/AS7-5744
> Project: Application Server 7
> Issue Type: Bug
> Components: EE, Logging
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Windows 7 pro
> JBoss 7.1.3
> Reporter: Francois MESSIAEN
> Assignee: James Perkins
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
> Attachments: logging.properties
>
>
> If a logging.properties file, as described in the java.util.logging.LogManager, is in a jar file of the ear, the application fails to be deployed. An Exception is thrown:
> {noformat}
> 11:38:03,842 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."fullear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fullear.ear".POST_MODULE: JBAS018733: N'a pas pu traiter la phase POST_MODULE de deployment "fullear.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011555: N'a pas pu configurer la connexion par le fichier de configuration 'logging.properties'
> at org.jboss.as.logging.LoggingConfigurationProcessor.deploy(LoggingConfigurationProcessor.java:125)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.3.Final.jar:7.1.3.Final]
> ... 5 more
> Caused by: java.lang.IllegalArgumentException: className is null
> at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:52) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.config.HandlerConfigurationImpl.<init>(HandlerConfigurationImpl.java:54) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.config.LogContextConfigurationImpl.addHandlerConfiguration(LogContextConfigurationImpl.java:138) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:477) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:379) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:92) [jboss-logmanager-1.3.2.Final.jar:1.3.2.Final]
> at org.jboss.as.logging.LoggingConfigurationProcessor.deploy(LoggingConfigurationProcessor.java:122)
> ... 6 more
> 11:38:03,845 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Rapport de statut de service
> JBAS014777: Services qui n'ont pas pu démarrer : service jboss.deployment.unit."fullear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fullear.ear".POST_MODULE: JBAS018733: N'a pas pu traiter la phase POST_MODULE de deployment "fullear.ear"
> {noformat}
> The content of the fullear.ear I use for this test is:
> * lib
> ** myejbClient.jar
> * META-INF
> ** application.xml
> ** jboss-app.xml
> ** jboss-deployment-structure.xml
> ** jboss-ejb-client.xml
> ** management-trackfolder-hornetq-jms.xml
> ** MANIFEST.MF
> * myejb.jar
> * web.war
> I put the logging.properties files in myejbclient.jar file. The content of that jar file is :
> * org
> ** mapp
> *** ejb
> **** logging.properties
> **** Greeter.class
> * META-INF
> ** MANIFEST.MF
> The logging.properties file is a copy of the [JRE_HOME]/lib/logging.properties
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-976) Multi-JSF doesn't understand new modules structure
by Glenn Kastrinos (JIRA)
[ https://issues.jboss.org/browse/WFLY-976?page=com.atlassian.jira.plugin.s... ]
Glenn Kastrinos commented on WFLY-976:
--------------------------------------
YES! Thank you so much for all of your help! It FINALLY compiles and deploys successfully with no errors, even when I added the tomahawk-1.1.9 jar and put the extension filters back into my web.xml. My only issue is that I can't seem to get the correct URL. http://127.0.0.1:8080/Localization/ should work, judging from the standalone.xml. I just get "404 - Not Found." Any thoughts?
I hope this post tree helps people that were in my position. Thank you again very much
> Multi-JSF doesn't understand new modules structure
> --------------------------------------------------
>
> Key: WFLY-976
> URL: https://issues.jboss.org/browse/WFLY-976
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Attachments: install-myfaces-2.1.11.cli, Localization.war, Localization.war
>
>
> With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default.
> The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script.
> See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1177) Recursive expression resolution
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.... ]
John Mazzitelli commented on WFLY-1177:
---------------------------------------
to be clear, the following should still resolve properly:
$\{x:$\{y}/boo}
If sysprop "x" isn't specified, the value should be the resolved value of $\{y}/boo (that is, whatever sysprop "y" value is, appended with "/boo").
> Recursive expression resolution
> -------------------------------
>
> Key: WFLY-1177
> URL: https://issues.jboss.org/browse/WFLY-1177
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jess Sightler
> Labels: rhq
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-976) Multi-JSF doesn't understand new modules structure
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-976?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on WFLY-976:
-----------------------------------
There are two problems in your web.xml.
You don't want this because you are using the MyFaces implementation that resides under /modules. If you do this it means "Ignore all the regular JSF stuff. The WAR is taking care of everything JSF-related". So comment this out.{noformat}
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>{noformat}
You don't want this because it will be handled automatically by WildFly. If you specify this listener in web.xml then it won't be able to find the class.{noformat}
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>{noformat}
So now what I see with your app is some errors that indicate the datasource is missing. I assume you probably won't have that problem.{noformat}
14:36:50,762 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014613: Operation ("deploy") failed - address: ({"deployment" => "Lo
calization.war"}) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"Localization.war#LocalizationPU\" is m
issing [jboss.naming.context.java.jboss.datasources.LocalizationDS]"]}
14:36:50,767 ERROR [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "Localization.war" was rolled back with the following failure me
ssage: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"Localization.war#LocalizationPU\" is missing [jboss.naming.context.java.
jboss.datasources.LocalizationDS]"]}
{noformat}
> Multi-JSF doesn't understand new modules structure
> --------------------------------------------------
>
> Key: WFLY-976
> URL: https://issues.jboss.org/browse/WFLY-976
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Attachments: install-myfaces-2.1.11.cli, Localization.war, Localization.war
>
>
> With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default.
> The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script.
> See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789
--
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
12 years, 8 months
[JBoss JIRA] (AS7-5100) JMX client does not work inside web application (servlet)
by John Sanda (JIRA)
[ https://issues.jboss.org/browse/AS7-5100?page=com.atlassian.jira.plugin.s... ]
John Sanda commented on AS7-5100:
---------------------------------
What about connecting to another Java process that is running an MBean server and configured to use the RMI connector? That sounds like the issue here as well as the one described in https://issues.jboss.org/browse/AS7-2138.
> JMX client does not work inside web application (servlet)
> ---------------------------------------------------------
>
> Key: AS7-5100
> URL: https://issues.jboss.org/browse/AS7-5100
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.0.2.Final, 7.1.1.Final
> Environment: JBoss 7.1.1 on Windows XP, Operating system should not doing impact
> Reporter: Francois Billard
>
> a simple jmx client connection to get an attribute on a remote MBeanServer does not work and produce errors at runtime :
> Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://192.168.47.23:50000/jmxrmi -- service jboss.naming.context.java.rmi:."192.168.47.23:50000".jmxrmi
>
> and
>
> Caused by: javax.naming.NameNotFoundException: rmi://192.168.47.23:50000/jmxrmi -- service jboss.naming.context.java.rmi:."192.168.47.23:50000".jmxrmi
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1177) Recursive expression resolution
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.... ]
John Mazzitelli edited comment on WFLY-1177 at 4/30/13 2:02 PM:
----------------------------------------------------------------
Just wanted to make sure this fix includes my use-case where a sysprop value itself has an expression in it for ssl config settings.
ca-certificate-file and certificate-key-file attributes on ssl=configuration resource - if you set one of those to:
$\{x}
and x is a system prop whose actual value has an expression in it such as:
$\{jboss.server.config.dir}/my.keystore
we need it resolved fully for the web connector to start properly.
was (Author: mazz):
Just wanted to make sure this fix includes my use-case where a sysprop value itself has an expression in it for ssl config settings.
ca-certificate-file and certificate-key-file attributes on ssl=configuration resource - if you set one of those to:
${x}
and x is a system prop whose actual value has an expression in it such as:
${jboss.server.config.dir}/my.keystore
we need it resolved fully for the web connector to start properly.
> Recursive expression resolution
> -------------------------------
>
> Key: WFLY-1177
> URL: https://issues.jboss.org/browse/WFLY-1177
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jess Sightler
> Labels: rhq
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1177) Recursive expression resolution
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.... ]
John Mazzitelli updated WFLY-1177:
----------------------------------
Labels: rhq (was: )
> Recursive expression resolution
> -------------------------------
>
> Key: WFLY-1177
> URL: https://issues.jboss.org/browse/WFLY-1177
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jess Sightler
> Labels: rhq
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1177) Recursive expression resolution
by John Mazzitelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.... ]
John Mazzitelli commented on WFLY-1177:
---------------------------------------
Just wanted to make sure this fix includes my use-case where a sysprop value itself has an expression in it for ssl config settings.
ca-certificate-file and certificate-key-file attributes on ssl=configuration resource - if you set one of those to:
${x}
and x is a system prop whose actual value has an expression in it such as:
${jboss.server.config.dir}/my.keystore
we need it resolved fully for the web connector to start properly.
> Recursive expression resolution
> -------------------------------
>
> Key: WFLY-1177
> URL: https://issues.jboss.org/browse/WFLY-1177
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jess Sightler
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-976) Multi-JSF doesn't understand new modules structure
by Glenn Kastrinos (JIRA)
[ https://issues.jboss.org/browse/WFLY-976?page=com.atlassian.jira.plugin.s... ]
Glenn Kastrinos edited comment on WFLY-976 at 4/30/13 1:51 PM:
---------------------------------------------------------------
I did deploy the .cli and can see in my wildfly directory that myfaces has been laced throughout the modules via a .cli, however if I don't have the libraries in the /lib, it errors out saying they can't be found. It first threw:
JBAS018733: Failed to process phase INSTALL of deployment "Localization.war" ...
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.ClassNotFoundException: javax.faces.webapp.FacesServlet
so I added the myfaces bundle-2.1.11, but then it errored out asking for the collections predicate, after I added collections-3.2, then it goes a little farther and needs the digester. When I finally add all the things it asks for (getting farther in the deployment process everytime) it goes back to the original error:
WeldApplicationFactory is no javax.faces.application.ApplicationFactory.
I'll upload mine without the libraries. If it works on yours then it must be something with my AS even though I deployed the .cli? Could using XP have any impact? Thank you
was (Author: glennk):
I did deploy the .cli and can see in my wildfly directory that myfaces has been laced throughout the modules via a .cli, however if I don't have the libraries in the /lib, it errors out saying they can't be found. It first threw:
JBAS018733: Failed to process phase INSTALL of deployment "Localization.war" ...
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.ClassNotFoundException: javax.faces.webapp.FacesServlet
so I added the myfaces bundle-2.1.11, but then it errored out asking for the collections predicate, after I added collections-3.2, then it goes a little farther and needs the digester. When I finally add all the things it asks for (getting farther in the deployment process everytime) it goes back to the original error:
WeldApplicationFactory is no javax.faces.application.ApplicationFactory.
I'll remove the current war and upload mine without the libraries. If it works on yours then it must be something with my AS even though I deployed the .cli? Could using XP have any impact? Thank you
> Multi-JSF doesn't understand new modules structure
> --------------------------------------------------
>
> Key: WFLY-976
> URL: https://issues.jboss.org/browse/WFLY-976
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Attachments: install-myfaces-2.1.11.cli, Localization.war, Localization.war
>
>
> With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default.
> The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script.
> See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789
--
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
12 years, 8 months