[weld-issues] [JBoss JIRA] Updated: (CDITCK-221) Synchronization bug in testXScopeActiveDuringCallToEjbTimeoutMethod tests

[Pete Muir (JIRA)]

 [ 
https://issues.jboss.org/browse/CDITCK-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pete Muir updated CDITCK-221:
-

Fix Version/s: 1.0.5.CR1


David, I will exclude these. Do you have a full list of affected tests?

 Synchronization bug in testXScopeActiveDuringCallToEjbTimeoutMethod tests
 ---

 Key: CDITCK-221
 URL: https://issues.jboss.org/browse/CDITCK-221
 Project: CDI TCK
  Issue Type: Bug
  Security Level: Public(Everyone can see) 
  Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
 Fix For: 1.0.5.CR1


 Waiting on either climbed or descended just tests that the timeout method was 
 entered but does not guarantee the end of the method was reached and the 
 proper state was set in the other variables.  These tests will occasionally 
 fail for this timing issue.
 Though not fancy, this kind of synchronization can work.  We just need to 
 move these variables to the end of the timeout method.  That will guarantee 
 that when either climbed or descended are set to true the other variables are 
 also in a testable state.
 {code}
 @Timeout
public void timeout(Timer timer)
{
   if (beanManager.getContext(ApplicationScoped.class).isActive())
   {
  applicationScopeActive = true;
  if (beanId  0.0)
  {
 if (beanId == simpleApplicationBeanInstance.get().getId())
 {
sameBean = true;
 }
  }
  else
  {
 beanId = simpleApplicationBeanInstance.get().getId();
  }
   }
   // applicationScopeActive, beanId and sameBean have been set and are 
 testable
   if (timer.getInfo().equals(CLIMB_COMMAND))
   {
  climbed = true;
   }
   if (timer.getInfo().equals(DESCEND_COMMAND))
   {
  descended = true;
   }
}
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues

[weld-issues] [JBoss JIRA] Created: (WELD-930) Producer is made an alternative if the declaring bean class is an alternative

[Alexey Kazakov (JIRA)]

Producer is made an alternative if the declaring bean class is an alternative
-

 Key: WELD-930
 URL: https://issues.jboss.org/browse/WELD-930
 Project: Weld
  Issue Type: Bug
  Components: Producers (Methods, Fields and Disposers)
Affects Versions: 1.1.0.Final
Reporter: Alexey Kazakov


I'm looking at examples from 
https://github.com/pmuir/jboss-as-developer-guide/tree/master/quickstarts

There is org.jboss.as.quickstarts.login.EJBUserManager:

{code:title=org.jboss.as.quickstarts.login.EJBUserManager|borderStyle=solid}
...
@Named(userManager)
@RequestScoped
@Alternative
@Stateful
public class EJBUserManager implements UserManager {
...
@Produces
@Named
@RequestScoped
public ListUser getUsers() throws Exception {
...
}
...
}
{code}

And there is also another bean 
org.jboss.as.quickstarts.login.ManagedBeanUserManager:

{code:title=org.jboss.as.quickstarts.login.ManagedBeanUserManager|borderStyle=solid}
...
@Named(userManager)
@RequestScoped
public class ManagedBeanUserManager implements UserManager {

   @SuppressWarnings(unchecked)
   @Produces
   @Named
   @RequestScoped
   public ListUser getUsers() throws Exception {
   ...
   }
...
}
{code}

This code works in Weld even if EJBUserManager.getUsers() is not annotated 
@Alternative. But regarding the spec such a method has an ambiguous EL name 
users:

{quote}
5.3.1. Ambiguous EL names
An ambiguous EL name exists in an EL expression when an EL name resolves to 
multiple beans. When an ambiguous EL
name exists, the container attempts to resolve the ambiguity. If any of the 
beans are alternatives, the container eliminates
all beans that are not alternatives, *except for producer methods and fields of 
beans that are alternatives*. If there is exactly
one bean remaining, the container will select this bean, and the ambiguous EL 
name is called resolvable.
{quote}

There is a comment from Pete Muir:
{quote}
This looks to me like a bug in Weld (one that crept in from a pre-final spec 
revision) - that it checks if the declaring bean class is an alternative, and 
if it is, makes the producer an alternative. Can you file a WELD issue for 
this? I'll update the quickstart to explicitly make the producer an alternative.

Pete
{quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues