[JBoss JIRA] (WFLY-4127) @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-4127?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-4127:
------------------------------------
[~swd847] Well, I see no active transaction. But it seems that it's not a regression - changing the default value from REQUIRED to NOT_SUPPORTED just revealed that {{org.jboss.as.ejb3.component.EJBComponentCreateService}} does not consider non-public lifecycle callback methods when building transaction attributes map and so the default value is applied (it was originally REQUIRED and that's the reason why the TCK test passed before).
See alse EJB 3.2 spec, section 8.3.7 "Specification of the Transaction Attributes for a Bean’s Methods":
{quote}
For a stateful session bean, the transaction attributes are specified for the PostConstruct, PreDestroy, PrePassivate or PostActivate lifecycle callback interceptor methods, if any.
{quote}
And Interceptors 1.2 spec, section 2.6 "Interceptors for Lifecycle Event Callbacks":
{quote}
Lifecycle callback interceptor methods can have public, private, protected, or package level access.
{quote}
Anyway, I'm not also sure whether NOT_SUPPORTED should be the default value for SFSB (see my comment about {{StatefulComponentDescription}} in the description).
> @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback
> ----------------------------------------------------------------------
>
> Key: WFLY-4127
> URL: https://issues.jboss.org/browse/WFLY-4127
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Martin Kouba
> Assignee: Stuart Douglas
>
> This is a regression introduced in this commit:
> https://github.com/wildfly/wildfly/commit/456a624d98eaa5f5fc016ad75202901...
> Most probably {{StatefulComponentDescription}} should not pass treatRequiredAsRequiresNew=false to {{org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.Factory}} constructor.
> There is a CDI TCK test which can be used as a reproducer:
> https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1127593|https://bugzilla.redhat.com/show_bug.cgi?id=1127593] from POST to MODIFIED
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4013) The value of the bound attribute in socket-binding-group messaging is always false
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4013?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4013:
-----------------------------------------------
Ondřej Kalman <okalman(a)redhat.com> changed the Status of [bug 1156360|https://bugzilla.redhat.com/show_bug.cgi?id=1156360] from ON_QA to VERIFIED
> The value of the bound attribute in socket-binding-group messaging is always false
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4013
> URL: https://issues.jboss.org/browse/WFLY-4013
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: JBoss AS7 7.2.0.Final
> Environment: JBoss EAP 6.3.1.
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> The value of bound attribute in messaging socket group is always false.
> {noformat}
> /socket-binding-group=standard-sockets/socket-binding=messaging:read-resource(include-runtime=true, recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "bound" => false,
> "bound-address" => undefined,
> "bound-port" => undefined,
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => undefined,
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "messaging",
> "port" => 5445
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Heiko Braun edited comment on WFCORE-208 at 12/3/14 5:54 AM:
-------------------------------------------------------------
the whole point of this exercise is to be able to derive resource-descriptions for singleton resources
which may, or may not exist (have been added yet). as such the respoonse needs to include the child information regardless if the singleton resource is given or not
was (Author: heiko.braun):
the whole point of this exercise is to be able to derive resource-descriptions for singleton resources
which may, or may not exist (have been added yet). as such the respoonse needs to include the child information regardless if the singleton resource is given (has been added yet) or not
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-208) Expose 'singleton' type information in read-children-types
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFCORE-208?page=com.atlassian.jira.plugin... ]
Heiko Braun commented on WFCORE-208:
------------------------------------
the whole point of this exercise is to be able to derive resource-descriptions for singleton resources
which may, or may not exist (have been added yet). as such the respoonse needs to include the child information regardless if the singleton resource is given (has been added yet) or not
> Expose 'singleton' type information in read-children-types
> ----------------------------------------------------------
>
> Key: WFCORE-208
> URL: https://issues.jboss.org/browse/WFCORE-208
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 1.0.0.Beta1
>
>
> Management clients need a mechanism to disambiguate between cases where a management resource registration exists for a a wildcard PathElement (e.g. PathElement.pathElement("service"), represented in CLI syntax as service=*) versus for a fully specified PathElement (e.g. PathElement.pathElement("service", "remote"), represented as service=remote). In the fully specified case they need to be able to see the full path element when querying for types using the read-children-types operation.
> The term we have reached consensus on for describing registrations against a non-wildcard PathElement is a 'singleton'. The registration represents a type, and since within the context of its parent only one address will be valid for that type, that type has a singleton nature.
> The task here is to add a new boolean parameter to the read-children-types operation, "include-singletons". The parameter will be optional, default value of 'false', which will result in unchanged default behavior from what exists in WF 8.x and earlier.
> If the "include-singletons" parameter is set to "true", the operation result will include the full key/value pair for any singleton registration. So, if a parent registration had children registered under "service=remote" and "service=async", the result for the existing operation would be:
> {code}
> "result"=> ["service"]
> {code}
> If the "include-singletons" parameter was set to 'true' it would be:
> {code}
> "result"=> ["service=remote", "service=async"]
> {code}
> Note that the elements in the above result list are not ModelType.PROPERTY. They are STRING. The result type for read-children-types is always LIST of STRING.
> The '=' char is illegal in the key portion of a PathElement, so a client invoking read-children-types can safely assume that the presence of an '=' char in an element in the result denotes a singleton type, and that the first such char in any element represents the end of the 'key' portion of the registration's PathElement and the portion after that first char represents the value portion of the PathElement.
> Note also that there is no simple element "service" in the above result. *If "include-singletons" is "true" a non-fully-qualified type (i.e. just key instead of key=value) will only appear in the result if there is a wildcard registration for that key.*
> However, it is possible to have both "key" and one or more "key=xxx" in the same result. This can occur in the case of override registrations, for example what we use with datasources. There is a base type for datasources, but then additional datasource-specific registrations get added to support exposing additional vendor-specific metrics. In such situations, the response with "include-singletons=true" will look like this:
> {code}
> "result"=> ["datasource", "datasource=ExampleDS"]
> {code}
> A client that sees both "key" and "key=xxx" in a result can safely assume that "key=xxx" represents an override registration, overriding the basic type registered under "key=*".
> Note there is no guarantee as to ordering in the list, i.e. the above example could also look like this:
> {code}
> "result"=> ["datasource=ExampleDS", "datasource"]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (DROOLS-660) dead lock in fastFindClass method in PackageClassLoader extends ClassLoader implements FastClassLoader
by chi chi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-660?page=com.atlassian.jira.plugin... ]
chi chi commented on DROOLS-660:
--------------------------------
public Class<?> fastFindClass( final String name ) {
lock.lock();
Class<?> cls = findLoadedClass( name );
if (cls == null) {
final byte[] clazzBytes = this.store.read( convertClassToResourcePath( name ) );
if (clazzBytes != null) {
String pkgName = name.substring( 0,
name.lastIndexOf( '.' ) );
if ( getPackage( pkgName ) == null ) {
definePackage( pkgName,
"",
"",
"",
"",
"",
"",
null );
}
cls = defineClass( name,
clazzBytes,
0,
clazzBytes.length,
PROTECTION_DOMAIN );
}
if (cls != null) {
resolveClass( cls );
}
}
lock.unlock();
return cls;
}
it that ok? i find the lock has been removed in 6.2.0.Final， is that means 5.6.0Final has dead lock problem？ can i use 5.6.0 in my project?
> dead lock in fastFindClass method in PackageClassLoader extends ClassLoader implements FastClassLoader
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-660
> URL: https://issues.jboss.org/browse/DROOLS-660
> Project: Drools
> Issue Type: Feature Request
> Reporter: chi chi
> Assignee: Mark Proctor
>
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4143) Enable checkbox is ignored when replacing a disabled deployment
by Lukas Eder (JIRA)
[ https://issues.jboss.org/browse/WFLY-4143?page=com.atlassian.jira.plugin.... ]
Lukas Eder commented on WFLY-4143:
----------------------------------
In fact, as it seems, the checkbox doesn't work at all. When I replace a previously enabled application and leave the checkbox unchecked (i.e. "NOT(enable)"), the application will remain enabled, instead of disabling it...
> Enable checkbox is ignored when replacing a disabled deployment
> ---------------------------------------------------------------
>
> Key: WFLY-4143
> URL: https://issues.jboss.org/browse/WFLY-4143
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 8.2.0.Final
> Reporter: Lukas Eder
> Assignee: Heiko Braun
> Priority: Minor
>
> This can be reproduced as follows in the Deployments overview of the console application:
> - Have a disabled deployment
> - Click Replace
> - On Step 2/2, check the "Enable" checkbox
> - Save
> The deployment is still disabled
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months