[JBoss JIRA] (WFLY-4399) TransactionSynchronizationRegistry gets not propagated to @Asynchronous EJB
by Thomas Veith (JIRA)
Thomas Veith created WFLY-4399:
----------------------------------
Summary: TransactionSynchronizationRegistry gets not propagated to @Asynchronous EJB
Key: WFLY-4399
URL: https://issues.jboss.org/browse/WFLY-4399
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 8.2.0.Final
Reporter: Thomas Veith
When calling a method of an @Asynchronous EJB (in the same transaction), the TransactionSynchronizationRegistry is not propagated to the asynchronousBean.
e.g. when I store a value in the TransactionSynchronizationRegistry of the caller (registry.putResource()), in the callee it is null.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-3657:
-------------------------------------
Assignee: Alessio Soldano (was: Jim Ma)
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-2129:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2129
> URL: https://issues.jboss.org/browse/WFLY-2129
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Environment: Mac OS X
> Reporter: Nicky Mølholm
> Assignee: Jim Ma
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc)
> A simple EJB with a Web service view can illustrate the first problem:
> {code:java}
> @Stateless
> @WebService
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> @PermitAll // <-- This doesn't work
> //@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> // <--- unless you put them on class level
> public String sayHello(String name) {
> System.out.println("******** Greeter.sayHello(" + name + ")");
> return "Hello " + name;
> }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll,@DenyAll,@RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano reassigned WFLY-3657:
-------------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Jim Ma
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1119) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1119?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-1119:
-------------------------------------
Hi Amos, I think if the setting is "1" we should leave it alone. I think we should only do this if the entry is empty. Perhaps by default we should remove the node-identifier="1" from the standalone.xml so the new behaviour activates by default. Remember we need to make this a true uuid. Take a look at our UID implementation - remember it needs to go in the Xids we create and I think there is a max length for node-name so will need to verify that one of those will fit in before we proceed.
It would be good to be able to verify that no other server has the same node id somehow if that is possible with DMR to check attributes of other servers.
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: WFLY-1119
> URL: https://issues.jboss.org/browse/WFLY-1119
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Clebert Suconic
> Assignee: Amos Feng
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Tobias Rötschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Tobias Rötschke edited comment on WFLY-4384 at 3/3/15 3:44 AM:
---------------------------------------------------------------
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent threads, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
Whether or not this issue is a bug depends on who is responsible for attaching the invoked thread to the transaction of the invoker. In my opinion the JSR-236-implementation is, otherwise USE_TRANSACTION_OF_EXECUTION_THREAD wouldn't make much sense to me. If the application has to take care of it, what is the point of this execution property? We might still be wrong in the way we use that implementation though.
was (Author: tobias.roetschke):
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent threads, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Tobias Rötschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Tobias Rötschke edited comment on WFLY-4384 at 3/3/15 3:33 AM:
---------------------------------------------------------------
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent threads, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
was (Author: tobias.roetschke):
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent thread, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4384) ContextService (JSR236): transactional context always suspended
by Tobias Rötschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-4384?page=com.atlassian.jira.plugin.... ]
Tobias Rötschke commented on WFLY-4384:
---------------------------------------
Please let me eloborate on Maxim's question. What we are trying to do, is to execute code in concurrent thread, but within the same transaction. Our guiding example is Gupta's "Java EE 7 Essentials", chapter 10. I understand that invoking the contextual object -- not creating it -- is influenced by the USE_TRANSACTION_OF_EXECUTION_THREAD property value. That results from the beforeProxyMethod() of the TransactionSetupProviderImpl class. However, the code seemingly expects that the thread, where the proxy method is executed in, is already attached to the transaction of the invoking thread.
This turns out not be the case in our setting. As you point out, ManagedExecutorService runs in an internal thread outside a transaction. So we used Executors.newFixedThreadPool() instead as in Gupta's example. We passed the default ManagedThreadFactory to this method. We supplied the contextual object with the TransactionManager injected to the class inside the invoking thread. We verified that the contextual object is invoked directly from the invoking thread. However, TransactionManager.getTransaction() yielded null inside the thread of the contextual object.
Question is: What are we supposed to do in order to attach the thread of the contextual object to the transaction of the invoking thread in the first place so that TransactionSetupProviderImpl.beforeProxy does what it is meant to do? Unfortunately, the javadoc example you cited did not help to explain that to us.
> ContextService (JSR236): transactional context always suspended
> ---------------------------------------------------------------
>
> Key: WFLY-4384
> URL: https://issues.jboss.org/browse/WFLY-4384
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Maxim Frolov
> Assignee: Eduardo Martins
> Priority: Critical
>
> According to §3.3.5 of JSR-236 specification:
> ??By using an execution property when creating the contextual proxy object, application components can choose to not suspend the transactional context on the thread ...??
> Given the following EJB and Task:
> {code:java}
> @WebService(serviceName = "Jsr236WebService")
> @Stateless
> public class Jsr236WebService {
> @Inject Jsr236ManagedTask jsr236ManagedTask;
> @Resource ManagedExecutorService executor;
> @Resource ContextService contextService;
>
> @WebMethod(operationName = "hello")
> public String hello(@WebParam(name = "name") String txt) {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> Future<String> future = executor.submit(
> contextService.createContextualProxy(jsr236ManagedTask, execProps, Callable.class));
> try {
> return future.get();
> } catch (InterruptedException | ExecutionException e) {
> throw new RuntimeException(e);
> }
> }
> }
> {code}
> {code:java}
> @Dependent
> @Transactional(Transactional.TxType.MANDATORY)
> public class Jsr236ManagedTask implements Callable<String>, ManagedTask {
> @Override
> public String call() {
> return "called";
> }
> @Override
> public Map<String, String> getExecutionProperties() {
> Map<String, String> execProps = new HashMap<>();
> execProps.put(ManagedTask.TRANSACTION, ManagedTask.USE_TRANSACTION_OF_EXECUTION_THREAD);
> return execProps;
> }
> }
> {code}
> When the {{call()}} Method of the task is called the following exception occurs:
> {noformat}
> javax.transaction.TransactionalException: ARJUNA016110: Transaction is required for invocation
> {noformat}
> See maven test project [https://github.com/wrungel/bugs/tree/master/jsr236-test] on GitHub.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1910:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1189839|https://bugzilla.redhat.com/show_bug.cgi?id=1189839] from POST to MODIFIED
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months