[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
10 years, 11 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
10 years, 11 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
10 years, 11 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
10 years, 11 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
10 years, 11 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
10 years, 11 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
10 years, 11 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
10 years, 11 months
[JBoss JIRA] (WFLY-967) ClassLoader memory leak with JSF
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on WFLY-967:
-----------------------------------
Vlad, what problem are you actually seeing due to this (possible) leak?
I'm seeing the Managed Bean "Test" sometimes stick around because it is request-scoped bean and it is referenced by the HttpServletRequestImpl. Those do get cleaned up and/or recycled so I can't say that the bean is really leaking.
Before you were talking about the ModuleClassLoader. Do you have some procedure that causes lots of those instances that get created but never cleaned up?
It would be easy enough to call Introspector.flushCaches on undeploy of JSF apps but I don't want to do it if I can't see a compelling reason.
> ClassLoader memory leak with JSF
> --------------------------------
>
> Key: WFLY-967
> URL: https://issues.jboss.org/browse/WFLY-967
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Vlad Arkhipov
> Assignee: Stan Silvert
> Priority: Critical
> Attachments: war-leak.tar.gz
>
>
> JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce:
> # mvn package
> # deploy war-leak.war
> # open http://localhost:8080/war-leak
> # undeploy war-leak.war
> # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war
> References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose.
> http://wiki.apache.org/commons/Logging/UndeployMemoryLeak
> http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/...
--
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
10 years, 11 months