[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, 9 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, 9 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, 9 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, 9 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
12 years, 9 months
[JBoss JIRA] (WFLY-490) Simple Domain Management Role Based Permissions
by Gopi Chand Uppala (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Gopi Chand Uppala commented on WFLY-490:
----------------------------------------
Thanks! Hope it gets rolled into JBoss EAP quickly.
> Simple Domain Management Role Based Permissions
> -----------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
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, 9 months
[JBoss JIRA] (AS7-3143) JMS Messages with CMP and transactional=true are not commited to the queue
by Tom Eicher (JIRA)
[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ]
Tom Eicher commented on AS7-3143:
---------------------------------
So using JmsXA will will fix the problem of messages not being received (at all) in the MDB.
However, the parameter is still not completely ignored since transacted=false will work with multiple MDBs (ActivationConfigProperty maxSessions) as configured,
whereas transacted=true will only have one (single-threaded) MDB working on the queue, i.e. the message posting/receiving is serialized.
Is this expected behaviour or maybe another bug ?
> JMS Messages with CMP and transactional=true are not commited to the queue
> --------------------------------------------------------------------------
>
> Key: AS7-3143
> URL: https://issues.jboss.org/browse/AS7-3143
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.0.1.Final, 7.1.0.CR1, 7.1.0.CR1b
> Environment: Windows 7, Java 1.6 update 24
> Reporter: Markus Döring
> Assignee: Carlo de Wolf
> Fix For: 7.1.0.Final
>
> Attachments: TestEAR.ear.zip, TestEAR.ear.zip, TestEAR.ear.zip
>
>
> When sending a message to a JMS queue using container managed transactions and setting transactional=true (connection.createSession(true, Session.AUTO_ACKNOWLEDGE)), the message is never added to the queue.
> Using transactional=false is not an option because the message is added to the queue immediately and not after transaction commit.
> This can be reproduced with the attached EAR (exploded deployment, so just unpack the .zip in the deployments directory) and the standalone-full.xml (JBoss 7.1.0.CR1
--
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, 9 months
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
The Infinispan team has identified another condition that can trigger this bug, specifically ISPN-2974. The fix is currently be ported to Infinispan 5.2.x - and should soon be available for consumption by EAP 6.1.
What should we do with the status of this BZ?
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
--
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, 9 months
[JBoss JIRA] (WFLY-490) Simple Domain Management Role Based Permissions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-490:
----------------------------------
Fix Version/s: 8.0.0.CR1
Priority: Blocker (was: Major)
Thanks for the feedback.
We've decided to pull this back into WildFly 8.
> Simple Domain Management Role Based Permissions
> -----------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
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, 9 months