[JBoss JIRA] (DROOLS-511) KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a pacakge doesn't exist
by Mike Wilson (JIRA)
Mike Wilson created DROOLS-511:
----------------------------------
Summary: KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a pacakge doesn't exist
Key: DROOLS-511
URL: https://issues.jboss.org/browse/DROOLS-511
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: Mike Wilson
Assignee: Mark Proctor
When calling KieContainerImpl.updateToVersion(ReleaseId), we sometimes experience a NullPointerException during a chained set of method calls that try to obtain a package, and then a rule within it.
If the package is null, a NullPointerException is thrown, because there is no check in place before that call to get the rule from the package.
To prevent this, a null check should be added to the package before trying to get the rule from it.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3409) Incorrect port number for commented out domain controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3409?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-3409.
------------------------------------
Resolution: Duplicate Issue
> Incorrect port number for commented out domain controller
> ---------------------------------------------------------
>
> Key: WFLY-3409
> URL: https://issues.jboss.org/browse/WFLY-3409
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Arun Gupta
> Assignee: Jason Greene
>
> domain/configuration/host.xml has the following fragment:
> <domain-controller>
> <local/>
> <!-- Alternative remote domain controller configuration with a host and port -->
> <!-- <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/> -->
> </domain-controller>
> Even though the fragment is commented, the port number should be updated to 9990 anyway.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3410) Old “remote://“ protocol is hard coded RemoteDomainConnectionService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3410?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-3410.
------------------------------------
Assignee: (was: Jason Greene)
Resolution: Duplicate Issue
> Old “remote://“ protocol is hard coded RemoteDomainConnectionService
> --------------------------------------------------------------------
>
> Key: WFLY-3410
> URL: https://issues.jboss.org/browse/WFLY-3410
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Arun Gupta
>
> Email conversation on wildfly-dev:
> http://lists.jboss.org/pipermail/wildfly-dev/2014-May/002157.html
> > 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ?
> >
> > <domain-controller>
> > <remote host="10.211.55.7" port="9999"/>
> > </domain-controller>
> >
> > FTR it only works with 9999, not with 9990.
> >
> > Domain Controller shows the message:
> >
> > [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host
> > Controller Service Threads - 28) JBAS010918: Registered remote slave
> > host "slave", WildFly 8.1.0.CR2 “Kenny”
> It looks like we hardcode the old “remote://“ protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the <remote> element take a ‘protocol’ attribute?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-568) Consider using a "describe" notion for providing the model to slaves on registration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-568?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-568:
----------------------------------
Assignee: Emanuel Muckenhuber
> Consider using a "describe" notion for providing the model to slaves on registration
> ------------------------------------------------------------------------------------
>
> Key: WFLY-568
> URL: https://issues.jboss.org/browse/WFLY-568
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 9.0.0.CR1
>
>
> When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave.
> Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC.
> This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3429:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103735
> Classloader leak in JBossCachedAuthenticationManager
> ----------------------------------------------------
>
> Key: WFLY-3429
> URL: https://issues.jboss.org/browse/WFLY-3429
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.
> The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
> One option to solve this issue could be to remove the cache entries which are related to the undeployed application.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-3429:
------------------------------
Bugzilla Update: (was: Perform)
> Classloader leak in JBossCachedAuthenticationManager
> ----------------------------------------------------
>
> Key: WFLY-3429
> URL: https://issues.jboss.org/browse/WFLY-3429
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.
> The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
> One option to solve this issue could be to remove the cache entries which are related to the undeployed application.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager
by Josef Cacek (JIRA)
Josef Cacek created WFLY-3429:
---------------------------------
Summary: Classloader leak in JBossCachedAuthenticationManager
Key: WFLY-3429
URL: https://issues.jboss.org/browse/WFLY-3429
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 8.1.0.Final
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Critical
When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.
The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
One option to solve this issue could be to remove the cache entries which are related to the undeployed application.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3345:
-------------------------------
Fix Version/s: 9.0.0.Alpha1
> Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows
> ----------------------------------------------------------------------
>
> Key: WFLY-3345
> URL: https://issues.jboss.org/browse/WFLY-3345
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 8.2.0.CR1, 9.0.0.Alpha1
>
>
> In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error:
> {code}
> [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month