[JBoss JIRA] (WFCORE-5044) Add org.apache.sshd:sshd-common dependency
by Ashley Abdel-Sayed (Jira)
Ashley Abdel-Sayed created WFCORE-5044:
------------------------------------------
Summary: Add org.apache.sshd:sshd-common dependency
Key: WFCORE-5044
URL: https://issues.redhat.com/browse/WFCORE-5044
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ashley Abdel-Sayed
Assignee: Darran Lofthouse
The {{org.apache.sshd:sshd-common}} artifact is required for the Elytron component upgrade containing SSH authentication changes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Andrew Marlow (Jira)
[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ]
Andrew Marlow commented on WFCORE-482:
--------------------------------------
Thanks! :-)
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.redhat.com/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5043) ColorOutputTestCase.longCommand fails if environment defines _JAVA_OPTIONS environment variable
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFCORE-5043?page=com.atlassian.jira.plug... ]
Paul Ferraro updated WFCORE-5043:
---------------------------------
Summary: ColorOutputTestCase.longCommand fails if environment defines _JAVA_OPTIONS environment variable (was: CliArgumentsTestCase.testMisspelledParameter fails if environment defines _JAVA_OPTIONS environment variable)
> ColorOutputTestCase.longCommand fails if environment defines _JAVA_OPTIONS environment variable
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-5043
> URL: https://issues.redhat.com/browse/WFCORE-5043
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> If the runtime environment defines a _JAVA_OPTIONS environment variable, java likes to output: "Picked up _JAVA_OPTIONS: ..." to the console.
> Because the testMisspelledParameter test reads the console output verbatim, it fails if the JVM outputs noise on startup.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5043) ColorOutputTestCase.longCommand fails if environment defines _JAVA_OPTIONS environment variable
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFCORE-5043?page=com.atlassian.jira.plug... ]
Paul Ferraro updated WFCORE-5043:
---------------------------------
Description:
If the runtime environment defines a _JAVA_OPTIONS environment variable, java likes to output: "Picked up _JAVA_OPTIONS: ..." to the console.
Because the longCommand test reads the console output verbatim, it fails if the JVM outputs noise on startup.
was:
If the runtime environment defines a _JAVA_OPTIONS environment variable, java likes to output: "Picked up _JAVA_OPTIONS: ..." to the console.
Because the testMisspelledParameter test reads the console output verbatim, it fails if the JVM outputs noise on startup.
> ColorOutputTestCase.longCommand fails if environment defines _JAVA_OPTIONS environment variable
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-5043
> URL: https://issues.redhat.com/browse/WFCORE-5043
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> If the runtime environment defines a _JAVA_OPTIONS environment variable, java likes to output: "Picked up _JAVA_OPTIONS: ..." to the console.
> Because the longCommand test reads the console output verbatim, it fails if the JVM outputs noise on startup.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13661) Assignment of default bean instance pools for MDBs and SLSBs is unclear
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are child bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the MessageDrivenComponentDescription and StatelessComponentDescription which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are child bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
> Assignment of default bean instance pools for MDBs and SLSBs is unclear
> -----------------------------------------------------------------------
>
> Key: WFLY-13661
> URL: https://issues.redhat.com/browse/WFLY-13661
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.1.Final
> Reporter: Richard Achmatowicz
> Assignee: Cheng Fang
> Priority: Major
>
> SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
> The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
> However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
> # XSD
> ** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
> ** there are child bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
> ** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
> # Resource Definition
> ** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
> ** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
> # AddHandler
> ** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the MessageDrivenComponentDescription and StatelessComponentDescription which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
> ** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
> # Summary
> ** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
> ** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
> So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13661) Assignment of default bean instance pools for MDBs and SLSBs is unclear
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are child bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
> Assignment of default bean instance pools for MDBs and SLSBs is unclear
> -----------------------------------------------------------------------
>
> Key: WFLY-13661
> URL: https://issues.redhat.com/browse/WFLY-13661
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.1.Final
> Reporter: Richard Achmatowicz
> Assignee: Cheng Fang
> Priority: Major
>
> SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
> The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
> However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
> # XSD
> ** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
> ** there are child bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
> ** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
> # Resource Definition
> ** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
> ** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
> # AddHandler
> ** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
> ** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
> # Summary
> ** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
> ** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
> So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13661) Assignment of default bean instance pools for MDBs and SLSBs is unclear
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
The way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
> Assignment of default bean instance pools for MDBs and SLSBs is unclear
> -----------------------------------------------------------------------
>
> Key: WFLY-13661
> URL: https://issues.redhat.com/browse/WFLY-13661
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.1.Final
> Reporter: Richard Achmatowicz
> Assignee: Cheng Fang
> Priority: Major
>
> SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
> The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
> However, the way that the configuration is currently set up to define the default-bean-pools is confusing:
> # XSD
> ** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
> ** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
> ** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
> # Resource Definition
> ** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
> ** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
> # AddHandler
> ** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
> ** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
> # Summary
> ** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
> ** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
> So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13661) Assignment of default bean instance pools for MDBs and SLSBs is unclear
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
The way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem.
The way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
> Assignment of default bean instance pools for MDBs and SLSBs is unclear
> -----------------------------------------------------------------------
>
> Key: WFLY-13661
> URL: https://issues.redhat.com/browse/WFLY-13661
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.1.Final
> Reporter: Richard Achmatowicz
> Assignee: Cheng Fang
> Priority: Major
>
> SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
> The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem. Ordinarily, one would define attributes of the EJB3SubsystemRootResource (for example) for each default bean instance pool and the attribute values would point to the actual bean instance pool which backs that particular default pool.
> The way that the configuration is currently set up to define the default-bean-pools is confusing:
> # XSD
> ** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
> ** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
> ** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
> # Resource Definition
> ** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
> ** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
> # AddHandler
> ** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
> ** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
> # Summary
> ** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
> ** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
> So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13661) Assignment of default bean instance pools for MDBs and SLSBs is unclear
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13661?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz updated WFLY-13661:
---------------------------------------
Description:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem.
The way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
was:
SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the common names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem.
The way that the configuration is currently set up to define the default-bean-pools is confusing:
# XSD
** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
# Resource Definition
** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
# AddHandler
** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
# Summary
** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
> Assignment of default bean instance pools for MDBs and SLSBs is unclear
> -----------------------------------------------------------------------
>
> Key: WFLY-13661
> URL: https://issues.redhat.com/browse/WFLY-13661
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 20.0.1.Final
> Reporter: Richard Achmatowicz
> Assignee: Cheng Fang
> Priority: Major
>
> SLSB and MDB deployments benefit from bean instance pools, a pool of stateless beans of a given type which can be used to handle incoming requests. Bean deployments can be configured to use specific bean instance pools for the bean type, default bean instance pools for the bean type or no instance pool.
> The configuration of default bean instance pools is achieved at the service level by associating a default bean instance pool service name (e.g. jboss.ejb.pool.default-slsb) with an existing bean instance pool from a bean-pool resource instance <pools><bean-instance-pools><strict-max-pool> (e.g. jboss.ejb.pool.the-bean-pool-for-the-slsb-default). However, the fixed names of the default pools need to be mapped somehow to specific bean pool resources defined in the subsystem.
> The way that the configuration is currently set up to define the default-bean-pools is confusing:
> # XSD
> ** there are no attributes on the top level subsystem element for default-slsb-instance-pool and default-mdb-instance-pool attributes, so these values cannot be set from XML
> ** there are bean-instance-pool-ref elements in the <mdb> element and the <session-beans><stateless> elements, and these bean-instance-pool-ref elements are *required*
> ** the parser takes the values from the bean-instance-pool-ref elements and uses them to initialise DEFAULT_SLSB_INSTANCE_POOL and DEFAULT_MDB_INSTANCE_POOL attribute defined in the EJB3SubsystemRootResourceDefinition via validateAndSet() methods to update the model
> # Resource Definition
> ** there are three attributes defined DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL and DEFAULT_ENTITY_INSTANCE_POOL in the EJB3 root resource definition, these attributes are registered, and whether they take a value or not is *optional*
> ** these attributes have custom read-write handlers EJB3SubsystemDefaultPoolWriteHandler.SLSB_POOL, EJB3SubsystemDefaultPoolWriteHandler.MDB_POOL, and EJB3SubsystemDefaultPoolWriteHandler.ENTITY_POOL
> # AddHandler
> ** in the add handler, there are conditions final boolean defaultSlsbPoolAvailable = model.hasDefined(DEFAULT_SLSB_INSTANCE_POOL) and final boolean defaultMdbPoolAvailable = model.hasDefined(DEFAULT_MDB_INSTANCE_POOL) which are passed into the AnnotatedEJBComponentDescriptionDeploymentProcessor which will conditionally install a service representing the default SLSB and MDB pools if the default bean pool attributes are defined and have a value
> ** NOTE: I came across this issue as this arrangement of services requires conditional capabilities to be defined
> # Summary
> ** because the bean-instance-pool-ref elements are required in the XML, and because they populate the elements DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL, it would seem that there will always initially be default pools and so these conditional checks in the add handler might not seem not necessary
> ** on the other hand, because the resource attributes DEFAULT_SLSB_INSTANCE_POOL, DEFAULT_MDB_INSTANCE_POOL are defined and have handlers, and because their values are optional, they could be set to null by the user after the server boots up, resulting in no default bean pools for subsequent deployments
> So, the EJB spec needs to be consulted to see if default-bean-instance-pools are required and if so, how we can better set up the configuration of these pools. Also, the DEAFULT_ENTITY_INSTANCE_POOL attribute does not seem to be used any more, but this could be a bug as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months