[JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-3987:
---------------------------------------
[~push174] please see my last comment; if you can provider a reproducer, please attach it here and I'll have a look at it.
> Regression regarding WS Client when using header authentication
> ---------------------------------------------------------------
>
> Key: WFLY-3987
> URL: https://issues.jboss.org/browse/WFLY-3987
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A
> Reporter: Marcus Carlson
> Assignee: Alessio Soldano
>
> I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projec... for an example of how the WSDL file looks like.
> I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this:
> {noformat}
> port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo);
> {noformat}
> Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request:
> {noformat}
> ID: 1
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><AuthenticationInfo xmlns="urn:HPD_IncidentInterface_WS"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></AuthenticationInfo></soap:Header><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS"><Qualification>'Status' = "Closed"</Qualification><startRecord>0</startRecord><maxLimit>1000</maxLimit></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!):
> {noformat}
> ID: 2
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AuthenticationInfo"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> I've also tried 9.0.0.Alpha1 with same result. What could be wrong?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2021) "ls /socket-binding-group=*" should print proper error message
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2021?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-7413 to WFCORE-2021:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2021 (was: JBEAP-7413)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
(was: User Experience)
Affects Version/s: 3.0.0.Alpha12
(was: 7.1.0.DR7)
> "ls /socket-binding-group=*" should print proper error message
> --------------------------------------------------------------
>
> Key: WFCORE-2021
> URL: https://issues.jboss.org/browse/WFCORE-2021
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha12
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> "ls /socket-binding-group=*" should print proper error message. Similar operation "ls /subsystem=*" print good error message.
> {noformat}
> [standalone@localhost:9990 /] ls /subsystem=*
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0030: No resource definition is registered for address [(\"subsystem\" => \"*\")]"}}
> [standalone@localhost:9990 /] ls /socket-binding-group=*
> Exception for ls /socket-binding-group=*: java.lang.IllegalArgumentException
> [standalone@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1364:
-----------------------------------
Assignee: Maciej Swiderski (was: Mario Fusco)
> InMemorySessionFactory has apparent memory leak
> -----------------------------------------------
>
> Key: DROOLS-1364
> URL: https://issues.jboss.org/browse/DROOLS-1364
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Eli Israel
> Assignee: Maciej Swiderski
>
> I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated)
> The SessionCache properly gets rid of sessions that have hung around too long, which is great.
> But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions.
> It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
ted won edited comment on WFCORE-2011 at 11/21/16 2:24 AM:
-----------------------------------------------------------
Hi Brian, Thanks for your kind and detailed explanation!
I agree with your second comment and know and understand the features especially on exclusively working between them. I thnk it can be changed as an improvement, not a bug. Any user can get to know it is working with 'named-formatter' first and 'formatter' is working without 'named-formatter' after trying some changing and applying in the configuration. However, It makes user confuse which one is selected and will be working with just looking at the view or without specific knowledge in the situation 'formatter' and 'named-formatter' attributes are alternatives to each other but it's displayed both at the same time in CLI and admin console. It also can't apply "(include-defaults=false)" in the admin console. There is no description for which one will be affected first or some information like a priority. So we got an inquiry for this inconsistency and confusing from a user. In a view of users perspective, they can't understand where the formatter {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} is from, in this case, especially when seeing in the admin console HANDLER -> Console page (attachment). They've never defined it. Actually, it's better to display named-formatter's format.
If it is okay, I'll be happy with working for a contribution for this issue and make a PR with the hint you gave me. I really appreciate your hint and asking again. :-)
was (Author: rhn-support-jwon):
Hi Brian, Thanks for your kind and detailed explanation!
I agree with your second comment and know and understand the features especially on exclusively working between them. I thnk it can be changed as an improvement, not a bug. Any user can get to know it is working with 'named-formatter' first and 'formatter' is working without 'named-formatter' after trying some changing and applying in the configuration. However, It makes user confuse which one is selected and will be working with just looking at the view or without specific knowledge in the situation 'formatter' and 'named-formatter' attributes are alternatives to each other but it's displayed both at the same time in CLI and admin console. It also can't apply "(include-defaults=false)" in the admin console. There is no description for which one will be affected first or some information like a priority. So we got an inquiry for this inconsistency and confusing from a user. In a view of users perspective, they can't understand where the formatter "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n" is from, in this case, especially when seeing in the admin console HANDLER -> Console page (attachment). They've never defined it. Actually, it's better to display named-formatter's format.
If it is okay, I'll be happy with working for a contribution for this issue and make a PR with the hint you gave me. I really appreciate your hint and asking again. :-)
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
ted won commented on WFCORE-2011:
---------------------------------
Hi Brian, Thanks for your kind and detailed explanation!
I agree with your second comment and know and understand the features especially on exclusively working between them. I thnk it can be changed as an improvement, not a bug. Any user can get to know it is working with 'named-formatter' first and 'formatter' is working without 'named-formatter' after trying some changing and applying in the configuration. However, It makes user confuse which one is selected and will be working with just looking at the view or without specific knowledge in the situation 'formatter' and 'named-formatter' attributes are alternatives to each other but it's displayed both at the same time in CLI and admin console. It also can't apply "(include-defaults=false)" in the admin console. There is no description for which one will be affected first or some information like a priority. So we got an inquiry for this inconsistency and confusing from a user. In a view of users perspective, they can't understand where the formatter "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n" is from, in this case, especially when seeing in the admin console HANDLER -> Console page (attachment). They've never defined it. Actually, it's better to display named-formatter's format.
If it is okay, I'll be happy with working for a contribution for this issue and make a PR with the hint you gave me. I really appreciate your hint and asking again. :-)
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat}
> It is working as it is defined with colors in a console.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console.
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
> It should be fixed like below:
> {code:title=Expected result}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => undefined,
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-756) Elytron ldap-realm does not support recursive role search
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-756?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas commented on ELY-756:
----------------------------------
>From backward compatibility point of view, some standalone filter is not needed. The same "member" attribute can be used for all recursive group search.
> Elytron ldap-realm does not support recursive role search
> ---------------------------------------------------------
>
> Key: ELY-756
> URL: https://issues.jboss.org/browse/ELY-756
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Affects Versions: 1.1.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Scenario:
> LDAP can include some roles which are members of other roles. I try to assigned also these "nested roles" to user during authentication/authorization process.
> In EAP 7.0 (with PicketBox) I am able to set configuration, which allows to assign these roles to user. LdapExtLoginModule with module option {{roleRecursion}} serves for this. It uses int value which determines how many levels should be searched and assigned to user. I am not able to achieve this scenario with Elytron and its ldap-realm.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> See example of LDIF for LDAP server:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> In Elytron I am able to assigned only {{R1}} role to user jduke. Legacy solution is able to use for example {{roleRecursion=1}} which results to assign roles {{R1}} and {{R2}} to user jduke.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication
by Pushpak Sathyanarayan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.... ]
Pushpak Sathyanarayan commented on WFLY-3987:
---------------------------------------------
Hello [~asoldano] ,
Any update on this bug?Even I am facing similar issue..Let me know if any work around is available for jira.
Thanks,
Pushpak
> Regression regarding WS Client when using header authentication
> ---------------------------------------------------------------
>
> Key: WFLY-3987
> URL: https://issues.jboss.org/browse/WFLY-3987
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A
> Reporter: Marcus Carlson
> Assignee: Alessio Soldano
>
> I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projec... for an example of how the WSDL file looks like.
> I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this:
> {noformat}
> port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo);
> {noformat}
> Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request:
> {noformat}
> ID: 1
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><AuthenticationInfo xmlns="urn:HPD_IncidentInterface_WS"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></AuthenticationInfo></soap:Header><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS"><Qualification>'Status' = "Closed"</Qualification><startRecord>0</startRecord><maxLimit>1000</maxLimit></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!):
> {noformat}
> ID: 2
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AuthenticationInfo"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> I've also tried 9.0.0.Alpha1 with same result. What could be wrong?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7554?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-7554:
----------------------------------
> Singleton: @AccessTimeout and @Lock on superclass method not
> -------------------------------------------------------------
>
> Key: WFLY-7554
> URL: https://issues.jboss.org/browse/WFLY-7554
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final, 10.1.0.Final
> Environment: Win7_64, Oracle Java 8/102
> Reporter: Stefan Lindner
> Assignee: Stuart Douglas
>
> {code:java}
> @AccessTimeout(value=54321)
> class MySuperclass {
> @AccessTimeout(value=1200000000000L)
> public void whileBlocked() {....}
> }
> @Singleton
> @Startup
> @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
> @DependsOn("BenutzerControllerImpl")
> @AccessTimeout(value=54321)
> @Lock(LockType.READ)
> class MyClass extends MySuperclass {
> @Lock(LockType.WRITE)
> public void myBlocker() {....}
> }
> {code}
> Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception
> javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS
> The standard says:
> {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass).
> {quote}
> In short:
> # @AccessTimeout annotations on bean's class or method work as expected
> # Annotations on superclass do not
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7554) Singleton: @AccessTimeout and @Lock on superclass method not
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7554?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7554.
----------------------------------
Resolution: Rejected
> Singleton: @AccessTimeout and @Lock on superclass method not
> -------------------------------------------------------------
>
> Key: WFLY-7554
> URL: https://issues.jboss.org/browse/WFLY-7554
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final, 10.1.0.Final
> Environment: Win7_64, Oracle Java 8/102
> Reporter: Stefan Lindner
> Assignee: Stuart Douglas
>
> {code:java}
> @AccessTimeout(value=54321)
> class MySuperclass {
> @AccessTimeout(value=1200000000000L)
> public void whileBlocked() {....}
> }
> @Singleton
> @Startup
> @ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
> @DependsOn("BenutzerControllerImpl")
> @AccessTimeout(value=54321)
> @Lock(LockType.READ)
> class MyClass extends MySuperclass {
> @Lock(LockType.WRITE)
> public void myBlocker() {....}
> }
> {code}
> Calling method {code:java}whileBlocked{code} when another thread has called {code:java}myBlocker{code} leads to Exception
> javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on MyClass - could not obtain lock within 5000MILLISECONDS
> The standard says:
> {quote}The AccessTimeout annotation can be specified on a business method or on a bean class (or superclass).
> {quote}
> In short:
> # @AccessTimeout annotations on bean's class or method work as expected
> # Annotations on superclass do not
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months