[JBoss JIRA] (WFLY-875) Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
by Sławomir Wojtasiak (JIRA)
[ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.s... ]
Sławomir Wojtasiak commented on WFLY-875:
-----------------------------------------
Yes the problem still exists, but in a bit different form. Make the method public and everything should be OK and remember that only method annotations works in this specific case.
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-875
> URL: https://issues.jboss.org/browse/WFLY-875
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss 7.1.1
> Reporter: Sławomir Wojtasiak
> Assignee: Stuart Douglas
> Labels: rhq
> Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
> @Override
> public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
> configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
> configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
> if(description.isPassivationApplicable()) {
> configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
> }
> configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
> }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE}
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer’s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel}
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-111) Add "PathAddress getCurrentAddress()" to OperationContext
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-111:
---------------------------------------
Summary: Add "PathAddress getCurrentAddress()" to OperationContext
Key: WFCORE-111
URL: https://issues.jboss.org/browse/WFCORE-111
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
There's a ton of this in OSH implementations:
PathAddress.pathAddress(operation.require(ModelDescriptionConstants.OP_ADDR))
which should be replaced with
context.getCurrentAddress()
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (DROOLS-573) Kie Server: bugs and enhancements
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-573?page=com.atlassian.jira.plugin... ]
Petr Široký edited comment on DROOLS-573 at 9/16/14 4:58 PM:
-------------------------------------------------------------
Currently there is no way to create stateless KieSession, server will always call newKieSession() no matter what is defined in kmodule.xml. As discussed over e-mail, this is bug and Edson is planning to fix it. Commenting here just to be sure it does not get forgotten.
was (Author: psiroky-redhat.com):
Currently there is now way to create stateless KieSession, server will always call newKieSession() no matter what is defined in kmodule.xml. As discussed over e-mail, this is bug and Edson is planning to fix it. Commenting here just to be sure it does not get forgotten.
> Kie Server: bugs and enhancements
> ---------------------------------
>
> Key: DROOLS-573
> URL: https://issues.jboss.org/browse/DROOLS-573
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.Beta1
> Reporter: Petr Široký
> Assignee: Edson Tirelli
>
> As discussed with Edson, I am creating list of possible bugs and enhancements for the KIE Server.
> Bugs:
> * Server returns NPE when the request body is empty (and is required). This happens for example when creating new container using /container/{id}, but not providing any data within the body (the XML/JSON specifying release-id, etc).
> * The server returns 201 (Created) even when the container was not actually created. Easy reproducer: try to create container using non-existing kjar GAV. The response code will be 201 and the response will be failure with message "Failed to create container 1...."
> Enhancements:
> * I think it it would useful to move the KieServer interface into -api module so that user's can use e.g. RestEasy ClientProxy to create own REST client in case the don't want to use the provided client.
> * When deplying the WAR into EAP 6.3.0 warning is dispalyed: JBAS016012: Deployment deployment "kie-server.war" contains CDI annotations but beans.xml was not found. The WAR file should contain beans.xml.
> The description will be updated if I found more such bugs/enhancements.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Michael Hauke (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Michael Hauke edited comment on WFLY-3189 at 9/16/14 3:46 PM:
--------------------------------------------------------------
Hi Rob,
as far as I see all the failed tests are in "testsuite/integration/smoke" and relate to "jboss-ejb-clustering_1_0.xsd", added by the pull request.
"testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/subsystem/xml/StandardConfigsXMLValidationUnitTestCase.java" has a static initializer, which adds some XSD to a set called "EXCLUDED_SCHEMA_FILES", starting here: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/smok..., with a reference to a Bug in Xercesj, including "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_*.xsd" and so on, i.e. probably all the schemata redefining the "javaee" name space.
I added "jboss-ejb-clustering_1_0.xsd" to this set and ran the tests in "testsuite/integration/smoke" and got no failures, Maven says: "Tests run: 109, Failures: 0, Errors: 0, Skipped: 2". I don't know what's about the skipped tests.
I'd propose to add "jboss-ejb-clustering_1_0.xsd" to the excluded XSD. I don't know how to amend your pull request to include that. Maybe you could do that?
was (Author: mhauke):
Hi Rob,
as far as I see all the failed tests are in "testsuite/integration/smoke" and relate to "jboss-ejb-clustering_1_0.xsd", added by the pull the request.
"testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/subsystem/xml/StandardConfigsXMLValidationUnitTestCase.java" has a static initializer, which adds some XSD to a set called "EXCLUDED_SCHEMA_FILES", starting here: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/smok..., with a reference to a Bug in Xercesj, including "jboss-ejb3-2_0.xsd", "jboss-ejb3-spec-2_0.xsd", "jboss-ejb-security_*.xsd" and so on, i.e. probably all the schemata redefining the "javaee" name space.
I added "jboss-ejb-clustering_1_0.xsd" to this set and ran the tests in "testsuite/integration/smoke" and got no failures, Maven says: "Tests run: 109, Failures: 0, Errors: 0, Skipped: 2". I don't know what's about the skipped tests.
I'd propose to add "jboss-ejb-clustering_1_0.xsd" to the excluded XSD. I don't know how to amend your pull request to include that. Maybe you could do that?
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
> Attachments: p.patch
>
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years