[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-8760:
-------------------------------
Thanks for the detailed reproduce steps, PR sent.
> get method of ModuleClassLoaderLocator requires createClassLoader permission
> ----------------------------------------------------------------------------
>
> Key: WFLY-8760
> URL: https://issues.jboss.org/browse/WFLY-8760
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Lin Gao
> Priority: Critical
>
> There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission.
> That means:
> * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission)
> ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator.
> * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8760) get method of ModuleClassLoaderLocator requires createClassLoader permission
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-8760?page=com.atlassian.jira.plugin.... ]
Lin Gao updated WFLY-8760:
--------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/10133
> get method of ModuleClassLoaderLocator requires createClassLoader permission
> ----------------------------------------------------------------------------
>
> Key: WFLY-8760
> URL: https://issues.jboss.org/browse/WFLY-8760
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Lin Gao
> Priority: Critical
>
> There is missing doPriviliged block in ModuleClassLoaderLocator. Fix of WFLY-7412 for ModuleClassLoaderLocator introduces new CombinedClassLoader innner class which extends SecureClassLoader. Initialization of this class needs to createClassLoader RuntimePermission.
> That means:
> * All deployment which uses API which internally uses ModuleClassLoaderLocator needs createClassLoader RuntimePermission (which is new in EAP 7.1, the same deployments in EAP 7.0 does not need this permission)
> ** i.e. getMappingContext(String mappingType) in org.jboss.security.plugins.mapping.JBossMappingManager works internally with ModuleClassLoaderLocator.
> * setting createClassLoader RuntimePermission for deployment can be dangerous and it should probably use own permission
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8875) Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-8875?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-8875:
-------------------------------
Environment: Deploy test-case.ear to reproducer
> Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-8875
> URL: https://issues.jboss.org/browse/WFLY-8875
> Project: WildFly
> Issue Type: Enhancement
> Components: EE, EJB
> Affects Versions: 11.0.0.Alpha1
> Environment: Deploy test-case.ear to reproducer
> Reporter: Brad Maxwell
> Priority: Minor
> Attachments: test-case.ear
>
>
> If an EJB client tries to use @EJB to inject an EJB Local Proxy and the Local interface is in two different classloaders/modules/sub-deployments, it throws the error below. It would be helpful for the user to identify the issue if the exception indicated multiple classloaders or class HelloWorld is loaded from multiple modules or class cast exception.
> {code}
> Caused by: java.lang.IllegalArgumentException: Can not set example.api.HelloWorld field example.client.ClientSingleton.helloWorld to example.api.HelloWorld$$$view1
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
> at java.lang.reflect.Field.set(Field.java:764)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:106)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 26 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8875) Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-8875?page=com.atlassian.jira.plugin.... ]
Brad Maxwell updated WFLY-8875:
-------------------------------
Attachment: test-case.ear
> Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-8875
> URL: https://issues.jboss.org/browse/WFLY-8875
> Project: WildFly
> Issue Type: Enhancement
> Components: EE, EJB
> Affects Versions: 11.0.0.Alpha1
> Reporter: Brad Maxwell
> Priority: Minor
> Attachments: test-case.ear
>
>
> If an EJB client tries to use @EJB to inject an EJB Local Proxy and the Local interface is in two different classloaders/modules/sub-deployments, it throws the error below. It would be helpful for the user to identify the issue if the exception indicated multiple classloaders or class HelloWorld is loaded from multiple modules or class cast exception.
> {code}
> Caused by: java.lang.IllegalArgumentException: Can not set example.api.HelloWorld field example.client.ClientSingleton.helloWorld to example.api.HelloWorld$$$view1
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
> at java.lang.reflect.Field.set(Field.java:764)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:106)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 26 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8875) Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-8875:
----------------------------------
Summary: Improve exception when injecting EJB Local Interface Proxy loaded from two different classloaders
Key: WFLY-8875
URL: https://issues.jboss.org/browse/WFLY-8875
Project: WildFly
Issue Type: Enhancement
Components: EE, EJB
Affects Versions: 11.0.0.Alpha1
Reporter: Brad Maxwell
Priority: Minor
If an EJB client tries to use @EJB to inject an EJB Local Proxy and the Local interface is in two different classloaders/modules/sub-deployments, it throws the error below. It would be helpful for the user to identify the issue if the exception indicated multiple classloaders or class HelloWorld is loaded from multiple modules or class cast exception.
{code}
Caused by: java.lang.IllegalArgumentException: Can not set example.api.HelloWorld field example.client.ClientSingleton.helloWorld to example.api.HelloWorld$$$view1
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:167)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:171)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:81)
at java.lang.reflect.Field.set(Field.java:764)
at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:106)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.weld.interceptors.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
... 26 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8874) jmx: java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFLY-8874?page=com.atlassian.jira.plugin.... ]
Gaétan QUENTIN updated WFLY-8874:
---------------------------------
Description:
Launching wildfly with these options:
JAVA_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xbootclasspath/p:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final.jar -Djboss.modules.system.pkgs=org.jboss.logmanager -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl '
will result in this error:
[Loaded org.jboss.as.server.Main from jar:file:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-2.2.0.Final.jar!/]
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:505)
Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level
was:
Launching wildfly with these options:
JAVA_JMX_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xbootclasspath/p:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final.jar -Djboss.modules.system.pkgs=org.jboss.logmanager -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl '
will result in this error:
[Loaded org.jboss.as.server.Main from jar:file:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-2.2.0.Final.jar!/]
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:505)
Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level
> jmx: java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
> ---------------------------------------------------------------
>
> Key: WFLY-8874
> URL: https://issues.jboss.org/browse/WFLY-8874
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.1.0.Final
> Environment: java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
> ubuntu 17.04
> Reporter: Gaétan QUENTIN
> Assignee: Kabir Khan
>
> Launching wildfly with these options:
> JAVA_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xbootclasspath/p:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final.jar -Djboss.modules.system.pkgs=org.jboss.logmanager -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl '
> will result in this error:
> [Loaded org.jboss.as.server.Main from jar:file:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-2.2.0.Final.jar!/]
> Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:505)
> Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8874) jmx: java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
by Gaétan QUENTIN (JIRA)
Gaétan QUENTIN created WFLY-8874:
------------------------------------
Summary: jmx: java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
Key: WFLY-8874
URL: https://issues.jboss.org/browse/WFLY-8874
Project: WildFly
Issue Type: Bug
Components: JMX
Affects Versions: 10.1.0.Final
Environment: java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
ubuntu 17.04
Reporter: Gaétan QUENTIN
Assignee: Kabir Khan
Launching wildfly with these options:
JAVA_JMX_OPTS='-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Xbootclasspath/p:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final.jar -Djboss.modules.system.pkgs=org.jboss.logmanager -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl '
will result in this error:
[Loaded org.jboss.as.server.Main from jar:file:/opt/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/server/main/wildfly-server-2.2.0.Final.jar!/]
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:505)
Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1592) Deleted facts retained in memory, but removed after (de)serialization
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1592?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1592:
-----------------------------------
Sprint: 2017 Week 22-23 (was: 2017 Week 22-23)
> Deleted facts retained in memory, but removed after (de)serialization
> ---------------------------------------------------------------------
>
> Key: DROOLS-1592
> URL: https://issues.jboss.org/browse/DROOLS-1592
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Nikolay Plekhanov
> Assignee: Mario Fusco
> Fix For: 7.1.0.Beta3
>
> Attachments: drools-memleak.zip
>
>
> Given:
> two agenda groups: A1 and A2.
> Rule R1 in agenda group A1 and rule R2 in agenda group A2.
> R1 matches facts of type T1, deletes them and creates facts of type T2.
> R2 matches facts of type T2 and does soemthing with them (it doesn't matter, because issue happens even if R2 never fired).
> Scenario:
> * Create session, add R1 and R2 rules
> * add some facts of T1 type
> * set focus on A1 agenda group
> * invoke "fireAllRules" method
> * Invoke "getObjects" and assure that session contains only T2 facts
> * analyze objects in memory (by jmap + memory analyzing tool or just traversing references by reflection) and assure that T1 facts are still reachable via session object.
> * serialize session using marshaller and deserialize in again
> * analyze deserialized session and see that it doesn't contain T1 fact references anymore.
> Thoughts:
> I assumed that T1 references storing is feature, because they can be necessary in some cases (like reverse of their deletion due to logical inversion of truth - not sure, but maybe), but T1 deletion after (de)serialization points out the opposite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1583) Refactor KnowledgeBaseImpl
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1583?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1583:
-----------------------------------
Sprint: 2017 Week 22-23 (was: 2017 Week 22-23)
> Refactor KnowledgeBaseImpl
> --------------------------
>
> Key: DROOLS-1583
> URL: https://issues.jboss.org/browse/DROOLS-1583
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Matteo Mortari
>
> It is required to review the KnowledgeBaseImpl and lower the technical debt accumulated on it by:
> # Remove unnecessary duplicated methods that at the moment are there only for backward compatibility reasons.
> # Review the locks and in particular check if some of them can be removed since now the kbase changes are enqueued.
> # Review the rules/packages addition lifecycle emitting events before and after them (and in general reviewing the existing events).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months