[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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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:
--------------------------------------
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, 5 months