[JBoss JIRA] (DROOLS-2517) NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize package
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2517?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-2517:
--------------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/1885
> NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize package
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2517
> URL: https://issues.jboss.org/browse/DROOLS-2517
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
>
> Under the conditions:
> * A rule uses a method of global variable in LHS. e.g. Person(myUtil.transform(name) == "John-san")
> * A package is serialized
> Serializing the package throws NullPointerException.
> {noformat}
> java.lang.NullPointerException: null
> at org.drools.core.base.BaseClassFieldReader.writeExternal(BaseClassFieldReader.java:196)
> at org.drools.core.base.extractors.MVELObjectClassFieldReader.writeExternal(MVELObjectClassFieldReader.java:72)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.base.ClassFieldAccessorStore$FieldLookupEntry.writeExternal(ClassFieldAccessorStore.java:384)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1413)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.base.ClassFieldAccessorStore.writeExternal(ClassFieldAccessorStore.java:61)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.definitions.impl.KnowledgePackageImpl.writeExternal(KnowledgePackageImpl.java:250)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.ArrayList.writeObject(ArrayList.java:762)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.compiler.integrationtests.SerializedPackageMergeTest.testBuildAndSerializePackagesWithGlobalMethodInLHS(SerializedPackageMergeTest.java:244)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (DROOLS-2517) NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize package
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2517?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-2517:
--------------------------------------
Summary: NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize package (was: NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize/deserialize package)
> NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize package
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2517
> URL: https://issues.jboss.org/browse/DROOLS-2517
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.7.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
>
> Under the conditions:
> * A rule uses a method of global variable in LHS. e.g. Person(myUtil.transform(name) == "John-san")
> * A package is serialized
> Serializing the package throws NullPointerException.
> {noformat}
> java.lang.NullPointerException: null
> at org.drools.core.base.BaseClassFieldReader.writeExternal(BaseClassFieldReader.java:196)
> at org.drools.core.base.extractors.MVELObjectClassFieldReader.writeExternal(MVELObjectClassFieldReader.java:72)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.base.ClassFieldAccessorStore$FieldLookupEntry.writeExternal(ClassFieldAccessorStore.java:384)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1413)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.base.ClassFieldAccessorStore.writeExternal(ClassFieldAccessorStore.java:61)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.core.definitions.impl.KnowledgePackageImpl.writeExternal(KnowledgePackageImpl.java:250)
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at java.util.ArrayList.writeObject(ArrayList.java:762)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at org.drools.compiler.integrationtests.SerializedPackageMergeTest.testBuildAndSerializePackagesWithGlobalMethodInLHS(SerializedPackageMergeTest.java:244)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (DROOLS-2517) NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize/deserialize package
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-2517:
-----------------------------------------
Summary: NullPointerException in BaseClassFieldReader.writeExternal() when a global method is used in LHS and serialize/deserialize package
Key: DROOLS-2517
URL: https://issues.jboss.org/browse/DROOLS-2517
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.7.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
Under the conditions:
* A rule uses a method of global variable in LHS. e.g. Person(myUtil.transform(name) == "John-san")
* A package is serialized
Serializing the package throws NullPointerException.
{noformat}
java.lang.NullPointerException: null
at org.drools.core.base.BaseClassFieldReader.writeExternal(BaseClassFieldReader.java:196)
at org.drools.core.base.extractors.MVELObjectClassFieldReader.writeExternal(MVELObjectClassFieldReader.java:72)
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at org.drools.core.base.ClassFieldAccessorStore$FieldLookupEntry.writeExternal(ClassFieldAccessorStore.java:384)
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1413)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at org.drools.core.base.ClassFieldAccessorStore.writeExternal(ClassFieldAccessorStore.java:61)
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at org.drools.core.definitions.impl.KnowledgePackageImpl.writeExternal(KnowledgePackageImpl.java:250)
at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1459)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1430)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at java.util.ArrayList.writeObject(ArrayList.java:762)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
at org.drools.compiler.integrationtests.SerializedPackageMergeTest.testBuildAndSerializePackagesWithGlobalMethodInLHS(SerializedPackageMergeTest.java:244)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10253:
-------------------------------------
[~mhk] Could you show us the contents of the EAR that you are deploying (output of "jar tf yourapp.ear" and also the contents of contained archives)? Mostly I am curious if there are any persistence provider jars contained in the EAR and if yes, the location in the EAR. I'm also interested in the location of the persistence.xml files in the EAR as well.
This will help me understand why your hitting this and how to responde to [~swd847] point raised in [https://github.com/wildfly/wildfly/pull/11164] about symptoms of a different problem than the pr addresses.
Thanks!
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3785) The read-feature-description output should optionally provide package requirement information
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3785?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3785:
----------------------------------------
Assignee: Brian Stansberry (was: ehsavoie Hugonnet)
> The read-feature-description output should optionally provide package requirement information
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-3785
> URL: https://issues.jboss.org/browse/WFCORE-3785
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
> This needs a bit of thought:
> 1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
> 2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
> Following from my discussion in 2) perhaps this data should be obtained from a Capability rather than from a ManagementResourceRegistration. The r-f-d handler is already reading capability data so it's not significantly harder for it to create output from that vs from the MRR.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3785) The read-feature-description output should optionally provide package requirement information
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3785?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3785:
-------------------------------------
Description:
If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
This needs a bit of thought:
1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
Following from my discussion in 2) perhaps this data should be obtained from a Capability rather than from a ManagementResourceRegistration. The r-f-d handler is already reading capability data so it's not significantly harder for it to create output from that vs from the MRR.
was:
If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
This needs a bit of thought:
1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
> The read-feature-description output should optionally provide package requirement information
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-3785
> URL: https://issues.jboss.org/browse/WFCORE-3785
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
> This needs a bit of thought:
> 1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
> 2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
> Following from my discussion in 2) perhaps this data should be obtained from a Capability rather than from a ManagementResourceRegistration. The r-f-d handler is already reading capability data so it's not significantly harder for it to create output from that vs from the MRR.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3785) The read-feature-description output should optionally provide package requirement information
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3785:
----------------------------------------
Summary: The read-feature-description output should optionally provide package requirement information
Key: WFCORE-3785
URL: https://issues.jboss.org/browse/WFCORE-3785
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
This needs a bit of thought:
1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities -- an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (WFCORE-3784) Standard WildFly Core domain.xml is missing discovery and security-manager subsystems
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3784:
----------------------------------------
Summary: Standard WildFly Core domain.xml is missing discovery and security-manager subsystems
Key: WFCORE-3784
URL: https://issues.jboss.org/browse/WFCORE-3784
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 5.0.0.Alpha4, 4.0.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
See the title. :) It looks like these subsystems got added to the list for the standalone config but not for the domain profile. Those profiles should basically match, except for details related to some aspect of domain mode (e.g. there's some minor elytron subsystems diffs due to the location of files in a domain vs standalone server.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years