[JBoss JIRA] (WFLY-2619) Enable https port override for Undertow
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2619:
--------------------------------------
Summary: Enable https port override for Undertow
Key: WFLY-2619
URL: https://issues.jboss.org/browse/WFLY-2619
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Beta1
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
At the moment the http to https redirect automatically discovers the port to redirect to - for situations where automatic discovery is not reliable e.g. port forwarding a config options should be provided to specify the redirect port to use.
--
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, 10 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Scott Marlow resolved WFLY-2593.
--------------------------------
Resolution: Out of Date
Cannot reproduce the leak in WildFly 8 and *should* be fixed in next EAP 6.x release (you could open a ticket with Red Hat support asking for the fix for your production environment).
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
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, 10 months
[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-2593.
------------------------------
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
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, 10 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka reopened WFLY-2426:
--------------------------------
Reopening, I'll add a testcase.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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, 10 months
[JBoss JIRA] (DROOLS-368) Memory leak mappedKnowledgeBaseListeners
by David Tse (JIRA)
David Tse created DROOLS-368:
--------------------------------
Summary: Memory leak mappedKnowledgeBaseListeners
Key: DROOLS-368
URL: https://issues.jboss.org/browse/DROOLS-368
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Environment: Linex
Reporter: David Tse
Assignee: Mark Proctor
Priority: Critical
This leak is identified by getting a heap dump. Analysis of the heap dump by Eclipse MAT puts org.drools.retoo.ReteooRuleBase as the prime suspect holding to 47.33% of the 870 MB heap memory with org.drools.retoo.ReteooStatefulSession adding to the problem accounting for an additional 5.25% of the memory leak.
Examination of the BRMS 5.5.0.Final source code indicates that SFT memory leaks are caused by issues associated with 7 classes in the drools-core module of the community version BRMS 5.5.0.Final. These classes are
• org.drools.impl.KnowledgeBaseImpl.java
• org.drools.impl.StatefulKnowledgeSession.java
• org.drools.retoo.ReteooStatefulSession which extends org.drools.retoo.ReteooWorkingMemory.java which extends org.drools.common.AbstractWorkingMemory.java
• org.drools.retoo.ReteooRuleBase.java which extends org.drools.common.AbstractRuleBase.java
The code in the community version has cyclic dependency and these developed into dying pointers.
1. org.drools.impl.KnowledgeBaseImpl$KnowledgeBaseEventListenerWrapper is holding a reference to this (KnowledgeBaseImpl)
2. KnowledgeBaseImpl is holding a reference to RuleBase (ReteooRuleBase is the implementation class)
3. ReteooRuleBase is holding a reference to org.drools.impl.KnowledgeBaseImpl$KnowledgeBaseEventListenerWrapper
For the second leak, StatefulKnowledgeSessionImpl is holding a reference to ReteooWorkingMemory. ReteooWorkingMemory is also holding a reference to StatefulKnowledgeSessionImpl.
--
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, 10 months
[JBoss JIRA] (WFLY-705) Implement a User Agent and Remote Address Filter for the HTTP Management Interface
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.s... ]
Andre Dietisheim commented on WFLY-705:
---------------------------------------
As discussed today there seems still to be some requirement for this. I'll try to provide this.
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
> Key: WFLY-705
> URL: https://issues.jboss.org/browse/WFLY-705
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Andre Dietisheim
> Fix For: Awaiting Volunteers
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.
--
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, 10 months
[JBoss JIRA] (WFLY-705) Implement a User Agent and Remote Address Filter for the HTTP Management Interface
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-705?page=com.atlassian.jira.plugin.s... ]
Andre Dietisheim reassigned WFLY-705:
-------------------------------------
Assignee: Andre Dietisheim
> Implement a User Agent and Remote Address Filter for the HTTP Management Interface
> ----------------------------------------------------------------------------------
>
> Key: WFLY-705
> URL: https://issues.jboss.org/browse/WFLY-705
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Andre Dietisheim
> Fix For: Awaiting Volunteers
>
>
> The HTTP Management interface provides access to manage the domain model, this interface is partly dependent on the protection supplied by an end users web browser.
> This feature request is to optionally filter inbound requests based on a configurable list of supported user agents and or remote addresses - this will mean buggy browser versions can be excluded and remote clients restricted.
> Anyone interested in contributing please feel free to ping darranl in #jboss-as7.
--
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, 10 months
[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
|javax.faces.component.visit.VisitContextFactory|works|
|javax.faces.context.ExceptionHandlerFactory|works|
|javax.faces.context.ExternalContextFactory|works|
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
was:
If I understand correctly to the subchapter "5.4.1
JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
So far I tried locally this (will be filling the table during time):
||JSF artifact||CDI Injection||
|javax.el.ELResolver||
|javax.faces.application.ApplicationFactory||
|javax.faces.application.NavigationHandler||
|javax.faces.application.ResourceHandler||
|javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
|javax.faces.component.visit.VisitContextFactory|works|
|javax.faces.context.ExceptionHandlerFactory|works|
|javax.faces.context.ExternalContextFactory|||
|javax.faces.context.FacesContextFactory|works|
|javax.faces.context.PartialViewContextFactory||
|javax.faces.event.ActionListener|works only when specified also in faces-config|
|javax.faces.event.SystemEventListener|doesn't work|
|javax.faces.lifecycle.ClientWindowFactory||
|javax.faces.lifecycle.LifecycleFactory||
|javax.faces.lifecycle.PhaseListener|works|
|javax.faces.render.RenderKitFactory||
|javax.faces.view.ViewDeclarationFactory||
|javax.faces.view.facelets.FaceletCacheFactory||
|javax.faces.view.facelets.FaceletFactory||
|javax.faces.view.facelets.TagHandlerDelegateFactory||
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver||
> |javax.faces.application.ApplicationFactory||
> |javax.faces.application.NavigationHandler||
> |javax.faces.application.ResourceHandler||
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|works|
> |javax.faces.context.ExceptionHandlerFactory|works|
> |javax.faces.context.ExternalContextFactory|works|
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.PartialViewContextFactory||
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|doesn't work|
> |javax.faces.lifecycle.ClientWindowFactory||
> |javax.faces.lifecycle.LifecycleFactory||
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory||
> |javax.faces.view.ViewDeclarationFactory||
> |javax.faces.view.facelets.FaceletCacheFactory||
> |javax.faces.view.facelets.FaceletFactory||
> |javax.faces.view.facelets.TagHandlerDelegateFactory||
>
--
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, 10 months
[JBoss JIRA] (WFLY-2605) TCCL leak in infinispan transaction reaper thread
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-2605?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-2605:
------------------------------------
Please attach the hibernate configuration. The cache manager in use should get destroyed on undeploy - and it looks like that isn't happening. I need to know which region factory is being used.
> TCCL leak in infinispan transaction reaper thread
> -------------------------------------------------
>
> Key: WFLY-2605
> URL: https://issues.jboss.org/browse/WFLY-2605
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Environment: Fedora 19, Oracle 7u45, Wildfly 7952aa65e67e1d
> Reporter: Brent Douglas
> Assignee: Paul Ferraro
>
> The reaper thread created in TransactionTable is leaking a deployment module classloader. I have observed by deploying and undeploying the same artifact a couple of times over that only the first deployment is held.
> Looking at where the thread is created in [TransactionTable|https://github.com/infinispan/infinispan/blob/master/cor...] it looks to me like it will get the TCCL of the caller so either that should be changed in Infinispan or the caller TCCL should be set appropriately.
> !http://i.imgur.com/M37pHSe.png!
--
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, 10 months