[jira] Resolved: (OWB-522) Missing updateTimeout in one of begin methods for conversation

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG resolved OWB-522.
---

   Resolution: Fixed
Fix Version/s: 1.1.0

> Missing updateTimeout in one of begin methods for conversation
> --
>
> Key: OWB-522
> URL: https://issues.apache.org/jira/browse/OWB-522
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
>
> This could cause conversion being mis-deleted by timer thread.

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

[jira] Closed: (OWB-522) Missing updateTimeout in one of begin methods for conversation

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-522.
-


> Missing updateTimeout in one of begin methods for conversation
> --
>
> Key: OWB-522
> URL: https://issues.apache.org/jira/browse/OWB-522
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.1.0, 1.0.1
>
>
> This could cause conversion being mis-deleted by timer thread.

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

[jira] Resolved: (OWB-508) Dependent scope proxies are needed to wrap the build-in beans returned from the services if they are not serializable yet

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG resolved OWB-508.
---

Resolution: Fixed

> Dependent scope proxies are needed to wrap the build-in beans returned from 
> the services if they are not serializable yet
> -
>
> Key: OWB-508
> URL: https://issues.apache.org/jira/browse/OWB-508
> Project: OpenWebBeans
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.1.0
>
>
> the 4 build-in beans in section 3.6 are passivation capable dependencies. 
> However, the actual instances returned from vender's 
> ValidatorService/SecurityService/TransactoinService some time are not 
> serializable and could cause passivation errors. 
> I would like to add dependent scope proxy around these actual instances if 
> they are not serializable, When the references get de-serialized, a new 
> actual instance will be retrieved from the corresponding service. Venders 
> should be able to override this behavior by some OWB custom property. 

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

[jira] Created: (OWB-522) Missing updateTimeout in one of begin methods for conversation

[YING WANG (JIRA)]

Missing updateTimeout in one of begin methods for conversation
--

 Key: OWB-522
 URL: https://issues.apache.org/jira/browse/OWB-522
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor
 Fix For: 1.0.1


This could cause conversion being mis-deleted by timer thread.

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

[jira] Commented: (OWB-514) Leak in ELContextStore

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978849#action_12978849
 ] 

YING WANG commented on OWB-514:
---

Hi Gurkan, I have some troube to locate AbstractOwbJsfPlugin.java and get some 
compile errors.

> Leak in ELContextStore
> --
>
> Key: OWB-514
> URL: https://issues.apache.org/jira/browse/OWB-514
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Gurkan Erdogdu
>Assignee: Gurkan Erdogdu
> Fix For: 1.1.0
>
>
> In current code, ELContextStore is leaked. When you put openwebbeans-jsf.jar 
> into server global classpath, even non OWB applications uses 
> WebBeansELResolver because it is registered in faces-config.xml.
> I will create a new JSF plugin to register WebBeansELResolver programatically 
> if application is OWB. And removing el-resolver from faces-config.xml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-508) Dependent scope proxies are needed to wrap the build-in beans returned from the services if they are not serializable yet

[YING WANG (JIRA)]

Dependent scope proxies are needed to wrap the build-in beans returned from the 
services if they are not serializable yet
-

 Key: OWB-508
 URL: https://issues.apache.org/jira/browse/OWB-508
 Project: OpenWebBeans
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor
 Fix For: 1.1.0


the 4 build-in beans in section 3.6 are passivation capable dependencies. 
However, the actual instances returned from vender's 
ValidatorService/SecurityService/TransactoinService some time are not 
serializable and could cause passivation errors. 

I would like to add dependent scope proxy around these actual instances if they 
are not serializable, When the references get de-serialized, a new actual 
instance will be retrieved from the corresponding service. Venders should be 
able to override this behavior by some OWB custom property. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-448) More changes for decorator and interceptor passivation support

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-448.
-

Resolution: Fixed

There is a limitation that abstract decorator passivation still not works. It 
is because that we use the proxy itself to store fields defined in the 
decorator. While when the proxy is serialized, javassist stream only serializes 
the common proxy related info (See SerializedProxy.java in javassist for 
details).  Hack javassit code and create our own proxy-like object might fix 
the issue but it is too dirty to try.  Not sure if using JVM proxy 
implementation works or not.

> More changes for decorator and interceptor passivation support
> --
>
> Key: OWB-448
> URL: https://issues.apache.org/jira/browse/OWB-448
> Project: OpenWebBeans
>  Issue Type: Improvement
>  Components: Interceptor and Decorators
>Affects Versions: 1.0.0-alpha-2
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.1.0
>
>
> add some serialization/deserialization code for interceptor, decorator, and 
> @EJB and some of their handlers. Note: due to the nature of abstract 
> decorator and javassist (we use a proxy object to instanciate the abstract 
> decorator class. ),  passivation of abstract decorator is not working right 
> now since the fields in the decorator((proxy object) could not be serialzed 
> by javassist.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-452) set active flag to false then context is destroyed

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-452.
-

Resolution: Fixed

> set active flag to false then context is destroyed
> --
>
> Key: OWB-452
> URL: https://issues.apache.org/jira/browse/OWB-452
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-2
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 1.0.0-alpha-3
>
>
> We should clear AbstractContext.active flag when a context is destroyed. So 
> it will not affect the next request/session run on the same thread.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-452) set active flag to false then context is destroyed

[YING WANG (JIRA)]

set active flag to false then context is destroyed
--

 Key: OWB-452
 URL: https://issues.apache.org/jira/browse/OWB-452
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0-alpha-2
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor
 Fix For: 1.0.0-alpha-3


We should clear AbstractContext.active flag when a context is destroyed. So it 
will not affect the next request/session run on the same thread.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-448) More changes for decorator and interceptor passivation support

[YING WANG (JIRA)]

More changes for decorator and interceptor passivation support
--

 Key: OWB-448
 URL: https://issues.apache.org/jira/browse/OWB-448
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Interceptor and Decorators
Affects Versions: 1.0.0-alpha-2
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor
 Fix For: 1.0.0-alpha-3


add some serialization/deserialization code for interceptor, decorator, and 
@EJB and some of their handlers. Note: due to the nature of abstract decorator 
and javassist (we use a proxy object to instanciate the abstract decorator 
class. ),  passivation of abstract decorator is not working right now since the 
fields in the decorator((proxy object) could not be serialzed by javassist.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-435) What is the expected result for following 2 decorators?

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898037#action_12898037
 ] 

YING WANG commented on OWB-435:
---

Two more questions, 

1. My UserBean is a session scope bean and my decorator has a counter to record 
times of invocations. However, the count is always 1. It seems a new 
UserDecorator1 will be created for each request.

2. Actually a new UserDecorator1 will be created whenever a UserBean's method 
is invoked, even though the method is not defined in the decorator, could we 
improve this?

@Decorator
public abstract class UserDecorator1 implements UserInterface, Serializable 
{
int count;

@Inject @Delegate @Any UserInterface ui;

public UserDecorator1() {
count = 0;
}

public String getName() {
count++;
return "UserDecorator1(" + ui.getName() + ")." + count;
}
}


> What is the expected result for following 2 decorators?
> ---
>
> Key: OWB-435
> URL: https://issues.apache.org/jira/browse/OWB-435
> Project: OpenWebBeans
>  Issue Type: Question
>  Components: Interceptor and Decorators
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
>
> While I am testing 2 decorators decorate the same getName() method of 
> UserBean, I found the result is:
> 1. "UserDecorator1(UserDecorator2(MYNAME)) "   <==  Did call 
> UserDecorator1.getName() first, but before it finishes, it recursively 
> invokes the UserDecorator2.getName() on the calling stack.
> 2. or  should the result be:
> "UserDecorator2(MYNAME)"  < should decorator2's result overwrite 
> decorator1's?
> 3. or should the result be:
> "UserDecorator2(UserDecorator1(MYNAME)) "< should decorator1's result 
> to the one used for decorator2?
> I prefer 3, but I am not sure which result is the correct one
> ===Userbean 
> public class UserBean implements UserInterface, Serializable 
> {
> public String getName()
> {
>   return "MYNAME";
> }
> }
> ===UserDecorator1 
> @Decorator
> public abstract class UserDecorator1 implements UserInterface, Serializable 
> {
>   @Inject @Delegate @Any UserInterface ui;
>   
>   public String getName() {
>   return "UserDecorator1(" + ui.getName() + ")";
>   }
> }
> ===UserDecorator2 
> @Decorator
> public abstract class UserDecorator2 implements UserInterface, Serializable 
> {
>   @Inject @Delegate @Any UserInterface ui;
>   
>   public String getName() {
>   return "UserDecorator2(" + ui.getName() + ")";
>   }
> }
> 
> 
> com.jcdi.test.UserDecorator1
> com.jcdi.test.UserDecorator2
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-435) What is the expected result for following 2 decorators?

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12897944#action_12897944
 ] 

YING WANG commented on OWB-435:
---

I know we did not break the spec ;)   But If I am a user who is not majored in 
computer science and bought 2 decorators from third parties to improve my 
current function X(),d1(X())  and  d2(X()),  I would expect if I add d1 
then d2 in the decorator list, the result should be something like d2(d1(X())). 
 I know if I change order in the beans.xml for the above test case, I could 
workaround and get the result I want. 

But for more complicated processing, changing order will not work. So are we 
saying users will never be able to get d2(d1(X())) result if they want  d1(X()) 
 and  d2(X()) work together?  

Just a few thoughts for fun ;))

> What is the expected result for following 2 decorators?
> ---
>
> Key: OWB-435
> URL: https://issues.apache.org/jira/browse/OWB-435
> Project: OpenWebBeans
>  Issue Type: Question
>  Components: Interceptor and Decorators
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
>
> While I am testing 2 decorators decorate the same getName() method of 
> UserBean, I found the result is:
> 1. "UserDecorator1(UserDecorator2(MYNAME)) "   <==  Did call 
> UserDecorator1.getName() first, but before it finishes, it recursively 
> invokes the UserDecorator2.getName() on the calling stack.
> 2. or  should the result be:
> "UserDecorator2(MYNAME)"  < should decorator2's result overwrite 
> decorator1's?
> 3. or should the result be:
> "UserDecorator2(UserDecorator1(MYNAME)) "< should decorator1's result 
> to the one used for decorator2?
> I prefer 3, but I am not sure which result is the correct one
> ===Userbean 
> public class UserBean implements UserInterface, Serializable 
> {
> public String getName()
> {
>   return "MYNAME";
> }
> }
> ===UserDecorator1 
> @Decorator
> public abstract class UserDecorator1 implements UserInterface, Serializable 
> {
>   @Inject @Delegate @Any UserInterface ui;
>   
>   public String getName() {
>   return "UserDecorator1(" + ui.getName() + ")";
>   }
> }
> ===UserDecorator2 
> @Decorator
> public abstract class UserDecorator2 implements UserInterface, Serializable 
> {
>   @Inject @Delegate @Any UserInterface ui;
>   
>   public String getName() {
>   return "UserDecorator2(" + ui.getName() + ")";
>   }
> }
> 
> 
> com.jcdi.test.UserDecorator1
> com.jcdi.test.UserDecorator2
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-435) What is the expected result for following 2 decorators?

[YING WANG (JIRA)]

What is the expected result for following 2 decorators?
---

 Key: OWB-435
 URL: https://issues.apache.org/jira/browse/OWB-435
 Project: OpenWebBeans
  Issue Type: Question
  Components: Interceptor and Decorators
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor


While I am testing 2 decorators decorate the same getName() method of UserBean, 
I found the result is:

1. "UserDecorator1(UserDecorator2(MYNAME)) "   <==  Did call 
UserDecorator1.getName() first, but before it finishes, it recursively invokes 
the UserDecorator2.getName() on the calling stack.

2. or  should the result be:
"UserDecorator2(MYNAME)"  < should decorator2's result overwrite 
decorator1's?

3. or should the result be:
"UserDecorator2(UserDecorator1(MYNAME)) "< should decorator1's result 
to the one used for decorator2?

I prefer 3, but I am not sure which result is the correct one

===Userbean 
public class UserBean implements UserInterface, Serializable 
{
public String getName()
{
return "MYNAME";
}
}
===UserDecorator1 
@Decorator
public abstract class UserDecorator1 implements UserInterface, Serializable 
{
@Inject @Delegate @Any UserInterface ui;

public String getName() {
return "UserDecorator1(" + ui.getName() + ")";
}
}
===UserDecorator2 
@Decorator
public abstract class UserDecorator2 implements UserInterface, Serializable 
{
@Inject @Delegate @Any UserInterface ui;

public String getName() {
return "UserDecorator2(" + ui.getName() + ")";
}
}


com.jcdi.test.UserDecorator1
com.jcdi.test.UserDecorator2



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-385:
--

Attachment: owb-385-2.patch

Sorry, fogot checkstyle. the second patch fixed CS issues and 2 minor bugs in 
the code. Please try this one. The reasons of using Externalizable are:

1. Java ObjectStreams will not work for proxies. So we use a wrapper to do the 
work by using javassit object streams.
2.  For performance reason, we just need to transfer passivation id instead of 
beans. (some fields of bean class is hard to be serialized).  
3. the failover bag holds a sessioncontext and a map of conversationcontexts. 
It does not handle each individual beans.

To enable, please define:

org.apache.webbeans.spi.FailOverService=org.apache.webbeans.web.failover.DefaultOwbFailOverService
org.apache.webbeans.web.failover.issupportfailover=true
org.apache.webbeans.web.failover.issupportpassivation=true

In my test, I have one proxy server =>1 cluster of 2 servers. access the 
application through the proxy server, then kill the server served the requests, 
then continue accessing the app, both session scope/conversation bean instances 
are failovered to the other server.





> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
> Attachments: owb-385-1.patch, owb-385-2.patch
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-385:
--

Attachment: owb-385-1.patch

Hi Guys, please review the changes under this bug. Basic failover /passivation 
service is added (not enabled by default) if the container is support session 
failover.  I did not have a chance to make changes for build-in beans yet. Will 
do it later. 

> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
> Attachments: owb-385-1.patch
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893213#action_12893213
 ] 

YING WANG commented on OWB-385:
---

The main target is to, at application level to config(enable/disable), allow a 
service to failover managed bean instances to other JVMs in a cluster 
environment or passivate them to other storage.  Also some owb 
contexts/managers needs to  be improved to support this (serialization 
related). 

> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893188#action_12893188
 ] 

YING WANG commented on OWB-385:
---

6.6.1 and 6.6.3 define the beans and scopes, including session scope and 
conversation scope that passivating capable.  My idea is to provide an SPI and 
a default implementation, which allow vendors to replace it with their own 
service to support failover and passivation for those beans. 

> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893030#action_12893030
 ] 

YING WANG commented on OWB-385:
---

My plan is to first add basic failover/passivation support for conversation , 
session scope beans. Then continue improving it to handle build-in beans and 
other senarios. 

> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OWB-385) implement passivation of managed beans in ServletContextListener

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG reassigned OWB-385:
-

Assignee: YING WANG  (was: Gurkan Erdogdu)

> implement passivation of managed beans in ServletContextListener
> 
>
> Key: OWB-385
> URL: https://issues.apache.org/jira/browse/OWB-385
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0-alpha-1
>Reporter: Eric Covener
>Assignee: YING WANG
> Fix For: 1.0.0-alpha-2
>
>   Original Estimate: 60h
>  Remaining Estimate: 60h
>
> Message-ID: <267326.60362...@web38203.mail.mud.yahoo.com>
> Currently we have no support for those callbacks for managed beans. Also 
> includes AroundTimeout method.
> Motivation
> --
> Actually we have 2 methods in  WebBeansConfigurationListener. Currently our 
> session and conversation context does not provided actiovation/passivation. 
> What we have to do is that we update below lifecycle callbacks to put all 
> session and conversation context instances into the session in the 
> "sessionWillPassivate" and call passivate callback, and reverse it on 
> "sessionDidActivate".
> Those areas needs some contributions :)
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionDidActivate(HttpSessionEvent event)
>{
>//TODO activation
>   //Gets all passivated instances from passivated session and restore our 
> session and conversation context.
>}
>/**
> * {...@inheritdoc}
> */
>@Override
>public void sessionWillPassivate(HttpSessionEvent event)
>{
>//TODO Passivation
>   //Gets all instances from the Session and ConversationContexts
>and add those into the session that is under passivation therefore our 
> bean instances
>are correctly passivated
>}
> Thanks;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-399) Proxy objects could not be correctly deserialized by using javassist 3.11. we need to update to 3.12

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880197#action_12880197
 ] 

YING WANG commented on OWB-399:
---

Thanks a lot , Mark.

> Proxy objects could not be correctly deserialized by using javassist 3.11. we 
> need to update to 3.12
> 
>
> Key: OWB-399
> URL: https://issues.apache.org/jira/browse/OWB-399
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: Mark Struberg
>Priority: Blocker
> Fix For: 1.0.0-CR1
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> While I am investigating owb failover / passivation support , I encountered 
> an issue that de-serialized proxy object could not delegate calls to bean 
> instance object methods. The handler field held by the proxy object ( such as 
> NormalScopeBeanInterceptorHandler we used for normal scope ) is replaced with 
> javassist default handler. 
> Sandbox tests show hat if I upgrade to javassist 3.12 and use 
> ProxyObjectInputStream/ProxyObjectOutputStream, the handler in de-serialized 
> proxy object get restored correctly.
> But 3.12 is not in jboss repository yet, anyone know if there is a way  to 
> push them update their javasssist repository? or create our own snapshot 
> repository temporarily? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-399) Proxy objects could not be correctly deserialized by using javassist 3.11. we need to update to 3.12

[YING WANG (JIRA)]

Proxy objects could not be correctly deserialized by using javassist 3.11. we 
need to update to 3.12


 Key: OWB-399
 URL: https://issues.apache.org/jira/browse/OWB-399
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.0-CR1
Reporter: YING WANG
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-CR2


While I am investigating owb failover / passivation support , I encountered an 
issue that de-serialized proxy object could not delegate calls to bean instance 
object methods. The handler field held by the proxy object ( such as 
NormalScopeBeanInterceptorHandler we used for normal scope ) is replaced with 
javassist default handler. 

Sandbox tests show hat if I upgrade to javassist 3.12 and use 
ProxyObjectInputStream/ProxyObjectOutputStream, the handler in de-serialized 
proxy object get restored correctly.

But 3.12 is not in jboss repository yet, anyone know if there is a way  to push 
them update their javasssist repository? or create our own snapshot repository 
temporarily? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-394) Any idea why our BeforeBeanDiscovery.addInterceptorBinding() has different signature?

[YING WANG (JIRA)]

Any idea why our BeforeBeanDiscovery.addInterceptorBinding() has different 
signature?
-

 Key: OWB-394
 URL: https://issues.apache.org/jira/browse/OWB-394
 Project: OpenWebBeans
  Issue Type: TCK Challenge
  Components: TCK
Affects Versions: 1.0.0-GA
Reporter: YING WANG
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0-GA


It seems we have a different signature for 
BeforeBeanDiscovery.addInterceptorBinding method.  see the link: 
http://java.sun.com/javaee/6/docs/api/javax/enterprise/inject/spi/BeforeBeanDiscovery.html.
  It seems we did change the method for about a year. So probably, it is caused 
by recent change in the spec/api?

Missing Methods
---
javax.enterprise.inject.spi.BeforeBeanDiscovery:method public 
abstract void 
javax.enterprise.inject.spi.BeforeBeanDiscovery.addInterceptorBinding(java.lang.Class)

Added Methods
-
javax.enterprise.inject.spi.BeforeBeanDiscovery:method public 
abstract !varargs void 
javax.enterprise.inject.spi.BeforeBeanDiscovery.addInterceptorBinding(java.lang.Class,java.lang.annotation.Annotation[])



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-369) Static ContextsService in ContextFactory causes wrong webContextService used for multiple applications

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-369.
-

Resolution: Fixed

> Static ContextsService in ContextFactory causes wrong webContextService used 
> for multiple applications
> --
>
> Key: OWB-369
> URL: https://issues.apache.org/jira/browse/OWB-369
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: ContextFactory.patch
>
>
> To reproduce,
> Application A, which does not support conversation, installed and tested 
> without any issue. then stop and uninstalled.
> Application B, which support conversation, get installed and started.
> When test Application B, ApplicationA's contextService is used and causes 
> conversation scope is not found since it does not support conversation.
> The problem is because of static variable used for contextsService in 
> ContextFactory which is JVM-wide and only init once. While 
> supportConversation flag is application-wide property.
> Probably we need contextService  variable to be  classloader based instead of 
> static variable. or need some change to supportsConversation flag.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (OWB-369) Static ContextsService in ContextFactory causes wrong webContextService used for multiple applications

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG reopened OWB-369:
---

  Assignee: YING WANG  (was: Gurkan Erdogdu)

Still randomly see different conversationManagers invoked for same session. Add 
2 more changes.

> Static ContextsService in ContextFactory causes wrong webContextService used 
> for multiple applications
> --
>
> Key: OWB-369
> URL: https://issues.apache.org/jira/browse/OWB-369
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: ContextFactory.patch
>
>
> To reproduce,
> Application A, which does not support conversation, installed and tested 
> without any issue. then stop and uninstalled.
> Application B, which support conversation, get installed and started.
> When test Application B, ApplicationA's contextService is used and causes 
> conversation scope is not found since it does not support conversation.
> The problem is because of static variable used for contextsService in 
> ContextFactory which is JVM-wide and only init once. While 
> supportConversation flag is application-wide property.
> Probably we need contextService  variable to be  classloader based instead of 
> static variable. or need some change to supportsConversation flag.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-370) Intransient Conversation context get rdestroyed randomly by destroyWithRespectToTimout

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-370.
-

Resolution: Fixed

> Intransient Conversation context get rdestroyed randomly by 
> destroyWithRespectToTimout
> --
>
> Key: OWB-370
> URL: https://issues.apache.org/jira/browse/OWB-370
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.0.0
>
>
> Before we put conversation context into ConversationManager's hashmap, we 
> should update the conversation's activeTime once. Else with 0 activeTime, the 
> conversation might be destroyed by timeout before we could update it in 
> afterPhase step.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-370) Intransient Conversation context get rdestroyed randomly by destroyWithRespectToTimout

[YING WANG (JIRA)]

Intransient Conversation context get rdestroyed randomly by 
destroyWithRespectToTimout
--

 Key: OWB-370
 URL: https://issues.apache.org/jira/browse/OWB-370
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: M4
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor
 Fix For: 1.0.0


Before we put conversation context into ConversationManager's hashmap, we 
should update the conversation's activeTime once. Else with 0 activeTime, the 
conversation might be destroyed by timeout before we could update it in 
afterPhase step.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-369) Static ContextsService in ContextFactory causes wrong webContextService used for multiple applications

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-369:
--

Attachment: ContextFactory.patch

Thanks Gurkan, Joe.  With Gurkan's recent changes, my second app still fails. 
How are we going to handle static ContextService in ContextFactory? I have 
uploaded this patch to replace it with local variables in the class. It might 
not be optimized, but requires minimum code changes. Please help review. Thanks 
in advance.

> Static ContextsService in ContextFactory causes wrong webContextService used 
> for multiple applications
> --
>
> Key: OWB-369
> URL: https://issues.apache.org/jira/browse/OWB-369
> Project: OpenWebBeans
>  Issue Type: Bug
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: ContextFactory.patch
>
>
> To reproduce,
> Application A, which does not support conversation, installed and tested 
> without any issue. then stop and uninstalled.
> Application B, which support conversation, get installed and started.
> When test Application B, ApplicationA's contextService is used and causes 
> conversation scope is not found since it does not support conversation.
> The problem is because of static variable used for contextsService in 
> ContextFactory which is JVM-wide and only init once. While 
> supportConversation flag is application-wide property.
> Probably we need contextService  variable to be  classloader based instead of 
> static variable. or need some change to supportsConversation flag.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-369) Static ContextsService in ContextFactory causes wrong webContextService used for multiple applications

[YING WANG (JIRA)]

Static ContextsService in ContextFactory causes wrong webContextService used 
for multiple applications
--

 Key: OWB-369
 URL: https://issues.apache.org/jira/browse/OWB-369
 Project: OpenWebBeans
  Issue Type: Bug
Affects Versions: M4
Reporter: YING WANG
Assignee: YING WANG
 Fix For: 1.0.0


To reproduce,

Application A, which does not support conversation, installed and tested 
without any issue. then stop and uninstalled.
Application B, which support conversation, get installed and started.
When test Application B, ApplicationA's contextService is used and causes 
conversation scope is not found since it does not support conversation.
The problem is because of static variable used for contextsService in 
ContextFactory which is JVM-wide and only init once. While supportConversation 
flag is application-wide property.

Probably we need contextService  variable to be  classloader based instead of 
static variable. or need some change to supportsConversation flag.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-366) ContextNotActiveException fired from AppScope/NormalScopedBeanInterceptorHandler when a proxied object finalized

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-366.
-

Fix Version/s: 1.0.0
   Resolution: Fixed

> ContextNotActiveException fired from 
> AppScope/NormalScopedBeanInterceptorHandler when a proxied object finalized
> 
>
> Key: OWB-366
> URL: https://issues.apache.org/jira/browse/OWB-366
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Interceptor and Decorators
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.0.0
>
>
> Whenever a proxied object recycled by JVM, ContextNotActiveException will be 
> fired from: 
> BeanManagerImpl.getContext(Class) line: 300   
> NormalScopedBeanInterceptorHandler.getContextualInstance() line: 105  
> NormalScopedBeanInterceptorHandler.invoke(Object, Method, Method, Object[]) 
> line: 75  
> ConversationImpl_$$_javassist_1.finalize() line: not available [local 
> variables unavailable]  
> J9VMInternals.runFinalize(Object) line: 412   
> We should directly invoke real object's finalize( ) since:
> it is not meaningful to find context in for finalize method;
> we do not know when jvm will invoke it;
> and it is out of concept of any scope.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-366) ContextNotActiveException fired from AppScope/NormalScopedBeanInterceptorHandler when a proxied object finalized

[YING WANG (JIRA)]

ContextNotActiveException fired from 
AppScope/NormalScopedBeanInterceptorHandler when a proxied object finalized


 Key: OWB-366
 URL: https://issues.apache.org/jira/browse/OWB-366
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Interceptor and Decorators
Affects Versions: M4
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor


Whenever a proxied object recycled by JVM, ContextNotActiveException will be 
fired from: 

BeanManagerImpl.getContext(Class) line: 300 
NormalScopedBeanInterceptorHandler.getContextualInstance() line: 105
NormalScopedBeanInterceptorHandler.invoke(Object, Method, Method, Object[]) 
line: 75
ConversationImpl_$$_javassist_1.finalize() line: not available [local variables 
unavailable]
J9VMInternals.runFinalize(Object) line: 412 

We should directly invoke real object's finalize( ) since:
it is not meaningful to find context in for finalize method;
we do not know when jvm will invoke it;
and it is out of concept of any scope.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-363) Intermittent bug with ApplicationScope disposers not being called

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861834#action_12861834
 ] 

YING WANG commented on OWB-363:
---

Gurkan, Joe, I took a look on the latest change. It could fix the 
applicationContext is not destroyed issue when shutting down. However, I feel 
it is still possible that wrong applicationContext gets destroyed in multiple 
applications env. such as:

T1:  Thread 1 handles App1 and have threadLocal applicationContext(app1)
T2:  Thread 2 handles App2 and have threadLocal applicationContext(app2)
T3:  app2 shutdown by admin and thread 1 handles it, since it has 
applicationContext(app1), according to current logic in 
destroyApplicationContext, app1's applicationContext get destroyed.  (I didn't 
find applicationContext get reset after each request.)

How about directly extract applicationContext from 
currentApplicationContexts(serveletContext) and do not use threadLocal one in 
destroyApplicationcontext () or make applicationContext a non-threadLocal, 
non-static variable like Joe said? 



> Intermittent bug with ApplicationScope disposers not being called
> -
>
> Key: OWB-363
> URL: https://issues.apache.org/jira/browse/OWB-363
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: M4
>Reporter: Joe Bergmark
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: 1.0.0
>
>
> While testing an application have seen an issue where disposers for 
> application scoped producer methods are not called.  Took a quick peek at the 
> WebContextService, and I suspect the ThreadLocal may not be correct for the 
> thread that is handling the application stop.
> It seems to me that we already have a 1:1 mapping of WebContextService 
> (loaded based on the classloader by WebBeansFinder) to the application, so we 
> could probably make the ApplicationContext field non-static and 
> non-threadlocal.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-312) Add dopriv's to allow OWB to function with java 2 security enabled

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12858614#action_12858614
 ] 

YING WANG commented on OWB-312:
---


To avoid this annoying "Access denied" Exceptions when java2 security enabled, 
does anyone mind if I delegate invocations of following methods to some 
SecurityUtil class and add doPrivileged guard around them?

Method.setAccess(boolean)  ==> SecurityUtil.doPrivilegedSetAccess(Method, 
boolean)
Class.setAccess(boolean)  ==> SecurityUtil.doPrivilegedSetAccess(Class, boolean)
Class.getDeclaredConstructors()  ==> 
SecurityUtil.doPrivilegedGetDeclaredConstructors(Class)
Class.getDeclaredConstructor(...)  ==> 
SecurityUtil.doPrivilegedSGetDeclaredConstructor(Class..)
Class.getDeclaredMethods()  ==> 
SecurityUtil.doPrivilegedGetDeclaredMethods(Class)
Class.getDeclaredMethod(...)  ==> 
SecurityUtil.doPrivilegedGetDeclaredMethods(Class..)
Class.getDeclaredFields()   ==> 
SecurityUtil.doPrivilegedGetDeclaredFields(Class)
Class.getDeclaredField(...)  ==> 
SecurityUtil.doPrivilegedGetDeclaredField(Class..)
ProxyFactory.createClass() ==> 
SecurityUtil.doPrivilegedGetProxyClass(ProxyFactory..)

One problem I have is the setAcess()/getDeclaredMethods() invocations in 
javax.enterprise.util.AnnotationLiteral, which is now part of geronimo jcdi 
api. Should we open a bug against geronimo?

> Add dopriv's to allow OWB to function with java 2 security enabled
> --
>
> Key: OWB-312
> URL: https://issues.apache.org/jira/browse/OWB-312
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: M4
>Reporter: Jacquelle Leggett
>Assignee: YING WANG
> Fix For: 1.0.0
>
>
> When using OWB with java 2 security enabled, my application requires the 
> following permissions:
>   permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
>   permission java.lang.RuntimePermission "accessDeclaredMembers";
>   permission java.lang.RuntimePermission "getClassLoader";
>   permission java.lang.RuntimePermission "getProtectionDomain"; 
> The associated errors do not appear to be strategic security exceptions; 
> therefore, dopriv blocks should be added to the appropriate sections of code. 
>  Adding dopriv blocks to AnnotationUtil and ClassUtil, will resolve most of 
> the issues based on the SecurityExceptions I saw.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission accessDeclaredMembers)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:108)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
>   at 
> java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1678)
>   at java.lang.Class.checkMemberAccess(Class.java:109)
>   at java.lang.Class.getDeclaredMethods(Class.java:668)
>   at 
> org.apache.webbeans.util.AnnotationUtil.hasAnnotationMember(AnnotationUtil.java:457)
>   at 
> org.apache.webbeans.container.InjectionResolver.findByQualifier(InjectionResolver.java:523)
>   at 
> org.apache.webbeans.container.InjectionResolver.implResolveByType(InjectionResolver.java:410)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OWB-312) Add dopriv's to allow OWB to function with java 2 security enabled

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG reassigned OWB-312:
-

Assignee: YING WANG  (was: Gurkan Erdogdu)

> Add dopriv's to allow OWB to function with java 2 security enabled
> --
>
> Key: OWB-312
> URL: https://issues.apache.org/jira/browse/OWB-312
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Core
>Affects Versions: M4
>Reporter: Jacquelle Leggett
>Assignee: YING WANG
> Fix For: 1.0.0
>
>
> When using OWB with java 2 security enabled, my application requires the 
> following permissions:
>   permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
>   permission java.lang.RuntimePermission "accessDeclaredMembers";
>   permission java.lang.RuntimePermission "getClassLoader";
>   permission java.lang.RuntimePermission "getProtectionDomain"; 
> The associated errors do not appear to be strategic security exceptions; 
> therefore, dopriv blocks should be added to the appropriate sections of code. 
>  Adding dopriv blocks to AnnotationUtil and ClassUtil, will resolve most of 
> the issues based on the SecurityExceptions I saw.
> java.security.AccessControlException: Access denied 
> (java.lang.RuntimePermission accessDeclaredMembers)
>   at 
> java.security.AccessController.checkPermission(AccessController.java:108)
>   at java.lang.SecurityManager.checkPermission(SecurityManager.java:533)
>   at 
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:212)
>   at 
> java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1678)
>   at java.lang.Class.checkMemberAccess(Class.java:109)
>   at java.lang.Class.getDeclaredMethods(Class.java:668)
>   at 
> org.apache.webbeans.util.AnnotationUtil.hasAnnotationMember(AnnotationUtil.java:457)
>   at 
> org.apache.webbeans.container.InjectionResolver.findByQualifier(InjectionResolver.java:523)
>   at 
> org.apache.webbeans.container.InjectionResolver.implResolveByType(InjectionResolver.java:410)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OWB-310) Drop dom4j and use jre builtin xml parsers for processing beans.xml

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG resolved OWB-310.
---

Resolution: Fixed

> Drop dom4j and use jre builtin xml parsers for processing beans.xml
> ---
>
> Key: OWB-310
> URL: https://issues.apache.org/jira/browse/OWB-310
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: XML Configuration
>Affects Versions: M4
>Reporter: Sven Linstaedt
>Assignee: YING WANG
> Fix For: 1.0.0
>
>
> To make OWB more independent of libraries, we should drop in favor of jre 
> builtin xml parsers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (OWB-310) Drop dom4j and use jre builtin xml parsers for processing beans.xml

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG reassigned OWB-310:
-

Assignee: YING WANG  (was: Gurkan Erdogdu)

Assign to Ying.

> Drop dom4j and use jre builtin xml parsers for processing beans.xml
> ---
>
> Key: OWB-310
> URL: https://issues.apache.org/jira/browse/OWB-310
> Project: OpenWebBeans
>  Issue Type: Task
>  Components: XML Configuration
>Affects Versions: M4
>Reporter: Sven Linstaedt
>Assignee: YING WANG
> Fix For: 1.0.0
>
>
> To make OWB more independent of libraries, we should drop in favor of jre 
> builtin xml parsers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (OWB-334) cid is missing when using redirect for a jsf 2.0 application

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG resolved OWB-334.
---

   Resolution: Fixed
Fix Version/s: 1.0.0

> cid is missing when using redirect for a jsf 2.0 application
> 
>
> Key: OWB-334
> URL: https://issues.apache.org/jira/browse/OWB-334
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Java EE Integration
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.0.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I have converted conversation-sample to a jsf 2 .0 application by changing 
> jsf version to 2.0 and disabling FaceletViewHandler. When I click "To Listing 
> Page", the cid is not appended after the redirect jsf url and the content 
> list in cart is empty.
> If I enable FaceletViewHandler, it works. But this depends on the default 
> behavior of FaceletViewHandler(ViewHandler in jsf2.0), which delegates 
> getRedirectURL( ) call to get getActionURL( ).
> Our ConversationAwareViewHandler shouldn't depends on FaceletViewHandler and 
> we do not have getRedirectURL( ) defined in ConversationAwareViewHandler. 
> My plan is to add getRedirectURL( ) method in ConversationAwareViewHandler, 
> which first tests if cid is already added, if not, then append cid at the end 
> of url. Thus, it will work with jsf 1.2/2.0 and w/wo  FaceletViewHandler.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (OWB-334) cid is missing when using redirect for a jsf 2.0 application

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG closed OWB-334.
-


> cid is missing when using redirect for a jsf 2.0 application
> 
>
> Key: OWB-334
> URL: https://issues.apache.org/jira/browse/OWB-334
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Java EE Integration
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
>Priority: Minor
> Fix For: 1.0.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I have converted conversation-sample to a jsf 2 .0 application by changing 
> jsf version to 2.0 and disabling FaceletViewHandler. When I click "To Listing 
> Page", the cid is not appended after the redirect jsf url and the content 
> list in cart is empty.
> If I enable FaceletViewHandler, it works. But this depends on the default 
> behavior of FaceletViewHandler(ViewHandler in jsf2.0), which delegates 
> getRedirectURL( ) call to get getActionURL( ).
> Our ConversationAwareViewHandler shouldn't depends on FaceletViewHandler and 
> we do not have getRedirectURL( ) defined in ConversationAwareViewHandler. 
> My plan is to add getRedirectURL( ) method in ConversationAwareViewHandler, 
> which first tests if cid is already added, if not, then append cid at the end 
> of url. Thus, it will work with jsf 1.2/2.0 and w/wo  FaceletViewHandler.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-334) cid is missing when using redirect for a jsf 2.0 application

[YING WANG (JIRA)]

cid is missing when using redirect for a jsf 2.0 application


 Key: OWB-334
 URL: https://issues.apache.org/jira/browse/OWB-334
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Java EE Integration
Affects Versions: M4
Reporter: YING WANG
Assignee: YING WANG
Priority: Minor


I have converted conversation-sample to a jsf 2 .0 application by changing jsf 
version to 2.0 and disabling FaceletViewHandler. When I click "To Listing 
Page", the cid is not appended after the redirect jsf url and the content list 
in cart is empty.

If I enable FaceletViewHandler, it works. But this depends on the default 
behavior of FaceletViewHandler(ViewHandler in jsf2.0), which delegates 
getRedirectURL( ) call to get getActionURL( ).

Our ConversationAwareViewHandler shouldn't depends on FaceletViewHandler and we 
do not have getRedirectURL( ) defined in ConversationAwareViewHandler. 

My plan is to add getRedirectURL( ) method in ConversationAwareViewHandler, 
which first tests if cid is already added, if not, then append cid at the end 
of url. Thus, it will work with jsf 1.2/2.0 and w/wo  FaceletViewHandler.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-321) Conversation beans could not be populated to non-faces request by a JSF redirect navigation rule

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844217#action_12844217
 ] 

YING WANG commented on OWB-321:
---

Ok, sounds good. I will keep this open.

> Conversation beans could not be populated to non-faces request by a JSF 
> redirect navigation rule
> 
>
> Key: OWB-321
> URL: https://issues.apache.org/jira/browse/OWB-321
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: owb321.patch
>
>
> I have the following JSF redirect navigation rule, which redirect a JSF page 
> to a jsp page:
>
> /cellphonebuy.xhtml
> 
> toListingPage
> /cellphonelist.jsp
> 
> 
> 
> However, in cellphonelist JSP page, I could not access beans of the 
> conversation context and "No active conversation context" Exception is 
> thrown. I do see the cid parameter being appended at the end of my jsp link. 
> According to 8th and 9th bullets under  6.7.4, a long-run conversation 
> context should be populated to non-face requests if JSF redirect is used or 
> the application generates a link with such cid parameter.  (please assign to 
> me)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-321) Conversation beans could not be populated to non-faces request by a JSF redirect navigation rule

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844204#action_12844204
 ] 

YING WANG commented on OWB-321:
---

Thanks a lot Gurkan for clarifying. I must be tooo focus on the wording. I got 
"Non-Faces request" definition from some tutorial from Sun and it says it could 
be a servlet or JSP page 
(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro10.html). 

Do you think it is appropriate to support conversation context for jsp in this 
scenario (any potential issue)? I do not want to break anything later because 
of this ;)  

> Conversation beans could not be populated to non-faces request by a JSF 
> redirect navigation rule
> 
>
> Key: OWB-321
> URL: https://issues.apache.org/jira/browse/OWB-321
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: owb321.patch
>
>
> I have the following JSF redirect navigation rule, which redirect a JSF page 
> to a jsp page:
>
> /cellphonebuy.xhtml
> 
> toListingPage
> /cellphonelist.jsp
> 
> 
> 
> However, in cellphonelist JSP page, I could not access beans of the 
> conversation context and "No active conversation context" Exception is 
> thrown. I do see the cid parameter being appended at the end of my jsp link. 
> According to 8th and 9th bullets under  6.7.4, a long-run conversation 
> context should be populated to non-face requests if JSF redirect is used or 
> the application generates a link with such cid parameter.  (please assign to 
> me)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-321) Conversation beans could not be populated to non-faces request by a JSF redirect navigation rule

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-321:
--

Attachment: owb321.patch

Could someone help review my change? Thanks in advance.

> Conversation beans could not be populated to non-faces request by a JSF 
> redirect navigation rule
> 
>
> Key: OWB-321
> URL: https://issues.apache.org/jira/browse/OWB-321
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
> Attachments: owb321.patch
>
>
> I have the following JSF redirect navigation rule, which redirect a JSF page 
> to a jsp page:
>
> /cellphonebuy.xhtml
> 
> toListingPage
> /cellphonelist.jsp
> 
> 
> 
> However, in cellphonelist JSP page, I could not access beans of the 
> conversation context and "No active conversation context" Exception is 
> thrown. I do see the cid parameter being appended at the end of my jsp link. 
> According to 8th and 9th bullets under  6.7.4, a long-run conversation 
> context should be populated to non-face requests if JSF redirect is used or 
> the application generates a link with such cid parameter.  (please assign to 
> me)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-321) Conversation beans could not be populated to non-faces request by a JSF redirect navigation rule

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843741#action_12843741
 ] 

YING WANG commented on OWB-321:
---

Thanks Sven for the info, I tested again, the reirect just works fine with cid 
appended at the end of each redirect URL. And JSF to JSF redirect also works.  

The problem only happens when the redirect URL is a Jsp(non-jsf request), in 
which case, the conversation context is not restored by WebBeansPaseListener 
since it is not a JSF page. 

Sven, do you remember if you ran jsf -> jsp redirection test?

> Conversation beans could not be populated to non-faces request by a JSF 
> redirect navigation rule
> 
>
> Key: OWB-321
> URL: https://issues.apache.org/jira/browse/OWB-321
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M4
>Reporter: YING WANG
>Assignee: YING WANG
> Fix For: 1.0.0
>
>
> I have the following JSF redirect navigation rule, which redirect a JSF page 
> to a jsp page:
>
> /cellphonebuy.xhtml
> 
> toListingPage
> /cellphonelist.jsp
> 
> 
> 
> However, in cellphonelist JSP page, I could not access beans of the 
> conversation context and "No active conversation context" Exception is 
> thrown. I do see the cid parameter being appended at the end of my jsp link. 
> According to 8th and 9th bullets under  6.7.4, a long-run conversation 
> context should be populated to non-face requests if JSF redirect is used or 
> the application generates a link with such cid parameter.  (please assign to 
> me)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-321) Conversation beans could not be populated to non-faces request by a JSF redirect navigation rule

[YING WANG (JIRA)]

Conversation beans could not be populated to non-faces request by a JSF 
redirect navigation rule


 Key: OWB-321
 URL: https://issues.apache.org/jira/browse/OWB-321
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M4
Reporter: YING WANG
Assignee: Gurkan Erdogdu


I have the following JSF redirect navigation rule, which redirect a JSF page to 
a jsp page:

   
/cellphonebuy.xhtml

toListingPage
/cellphonelist.jsp




However, in cellphonelist JSP page, I could not access beans of the 
conversation context and "No active conversation context" Exception is thrown. 
I do see the cid parameter being appended at the end of my jsp link. 

According to 8th and 9th bullets under  6.7.4, a long-run conversation context 
should be populated to non-face requests if JSF redirect is used or the 
application generates a link with such cid parameter.  (please assign to me)







-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-289) Owb return 2 beans for Indirect specialized producer beans

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839861#action_12839861
 ] 

YING WANG commented on OWB-289:
---

I would presume the exact being-extended method in the super class, which has:
1. same method name
2. same parameters
3. the same return type (exactly equals or be assignable, I am not sure on 
this. )

The current getClassMethodWithTypes just returns one of the methods which 
satisfy 1 and 2. And I feel that both of our proposed fixes might miss some 
overloaded method scenarios and skip some valid bean from specialization 
configuration. 

Since pb.getCreatorMethod( ) already returns the producer method associated 
with the bean, how about changing the 2 lines to:

   Method superMethod = pb.getCreatorMethod();
   if (superMethod.getName().equals(method.getName()) &&

superMethod.getParameterTypes().equals(method.getParameterTypes()) &&

superMethod.getReturnType().equals(method.getReturnType())) 
   {
   producerBeanListHelper.add(pb); 


comments?

> Owb return 2 beans for Indirect specialized producer beans
> --
>
> Key: OWB-289
> URL: https://issues.apache.org/jira/browse/OWB-289
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: M4
>
> Attachments: owb289.patch, owb289.test.jar
>
>
> The problem might be similar to 279 managed bean bug. 
> I have "@QualifierSpecialized IPen" bean being generated by 3 producers:
> DefaultPenProducer <-(extends/specialized producer) AdvancedPenProducer 
> <-(extends/specialized producer) PremiumPenProducer 
> While query the bean "@QualifierSpecialized IPen", owb returns both beans 
> generated in AdvancePenProducer and PremiumPenProducer class. (While we 
> expected only bean generated by PremiumPenProducer should be returned)
> configureProducerSpecialization( ) might need some change to disable the 
> override specialized producer bean.
> (testcase/patch will be uploaded later)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-289) Owb return 2 beans for Indirect specialized producer beans

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839821#action_12839821
 ] 

YING WANG commented on OWB-289:
---

Thanks Mark, are the 2 methods shares the same name, parameters but the return 
types are different? I think following line should fix the problem. (I am not 
sure about using equal or isAssignableFrom, probably should use equal?)

if (superMethod != null && 
superMethod.getReturnType().equals(method.getReturnType()))
{
producerBeanListHelper.add(pb);



> Owb return 2 beans for Indirect specialized producer beans
> --
>
> Key: OWB-289
> URL: https://issues.apache.org/jira/browse/OWB-289
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: M4
>
> Attachments: owb289.patch, owb289.test.jar
>
>
> The problem might be similar to 279 managed bean bug. 
> I have "@QualifierSpecialized IPen" bean being generated by 3 producers:
> DefaultPenProducer <-(extends/specialized producer) AdvancedPenProducer 
> <-(extends/specialized producer) PremiumPenProducer 
> While query the bean "@QualifierSpecialized IPen", owb returns both beans 
> generated in AdvancePenProducer and PremiumPenProducer class. (While we 
> expected only bean generated by PremiumPenProducer should be returned)
> configureProducerSpecialization( ) might need some change to disable the 
> override specialized producer bean.
> (testcase/patch will be uploaded later)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-308) minor clean up on specialization code path

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-308:
--

Attachment: 308.patch

upload patch.

> minor clean up on specialization code path
> --
>
> Key: OWB-308
> URL: https://issues.apache.org/jira/browse/OWB-308
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Attachments: 308.patch
>
>
> Ran some tests on recent driver and found a few Exceptions fired due to 
> multiple invocation of bean.setBeanName( ) when configure specialization. 
> Changes in this patch include:
> 1. For class-based specialization, if bean specialization is already 
> configured,  skip setting bean name and populating qualifiers
> 2. For producer-based specialization, comment out 2 blocks of 
> setBeanName/populating qualifiers in old code path, since that is delayed to  
> configSpecializedProducerMethodBeans() in checkSpecializations step.
> 3. Original test case SpecializesProducer1Test will not work, since there is 
> no container and checkSpecializations( ) is not invoked.
> 4. migrate new SpecializesProducer1Test to use a container in newtest package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-308) minor clean up on specialization code path

[YING WANG (JIRA)]

minor clean up on specialization code path
--

 Key: OWB-308
 URL: https://issues.apache.org/jira/browse/OWB-308
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor


Ran some tests on recent driver and found a few Exceptions fired due to 
multiple invocation of bean.setBeanName( ) when configure specialization. 
Changes in this patch include:

1. For class-based specialization, if bean specialization is already 
configured,  skip setting bean name and populating qualifiers
2. For producer-based specialization, comment out 2 blocks of 
setBeanName/populating qualifiers in old code path, since that is delayed to  
configSpecializedProducerMethodBeans() in checkSpecializations step.
3. Original test case SpecializesProducer1Test will not work, since there is no 
container and checkSpecializations( ) is not invoked.
4. migrate new SpecializesProducer1Test to use a container in newtest package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (OWB-289) Owb return 2 beans for Indirect specialized producer beans

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG reopened OWB-289:
---


Reopen it, so the patch could be integrated.

> Owb return 2 beans for Indirect specialized producer beans
> --
>
> Key: OWB-289
> URL: https://issues.apache.org/jira/browse/OWB-289
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: M4
>
> Attachments: owb289.patch, owb289.test.jar
>
>
> The problem might be similar to 279 managed bean bug. 
> I have "@QualifierSpecialized IPen" bean being generated by 3 producers:
> DefaultPenProducer <-(extends/specialized producer) AdvancedPenProducer 
> <-(extends/specialized producer) PremiumPenProducer 
> While query the bean "@QualifierSpecialized IPen", owb returns both beans 
> generated in AdvancePenProducer and PremiumPenProducer class. (While we 
> expected only bean generated by PremiumPenProducer should be returned)
> configureProducerSpecialization( ) might need some change to disable the 
> override specialized producer bean.
> (testcase/patch will be uploaded later)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-289) Owb return 2 beans for Indirect specialized producer beans

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-289:
--

Attachment: owb289.test.jar
owb289.patch

I think the bug might be mis-closed. Please review the this 289 patch and test 
case. The fix I created for 279 only fix class-based bean. OWB has different 
code path for specialized producer bean. 

This patch should fix the issue of indirect specialized producer method bean.


> Owb return 2 beans for Indirect specialized producer beans
> --
>
> Key: OWB-289
> URL: https://issues.apache.org/jira/browse/OWB-289
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Fix For: M4
>
> Attachments: owb289.patch, owb289.test.jar
>
>
> The problem might be similar to 279 managed bean bug. 
> I have "@QualifierSpecialized IPen" bean being generated by 3 producers:
> DefaultPenProducer <-(extends/specialized producer) AdvancedPenProducer 
> <-(extends/specialized producer) PremiumPenProducer 
> While query the bean "@QualifierSpecialized IPen", owb returns both beans 
> generated in AdvancePenProducer and PremiumPenProducer class. (While we 
> expected only bean generated by PremiumPenProducer should be returned)
> configureProducerSpecialization( ) might need some change to disable the 
> override specialized producer bean.
> (testcase/patch will be uploaded later)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-289) Owb return 2 beans for Indirect specialized producer beans

[YING WANG (JIRA)]

Owb return 2 beans for Indirect specialized producer beans
--

 Key: OWB-289
 URL: https://issues.apache.org/jira/browse/OWB-289
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor


The problem might be similar to 279 managed bean bug. 

I have "@QualifierSpecialized IPen" bean being generated by 3 producers:

DefaultPenProducer <-(extends/specialized producer) AdvancedPenProducer 
<-(extends/specialized producer) PremiumPenProducer 

While query the bean "@QualifierSpecialized IPen", owb returns both beans 
generated in AdvancePenProducer and PremiumPenProducer class. (While we 
expected only bean generated by PremiumPenProducer should be returned)

configureProducerSpecialization( ) might need some change to disable the 
override specialized producer bean.

(testcase/patch will be uploaded later)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-284) OWB could not find default bean if alternative specialized bean is not enabled.

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-284:
--

Attachment: owb284.patch

please review the patch(r911238) for 284, 279. Thanks.

> OWB could not find default bean if alternative specialized bean is not 
> enabled.
> ---
>
> Key: OWB-284
> URL: https://issues.apache.org/jira/browse/OWB-284
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Attachments: owb284.patch, owb284testcase.jar
>
>
> I have 2 managed beans: 
> @QualifierSpecialized Bus 
> @Alternative @Specializes public class SchoolBus extends Bus
> owb works fine when SchoolBus is enabled in bean.xml. However, if SchoolBus 
> is not enabled in bean.xml, owb could NOT locate Bus either.
> (test case will be uploaded later).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-284) OWB could not find default bean if alternative specialized bean is not enabled.

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834492#action_12834492
 ] 

YING WANG commented on OWB-284:
---

Gurkan, I will try to combine both, might take me some time. I am not sure 
about some behaviors:

1. Considering following 3 specialized beans:
Bean1
@Alternative @Specializes Bean2 extends Bean1
@Specializes Bean3 extends Bean2

If Bean2 is not enabled in bean.xml, should we report an error, or should still 
return Bean3?

2. Are we going to support defining Specialized bean  in bean.xml? or I could 
ignore checkXMLSpecializations? I didn't see definition of specialized bean in 
bean.xml in the spec. 

thanks.

> OWB could not find default bean if alternative specialized bean is not 
> enabled.
> ---
>
> Key: OWB-284
> URL: https://issues.apache.org/jira/browse/OWB-284
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Attachments: owb284testcase.jar
>
>
> I have 2 managed beans: 
> @QualifierSpecialized Bus 
> @Alternative @Specializes public class SchoolBus extends Bus
> owb works fine when SchoolBus is enabled in bean.xml. However, if SchoolBus 
> is not enabled in bean.xml, owb could NOT locate Bus either.
> (test case will be uploaded later).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-284) OWB could not find default bean if alternative specialized bean is not enabled.

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-284:
--

Attachment: owb284testcase.jar

test case for 284.

> OWB could not find default bean if alternative specialized bean is not 
> enabled.
> ---
>
> Key: OWB-284
> URL: https://issues.apache.org/jira/browse/OWB-284
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Attachments: owb284testcase.jar
>
>
> I have 2 managed beans: 
> @QualifierSpecialized Bus 
> @Alternative @Specializes public class SchoolBus extends Bus
> owb works fine when SchoolBus is enabled in bean.xml. However, if SchoolBus 
> is not enabled in bean.xml, owb could NOT locate Bus either.
> (test case will be uploaded later).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-284) OWB could not find default bean if alternative specialized bean is not enabled.

[YING WANG (JIRA)]

OWB could not find default bean if alternative specialized bean is not enabled.
---

 Key: OWB-284
 URL: https://issues.apache.org/jira/browse/OWB-284
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: YING WANG
Assignee: Gurkan Erdogdu


I have 2 managed beans: 

@QualifierSpecialized Bus 

@Alternative @Specializes public class SchoolBus extends Bus

owb works fine when SchoolBus is enabled in bean.xml. However, if SchoolBus is 
not enabled in bean.xml, owb could NOT locate Bus either.

(test case will be uploaded later).




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-279) Indirect specialization (4.3.1) throws InconsistentSpecializationException

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-279:
--

Attachment: owb279.svn.patch

svn patch against the latest r910649.

> Indirect specialization (4.3.1) throws InconsistentSpecializationException
> --
>
> Key: OWB-279
> URL: https://issues.apache.org/jira/browse/OWB-279
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Fix For: M4
>
> Attachments: owb279.svn.patch, owb299-patch.jar, specialize2.jar
>
>
> I have a list of specializes/extends beans (Car <- CarToyota <- 
> CarToyotaCamry <- CarToyotaCamryHybird). However the test throws
> org.apache.webbeans.exception.inject.InconsistentSpecializationException: 
> More than one specialized bean for class : class 
> org.apache.webbeans.newtests.specializes2.CarToyota is enabled in the 
> deployment.
> According to 4.3.1 X,Y,Z case, indirect specialization should work and 
> CarToyotaCamryHybird should be enabled in the above test case. Please help 
> review the test case (will upload later) and the following patches. 
> ==WebBeansUtil.java===
> /**
>  * verify a list of beans are directly specialized/extended each other.
>  * 
>  * @param resolvers
>  * @return
>  */
> public static boolean isDirectlySpecialized(Set> beans) {
>   ArrayList> beanList = new ArrayList>();
>   for(Bean bb : beans) {
>   AbstractBeanbean = (AbstractBean)bb;
>   beanList.add(bean);
>   }
>   
>   java.util.Collections.sort(beanList, new java.util.Comparator() {
>   public int compare(Object o1, Object o2) {
>   AbstractBean b1 = (AbstractBean)o1;
>   AbstractBean b2 = (AbstractBean)o2;
>   Class c1 = b1.getReturnType();
>   Class c2 = b2.getReturnType();
>   if (c2.isAssignableFrom(c1)) return 1;
>   if (c1.isAssignableFrom(c2)) return -1;
>   throw new InconsistentSpecializationException(c1 + " 
> and " + c2 + "are not assignable to each other." );
>   }
>   });
>   for(int i=0; i   if 
> (!beanList.get(i).getReturnType().equals(beanList.get(i+1).getReturnType().getSuperclass()))
>   return false;
>   }
>   return true;
> }
> 
> and in WebBeansUtil.configureSpecializations( ), verify the resolvers are 
> directly specialized/extended when size  > 1.
>
> if(resolvers.size() > 1 && !isDirectlySpecialized(resolvers))
> {   throw new InconsistentSpecializationException("More than one 
> specialized bean for class : " + specializedClass + " is enabled in the 
> deployment.");
> }
> 
> ==BeansDeployer.java===
> added  superClassList  local variable. If beanClasses contains:
> Car, CarToyota(s), Bus, ShoolBus(s), CarFord(s), current logic will not find 
> CarFord and carToyota will both specialize Car.
> protected void checkSpecializations(ScannerService scanner)
> {
> logger.info(OWBLogConst.INFO_0029);
> 
> try
> {
> Set> beanClasses = scanner.getBeanClasses();
> if (beanClasses != null && beanClasses.size() > 0)
> {
>   // make sure we do not have 2 specialized beans shares the same 
> super class
>   Class superClass = null;
> ArrayList> superClassList = new 
> ArrayList>();
> for(Class specialClass : beanClasses)
> {
> if(AnnotationUtil.hasClassAnnotation(specialClass, 
> Specializes.class))
> {
>   superClass = specialClass.getSuperclass();
> if(superClass.equals(Object.class))
> {
> throw new 
> WebBeansConfigurationException(logger.getTokenString(OWBLogConst.EXCEPT_0003) 
> + specialClass.getName()
>  + 
> logger.getTokenString(OWBLogConst.EXCEPT_0004));
> }
>   
> if 
> (superClassList.contains(specialClass.getSuperclass()))
> {
> throw new 
> InconsistentSpecializationException(logger.getTokenString(OWBLogConst.EXCEPT_0005)
>  + superClass.getName());
> }
> 
> WebB

[jira] Updated: (OWB-279) Indirect specialization (4.3.1) throws InconsistentSpecializationException

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-279:
--

Attachment: owb299-patch.jar

Please help review the patch. I modified configureSpecializations a little bit 
to recursively configure superClass if superclass is also a specialized. Thanks.


> Indirect specialization (4.3.1) throws InconsistentSpecializationException
> --
>
> Key: OWB-279
> URL: https://issues.apache.org/jira/browse/OWB-279
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Fix For: M4
>
> Attachments: owb299-patch.jar, specialize2.jar
>
>
> I have a list of specializes/extends beans (Car <- CarToyota <- 
> CarToyotaCamry <- CarToyotaCamryHybird). However the test throws
> org.apache.webbeans.exception.inject.InconsistentSpecializationException: 
> More than one specialized bean for class : class 
> org.apache.webbeans.newtests.specializes2.CarToyota is enabled in the 
> deployment.
> According to 4.3.1 X,Y,Z case, indirect specialization should work and 
> CarToyotaCamryHybird should be enabled in the above test case. Please help 
> review the test case (will upload later) and the following patches. 
> ==WebBeansUtil.java===
> /**
>  * verify a list of beans are directly specialized/extended each other.
>  * 
>  * @param resolvers
>  * @return
>  */
> public static boolean isDirectlySpecialized(Set> beans) {
>   ArrayList> beanList = new ArrayList>();
>   for(Bean bb : beans) {
>   AbstractBeanbean = (AbstractBean)bb;
>   beanList.add(bean);
>   }
>   
>   java.util.Collections.sort(beanList, new java.util.Comparator() {
>   public int compare(Object o1, Object o2) {
>   AbstractBean b1 = (AbstractBean)o1;
>   AbstractBean b2 = (AbstractBean)o2;
>   Class c1 = b1.getReturnType();
>   Class c2 = b2.getReturnType();
>   if (c2.isAssignableFrom(c1)) return 1;
>   if (c1.isAssignableFrom(c2)) return -1;
>   throw new InconsistentSpecializationException(c1 + " 
> and " + c2 + "are not assignable to each other." );
>   }
>   });
>   for(int i=0; i   if 
> (!beanList.get(i).getReturnType().equals(beanList.get(i+1).getReturnType().getSuperclass()))
>   return false;
>   }
>   return true;
> }
> 
> and in WebBeansUtil.configureSpecializations( ), verify the resolvers are 
> directly specialized/extended when size  > 1.
>
> if(resolvers.size() > 1 && !isDirectlySpecialized(resolvers))
> {   throw new InconsistentSpecializationException("More than one 
> specialized bean for class : " + specializedClass + " is enabled in the 
> deployment.");
> }
> 
> ==BeansDeployer.java===
> added  superClassList  local variable. If beanClasses contains:
> Car, CarToyota(s), Bus, ShoolBus(s), CarFord(s), current logic will not find 
> CarFord and carToyota will both specialize Car.
> protected void checkSpecializations(ScannerService scanner)
> {
> logger.info(OWBLogConst.INFO_0029);
> 
> try
> {
> Set> beanClasses = scanner.getBeanClasses();
> if (beanClasses != null && beanClasses.size() > 0)
> {
>   // make sure we do not have 2 specialized beans shares the same 
> super class
>   Class superClass = null;
> ArrayList> superClassList = new 
> ArrayList>();
> for(Class specialClass : beanClasses)
> {
> if(AnnotationUtil.hasClassAnnotation(specialClass, 
> Specializes.class))
> {
>   superClass = specialClass.getSuperclass();
> if(superClass.equals(Object.class))
> {
> throw new 
> WebBeansConfigurationException(logger.getTokenString(OWBLogConst.EXCEPT_0003) 
> + specialClass.getName()
>  + 
> logger.getTokenString(OWBLogConst.EXCEPT_0004));
> }
>   
> if 
> (superClassList.contains(specialClass.getSuperclass()))
> {
> throw new 
> InconsistentSpecializationException(logger.getTokenString(OWBLogConst.EXCEPT_0005)
>  + su

[jira] Updated: (OWB-279) Indirect specialization (4.3.1) throws InconsistentSpecializationException

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-279:
--

Attachment: specialize2.jar

Still not working even with my patch, bean size is 0 for some reason. debugging.

> Indirect specialization (4.3.1) throws InconsistentSpecializationException
> --
>
> Key: OWB-279
> URL: https://issues.apache.org/jira/browse/OWB-279
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Attachments: specialize2.jar
>
>
> I have a list of specializes/extends beans (Car <- CarToyota <- 
> CarToyotaCamry <- CarToyotaCamryHybird). However the test throws
> org.apache.webbeans.exception.inject.InconsistentSpecializationException: 
> More than one specialized bean for class : class 
> org.apache.webbeans.newtests.specializes2.CarToyota is enabled in the 
> deployment.
> According to 4.3.1 X,Y,Z case, indirect specialization should work and 
> CarToyotaCamryHybird should be enabled in the above test case. Please help 
> review the test case (will upload later) and the following patches. 
> ==WebBeansUtil.java===
> /**
>  * verify a list of beans are directly specialized/extended each other.
>  * 
>  * @param resolvers
>  * @return
>  */
> public static boolean isDirectlySpecialized(Set> beans) {
>   ArrayList> beanList = new ArrayList>();
>   for(Bean bb : beans) {
>   AbstractBeanbean = (AbstractBean)bb;
>   beanList.add(bean);
>   }
>   
>   java.util.Collections.sort(beanList, new java.util.Comparator() {
>   public int compare(Object o1, Object o2) {
>   AbstractBean b1 = (AbstractBean)o1;
>   AbstractBean b2 = (AbstractBean)o2;
>   Class c1 = b1.getReturnType();
>   Class c2 = b2.getReturnType();
>   if (c2.isAssignableFrom(c1)) return 1;
>   if (c1.isAssignableFrom(c2)) return -1;
>   throw new InconsistentSpecializationException(c1 + " 
> and " + c2 + "are not assignable to each other." );
>   }
>   });
>   for(int i=0; i   if 
> (!beanList.get(i).getReturnType().equals(beanList.get(i+1).getReturnType().getSuperclass()))
>   return false;
>   }
>   return true;
> }
> 
> and in WebBeansUtil.configureSpecializations( ), verify the resolvers are 
> directly specialized/extended when size  > 1.
>
> if(resolvers.size() > 1 && !isDirectlySpecialized(resolvers))
> {   throw new InconsistentSpecializationException("More than one 
> specialized bean for class : " + specializedClass + " is enabled in the 
> deployment.");
> }
> 
> ==BeansDeployer.java===
> added  superClassList  local variable. If beanClasses contains:
> Car, CarToyota(s), Bus, ShoolBus(s), CarFord(s), current logic will not find 
> CarFord and carToyota will both specialize Car.
> protected void checkSpecializations(ScannerService scanner)
> {
> logger.info(OWBLogConst.INFO_0029);
> 
> try
> {
> Set> beanClasses = scanner.getBeanClasses();
> if (beanClasses != null && beanClasses.size() > 0)
> {
>   // make sure we do not have 2 specialized beans shares the same 
> super class
>   Class superClass = null;
> ArrayList> superClassList = new 
> ArrayList>();
> for(Class specialClass : beanClasses)
> {
> if(AnnotationUtil.hasClassAnnotation(specialClass, 
> Specializes.class))
> {
>   superClass = specialClass.getSuperclass();
> if(superClass.equals(Object.class))
> {
> throw new 
> WebBeansConfigurationException(logger.getTokenString(OWBLogConst.EXCEPT_0003) 
> + specialClass.getName()
>  + 
> logger.getTokenString(OWBLogConst.EXCEPT_0004));
> }
>   
> if 
> (superClassList.contains(specialClass.getSuperclass()))
> {
> throw new 
> InconsistentSpecializationException(logger.getTokenString(OWBLogConst.EXCEPT_0005)
>  + superClass.getName());
> }
> 
> WebBeansUtil.configureSpec

[jira] Created: (OWB-279) Indirect specialization (4.3.1) throws InconsistentSpecializationException

[YING WANG (JIRA)]

Indirect specialization (4.3.1) throws InconsistentSpecializationException
--

 Key: OWB-279
 URL: https://issues.apache.org/jira/browse/OWB-279
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: YING WANG
Assignee: Gurkan Erdogdu


I have a list of specializes/extends beans (Car <- CarToyota <- CarToyotaCamry 
<- CarToyotaCamryHybird). However the test throws

org.apache.webbeans.exception.inject.InconsistentSpecializationException: More 
than one specialized bean for class : class 
org.apache.webbeans.newtests.specializes2.CarToyota is enabled in the 
deployment.

According to 4.3.1 X,Y,Z case, indirect specialization should work and 
CarToyotaCamryHybird should be enabled in the above test case. Please help 
review the test case (will upload later) and the following patches. 

==WebBeansUtil.java===
/**
 * verify a list of beans are directly specialized/extended each other.
 * 
 * @param resolvers
 * @return
 */
public static boolean isDirectlySpecialized(Set> beans) {
ArrayList> beanList = new ArrayList>();

for(Bean bb : beans) {
AbstractBeanbean = (AbstractBean)bb;
beanList.add(bean);
}

java.util.Collections.sort(beanList, new java.util.Comparator() {
public int compare(Object o1, Object o2) {
AbstractBean b1 = (AbstractBean)o1;
AbstractBean b2 = (AbstractBean)o2;
Class c1 = b1.getReturnType();
Class c2 = b2.getReturnType();
if (c2.isAssignableFrom(c1)) return 1;
if (c1.isAssignableFrom(c2)) return -1;
throw new InconsistentSpecializationException(c1 + " 
and " + c2 + "are not assignable to each other." );
}
});

for(int i=0; i 1.
   
if(resolvers.size() > 1 && !isDirectlySpecialized(resolvers))
{   throw new InconsistentSpecializationException("More than one 
specialized bean for class : " + specializedClass + " is enabled in the 
deployment.");
}



==BeansDeployer.java===
added  superClassList  local variable. If beanClasses contains:
Car, CarToyota(s), Bus, ShoolBus(s), CarFord(s), current logic will not find 
CarFord and carToyota will both specialize Car.

protected void checkSpecializations(ScannerService scanner)
{
logger.info(OWBLogConst.INFO_0029);

try
{
Set> beanClasses = scanner.getBeanClasses();
if (beanClasses != null && beanClasses.size() > 0)
{
// make sure we do not have 2 specialized beans shares the same 
super class
Class superClass = null;
ArrayList> superClassList = new ArrayList>();
for(Class specialClass : beanClasses)
{
if(AnnotationUtil.hasClassAnnotation(specialClass, 
Specializes.class))
{
superClass = specialClass.getSuperclass();
if(superClass.equals(Object.class))
{
throw new 
WebBeansConfigurationException(logger.getTokenString(OWBLogConst.EXCEPT_0003) + 
specialClass.getName()
 + 
logger.getTokenString(OWBLogConst.EXCEPT_0004));
}

if 
(superClassList.contains(specialClass.getSuperclass()))
{
throw new 
InconsistentSpecializationException(logger.getTokenString(OWBLogConst.EXCEPT_0005)
 + superClass.getName());
}

WebBeansUtil.configureSpecializations(specialClass);

}
}
}

// XML Defined Specializations
checkXMLSpecializations();
}
catch(Exception e)
{
throw new WebBeansDeploymentException(e);
}


logger.info(OWBLogConst.INFO_0030);
}
 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-273) Given class is not annotated with @Alternative Exception when try to enable alternative producer/producer field beans

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832062#action_12832062
 ] 

YING WANG commented on OWB-273:
---

Thanks a lot, Gurkan. So the only way to enable an alternative producer bean is 
to annotate 
both its class and producer method and enble the class in beans.xml?  

I also create a few test cases around alternative/producer/diposes and found 
some test cases
throws exceptions. Could you please help review and see if they are bugs or 
valid exceptions?


1. AlternativeTest1, includes DefaultBeanProducer and AlternativeBeanProducer1
and I have moved @Alternative from the producer method to the class level. And 
AlternativeBeanProducer1 is NOT selected.
Result:  AmbiguousResolutionException.
Ying's comments: Shouldn't the producer bean in AlternativeBeanProducer1 be 
disabled?
According to 5.1.2, a bean is enabled if it is not a producer method of a 
disabled bean.



2. AlternativeTest2, includes DefaultBeanProducer and AlternativeBeanProducer2
and have @Alternative annotated at class and producer method. And 
AlternativeBeanProducer2 is NOT selected.
Result: DefaultBeanProducer is used(expected). However the disposes 
method is not invoked.
Ying's comments: Not sure why disposes of DefaultBeanProducer is not invoked.



3. AlternativeTest3, includes DefaultBeanProducer and AlternativeBeanProducer3
and has disposes method defined in both. AlternativeBeanProducer3 is NOT 
selected.
Result: Producer method component of the disposal method : dumpBean3 in 
class : 

org.apache.webbeans.newtests.alternatives2.AlternativeBeanProducer3 must 
be in the same class!
Ying's comments: Shouldn't both producer and dispose methods in 
AlternativeBeanProducer3
be ignored since the AlternativeBeanProducer3 is disabled? the 
spec
did not mention much about how disposes method works in a 
alternative bean.



4. AlternativeTest4, includes DefaultBeanProducerWithoutDisposes, 
AlternativeBeanProducer3
and AlternativeBeanProducer4 . Have disposes method defined in 2 alternative 
classes. 
AlternativeBeanProducer3 and AlternativeBeanProducer4 are NOT selected.
Result: UnsatisfiedResolutionException: Producer method component of 
the disposal 
method : dumpBean3 in class : 
org.apache.webbeans.newtests.alternatives2.AlternativeBeanProducer3. 
annot find bean interface 
org.apache.webbeans.newtests.alternatives2.IProducedBean 
with qualifier 
[...@org.apache.webbeans.newtests.alternatives2.qualifierproducerbased()]
Ying's comments:  same as 3.


5. AlternativeTest5, same as above except AlternativeBeanProducer4 is enabled.
Result: same as 4.




> Given class is not annotated with @Alternative Exception when try to enable 
> alternative producer/producer field beans
> -
>
> Key: OWB-273
> URL: https://issues.apache.org/jira/browse/OWB-273
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Attachments: alternative2.jar
>
>
> I have an alternative producer bean as follow. It seems that the 
> AlternativesManager.addClazzAlternative( ) requires @Alternative to be 
> annotated at the class level even if it is an alternative producer and throws 
> the following exception.  
> It is not necessary to add @Alternative at both class level and method level 
> for a producer/producer field beans, right?
> =EXCEPTION===
>  
> org.apache.webbeans.exception.WebBeansConfigurationException: Given class : 
> com.jcdi.test.alternative.producerbased.AlternativeBeanProducer2 is not 
> annotated with @Alternative
> at 
> org.apache.webbeans.inject.AlternativesManager.addClazzAlternative(AlternativesManager.java:89)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.addAlternative(WebBeansXMLConfigurator.java:622)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureAlternativesElement(WebBeansXMLConfigurator.java:587)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:323)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:221)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configure(WebBeansXMLConfigurator.java:157)
> at 
> org.apache.webbeans.config.BeansDeployer.deployFromXML(BeansDeployer.java:384)
> at 
> org.apache.w

[jira] Updated: (OWB-273) Given class is not annotated with @Alternative Exception when try to enable alternative producer/producer field beans

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-273:
--

Attachment: alternative2.jar

test cases around alternative/producer/disposes.

> Given class is not annotated with @Alternative Exception when try to enable 
> alternative producer/producer field beans
> -
>
> Key: OWB-273
> URL: https://issues.apache.org/jira/browse/OWB-273
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
> Attachments: alternative2.jar
>
>
> I have an alternative producer bean as follow. It seems that the 
> AlternativesManager.addClazzAlternative( ) requires @Alternative to be 
> annotated at the class level even if it is an alternative producer and throws 
> the following exception.  
> It is not necessary to add @Alternative at both class level and method level 
> for a producer/producer field beans, right?
> =EXCEPTION===
>  
> org.apache.webbeans.exception.WebBeansConfigurationException: Given class : 
> com.jcdi.test.alternative.producerbased.AlternativeBeanProducer2 is not 
> annotated with @Alternative
> at 
> org.apache.webbeans.inject.AlternativesManager.addClazzAlternative(AlternativesManager.java:89)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.addAlternative(WebBeansXMLConfigurator.java:622)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureAlternativesElement(WebBeansXMLConfigurator.java:587)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:323)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:221)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configure(WebBeansXMLConfigurator.java:157)
> at 
> org.apache.webbeans.config.BeansDeployer.deployFromXML(BeansDeployer.java:384)
> at 
> org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:139)
> at 
> org.apache.webbeans.lifecycle.WebApplicationLifeCycle.applicationStarted(WebApplicationLifeCycle.java:196)
> at 
> org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)
> ===THE ALTERNATIVE PRODUCER 
> BEAN===
> public class AlternativeBeanProducer2 {
>   public @Produces @Alternative @QualifierProducerBased IProducedBean 
>   generateBean2(@New AlternativeBeanClass1 beanClass) {
>   return new AbstractProducedBean(beanClass, this);
>   }
> /*
>   public void dumpBean2(
>   @Disposes @QualifierProducer IProducedBean bean, ILog 
> log) {
>   log.log(bean + " is dumped by 
> AlternativeBeanProducer2");
>   }
> */ 
>   
> }
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (OWB-273) Given class is not annotated with @Alternative Exception when try to enable alternative producer/producer field beans

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831508#action_12831508
 ] 

YING WANG commented on OWB-273:
---

hmm. I am thinking, if a class itself is annotated with @alternative or a class 
has at least one producer/producer field annotated with @alternative then the 
class could be called "an alternative bean class". 

I am not sure how weld works, but based on a Gavin's sample (The blogger is 
super slow now):
   
 
http://relation.to/Bloggers/MakingExternalResourcesConfigurableWithoutLotsOfXML

it might not require a class itself to be annotated if the it already declares 
@alternative producer bean. 

> Given class is not annotated with @Alternative Exception when try to enable 
> alternative producer/producer field beans
> -
>
> Key: OWB-273
> URL: https://issues.apache.org/jira/browse/OWB-273
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Injection and Lookup
>Affects Versions: M3
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
>Priority: Minor
>
> I have an alternative producer bean as follow. It seems that the 
> AlternativesManager.addClazzAlternative( ) requires @Alternative to be 
> annotated at the class level even if it is an alternative producer and throws 
> the following exception.  
> It is not necessary to add @Alternative at both class level and method level 
> for a producer/producer field beans, right?
> =EXCEPTION===
>  
> org.apache.webbeans.exception.WebBeansConfigurationException: Given class : 
> com.jcdi.test.alternative.producerbased.AlternativeBeanProducer2 is not 
> annotated with @Alternative
> at 
> org.apache.webbeans.inject.AlternativesManager.addClazzAlternative(AlternativesManager.java:89)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.addAlternative(WebBeansXMLConfigurator.java:622)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureAlternativesElement(WebBeansXMLConfigurator.java:587)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:323)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:221)
> at 
> org.apache.webbeans.xml.WebBeansXMLConfigurator.configure(WebBeansXMLConfigurator.java:157)
> at 
> org.apache.webbeans.config.BeansDeployer.deployFromXML(BeansDeployer.java:384)
> at 
> org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:139)
> at 
> org.apache.webbeans.lifecycle.WebApplicationLifeCycle.applicationStarted(WebApplicationLifeCycle.java:196)
> at 
> org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)
> ===THE ALTERNATIVE PRODUCER 
> BEAN===
> public class AlternativeBeanProducer2 {
>   public @Produces @Alternative @QualifierProducerBased IProducedBean 
>   generateBean2(@New AlternativeBeanClass1 beanClass) {
>   return new AbstractProducedBean(beanClass, this);
>   }
> /*
>   public void dumpBean2(
>   @Disposes @QualifierProducer IProducedBean bean, ILog 
> log) {
>   log.log(bean + " is dumped by 
> AlternativeBeanProducer2");
>   }
> */ 
>   
> }
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-273) Given class is not annotated with @Alternative Exception when try to enable alternative producer/producer field beans

[YING WANG (JIRA)]

Given class is not annotated with @Alternative Exception when try to enable 
alternative producer/producer field beans
-

 Key: OWB-273
 URL: https://issues.apache.org/jira/browse/OWB-273
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Injection and Lookup
Affects Versions: M3
Reporter: YING WANG
Assignee: Gurkan Erdogdu
Priority: Minor


I have an alternative producer bean as follow. It seems that the 
AlternativesManager.addClazzAlternative( ) requires @Alternative to be 
annotated at the class level even if it is an alternative producer and throws 
the following exception.  

It is not necessary to add @Alternative at both class level and method level 
for a producer/producer field beans, right?

=EXCEPTION===
 
org.apache.webbeans.exception.WebBeansConfigurationException: Given class : 
com.jcdi.test.alternative.producerbased.AlternativeBeanProducer2 is not 
annotated with @Alternative
at 
org.apache.webbeans.inject.AlternativesManager.addClazzAlternative(AlternativesManager.java:89)
at 
org.apache.webbeans.xml.WebBeansXMLConfigurator.addAlternative(WebBeansXMLConfigurator.java:622)
at 
org.apache.webbeans.xml.WebBeansXMLConfigurator.configureAlternativesElement(WebBeansXMLConfigurator.java:587)
at 
org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:323)
at 
org.apache.webbeans.xml.WebBeansXMLConfigurator.configureSpecSpecific(WebBeansXMLConfigurator.java:221)
at 
org.apache.webbeans.xml.WebBeansXMLConfigurator.configure(WebBeansXMLConfigurator.java:157)
at 
org.apache.webbeans.config.BeansDeployer.deployFromXML(BeansDeployer.java:384)
at 
org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:139)
at 
org.apache.webbeans.lifecycle.WebApplicationLifeCycle.applicationStarted(WebApplicationLifeCycle.java:196)
at 
org.apache.webbeans.servlet.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:60)

===THE ALTERNATIVE PRODUCER 
BEAN===

public class AlternativeBeanProducer2 {

public @Produces @Alternative @QualifierProducerBased IProducedBean 
generateBean2(@New AlternativeBeanClass1 beanClass) {
return new AbstractProducedBean(beanClass, this);
}
/*  
public void dumpBean2(
@Disposes @QualifierProducer IProducedBean bean, ILog 
log) {
log.log(bean + " is dumped by 
AlternativeBeanProducer2");
}
*/ 

}



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (OWB-244) OWB injects a new object for @disposes injection point for dependent scope

[YING WANG (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

YING WANG updated OWB-244:
--

Attachment: dispose2.jar

test code for dependent and request scope @disposes

> OWB injects a new object for @disposes injection point for dependent scope 
> ---
>
> Key: OWB-244
> URL: https://issues.apache.org/jira/browse/OWB-244
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0
> Environment: windows
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Fix For: 1.0.0
>
> Attachments: dispose2.jar
>
>
> 1. I am testing @disposes for dependent scope for the following bean. 
> However, the object passed in my dispose method is not the one
> I first created by the producer method. It seems that OWB inject another new 
> one  for my "@Disposes @QualifierHttp HttpHeader header" before invoking my 
> dispose method.  
> My producer method is invoked twice. The first one is valid. I have collect 
> the stack trace for the second one. I don't know how to fix this..
> 2. Possibly another small one for ClassUtil.checkParametrizedType(), 
> shouldn't the method go though the rest types if the first one is 
> ParameterizedType?
> BTW, thanks a lot for fixing 241, it does work.
> Ying
> ===Stack trace for the second invocation of producer 
> method=
> Thread-119 creates 
> com.ibm.jcdi.test.disposes.httphea...@27422742(unknown=unknown,myIndex=1) 
> with the following stack trace:
> com.ibm.jcdi.test.disposes.HttpHeaderProducer.generateDependentScopeHttpHeader(HttpHeaderProducer.java:29)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> java.lang.reflect.Method.invoke(Method.java:600)
> org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:80)
> org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:168)
> org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:137)
> org.apache.webbeans.component.AbstractBean.create(AbstractBean.java:159)
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:65)
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:150)
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:709)
> org.apache.webbeans.component.AbstractBean.getDependent(AbstractBean.java:419)
> org.apache.webbeans.inject.AbstractInjectable.injectForDependent(AbstractInjectable.java:142)
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:98)
> <= inject the parameters of my dispose method
> org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:67)
> <= try to invoke my dispose method
> org.apache.webbeans.component.ProducerMethodBean.disposeDefault(ProducerMethodBean.java:227)
>
> org.apache.webbeans.component.ProducerMethodBean.dispose(ProducerMethodBean.java:203)
> org.apache.webbeans.component.ProducerMethodBean.destroyInstance(ProducerMethodBean.java:189)
> org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:201)
> org.apache.webbeans.context.creational.CreationalContextImpl.removeDependents(CreationalContextImpl.java:159)
> org.apache.webbeans.context.creational.CreationalContextImpl.release(CreationalContextImpl.java:171)
> org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:198)
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:200)
> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:222)
> org.apache.webbeans.context.ContextFactory.destroyRequestContext(ContextFactory.java:137)
> org.apache.webbeans.lifecycle.EnterpriseLifeCycle.requestEnded(EnterpriseLifeCycle.java:139)
> org.apache.webbeans.servlet.WebBeansConfigurationListener.requestDestroyed(WebBeansConfigurationListener.java:68)
> ==Test dependent Producer bean class for 
> @disposes
> @ApplicationScoped
> public class HttpHeaderProducer implements Serializable {
>   static ILog myLog = null;   
>   
> //dependent producer method
>   public static @Produces @QualifierHttp HttpHeader 
> generateDependentScopeHttpHeader(
>   @New HttpHeader header) throws Exception {
> }
> //disposer method
>   public static void dumpHttpHeader(
>   @Disposes @QualifierHttp HttpHeader header,
>   @QualifierDisposesTest(getID="3.3.x", getComments="T

[jira] Commented: (OWB-244) OWB injects a new object for @disposes injection point for dependent scope

[YING WANG (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806623#action_12806623
 ] 

YING WANG commented on OWB-244:
---

Sorry for the delay. I tested the recent r901845, the symptom is changed. my 
dependent @disposes method does not invoked at all. It seems the depdenent 
creation conext links get broken somewhere. I have uploaded a new test case for 
@disposes (see the attched source jar). 

Basically,  I have DepdenentBean producer bean which contains a disposer 
method. and it is injected into RequestModel. While my RequestBean is also a 
producer bean for request scope, which also contains a disposer method. The 
result shows only my RequestBean dispose method get invoked:

=RESULT==>

produced 
dependentmodel=org.apache.webbeans.newtests.disposes2.dependentmo...@53f653f6
produced 
requestmodel=org.apache.webbeans.newtests.disposes2.requestmo...@2f902f90
0
disposed 
requestmodel=org.apache.webbeans.newtests.disposes2.requestmo...@2f902f90

 OWB injects a new object for @disposes injection point for dependent scope 
> ---
>
> Key: OWB-244
> URL: https://issues.apache.org/jira/browse/OWB-244
> Project: OpenWebBeans
>  Issue Type: Bug
>  Components: Context and Scopes
>Affects Versions: 1.0.0
> Environment: windows
>Reporter: YING WANG
>Assignee: Gurkan Erdogdu
> Fix For: 1.0.0
>
>
> 1. I am testing @disposes for dependent scope for the following bean. 
> However, the object passed in my dispose method is not the one
> I first created by the producer method. It seems that OWB inject another new 
> one  for my "@Disposes @QualifierHttp HttpHeader header" before invoking my 
> dispose method.  
> My producer method is invoked twice. The first one is valid. I have collect 
> the stack trace for the second one. I don't know how to fix this..
> 2. Possibly another small one for ClassUtil.checkParametrizedType(), 
> shouldn't the method go though the rest types if the first one is 
> ParameterizedType?
> BTW, thanks a lot for fixing 241, it does work.
> Ying
> ===Stack trace for the second invocation of producer 
> method=
> Thread-119 creates 
> com.ibm.jcdi.test.disposes.httphea...@27422742(unknown=unknown,myIndex=1) 
> with the following stack trace:
> com.ibm.jcdi.test.disposes.HttpHeaderProducer.generateDependentScopeHttpHeader(HttpHeaderProducer.java:29)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> java.lang.reflect.Method.invoke(Method.java:600)
> org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:80)
> org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:168)
> org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:137)
> org.apache.webbeans.component.AbstractBean.create(AbstractBean.java:159)
> org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:65)
> org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:150)
> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:709)
> org.apache.webbeans.component.AbstractBean.getDependent(AbstractBean.java:419)
> org.apache.webbeans.inject.AbstractInjectable.injectForDependent(AbstractInjectable.java:142)
> org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:98)
> <= inject the parameters of my dispose method
> org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:67)
> <= try to invoke my dispose method
> org.apache.webbeans.component.ProducerMethodBean.disposeDefault(ProducerMethodBean.java:227)
>
> org.apache.webbeans.component.ProducerMethodBean.dispose(ProducerMethodBean.java:203)
> org.apache.webbeans.component.ProducerMethodBean.destroyInstance(ProducerMethodBean.java:189)
> org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:201)
> org.apache.webbeans.context.creational.CreationalContextImpl.removeDependents(CreationalContextImpl.java:159)
> org.apache.webbeans.context.creational.CreationalContextImpl.release(CreationalContextImpl.java:171)
> org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:198)
> org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:200)
> org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:222)
> org.apache.webbeans.context.ContextFactory.destroyRequestContext(ContextFactory.java:137)
> org.apache.webbeans.lifecycle.EnterpriseLifeC

[jira] Created: (OWB-244) OWB injects a new object for @disposes injection point for dependent scope

[YING WANG (JIRA)]

OWB injects a new object for @disposes injection point for dependent scope 
---

 Key: OWB-244
 URL: https://issues.apache.org/jira/browse/OWB-244
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Context and Scopes
Affects Versions: 1.0.0
 Environment: windows
Reporter: YING WANG
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0


1. I am testing @disposes for dependent scope for the following bean. However, 
the object passed in my dispose method is not the one
I first created by the producer method. It seems that OWB inject another new 
one  for my "@Disposes @QualifierHttp HttpHeader header" before invoking my 
dispose method.  

My producer method is invoked twice. The first one is valid. I have collect the 
stack trace for the second one. I don't know how to fix this..

2. Possibly another small one for ClassUtil.checkParametrizedType(), shouldn't 
the method go though the rest types if the first one is ParameterizedType?

BTW, thanks a lot for fixing 241, it does work.

Ying

===Stack trace for the second invocation of producer 
method=
Thread-119 creates 
com.ibm.jcdi.test.disposes.httphea...@27422742(unknown=unknown,myIndex=1) with 
the following stack trace:
com.ibm.jcdi.test.disposes.HttpHeaderProducer.generateDependentScopeHttpHeader(HttpHeaderProducer.java:29)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
java.lang.reflect.Method.invoke(Method.java:600)
org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:80)
org.apache.webbeans.component.ProducerMethodBean.createDefaultInstance(ProducerMethodBean.java:168)
org.apache.webbeans.component.ProducerMethodBean.createInstance(ProducerMethodBean.java:137)
org.apache.webbeans.component.AbstractBean.create(AbstractBean.java:159)
org.apache.webbeans.context.DependentContext.getInstance(DependentContext.java:65)
org.apache.webbeans.context.AbstractContext.get(AbstractContext.java:150)
org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:709)
org.apache.webbeans.component.AbstractBean.getDependent(AbstractBean.java:419)
org.apache.webbeans.inject.AbstractInjectable.injectForDependent(AbstractInjectable.java:142)
org.apache.webbeans.inject.AbstractInjectable.inject(AbstractInjectable.java:98)
<= inject the parameters of my dispose method
org.apache.webbeans.inject.InjectableMethods.doInjection(InjectableMethods.java:67)
<= try to invoke my dispose method
org.apache.webbeans.component.ProducerMethodBean.disposeDefault(ProducerMethodBean.java:227)
   
org.apache.webbeans.component.ProducerMethodBean.dispose(ProducerMethodBean.java:203)
org.apache.webbeans.component.ProducerMethodBean.destroyInstance(ProducerMethodBean.java:189)
org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:201)
org.apache.webbeans.context.creational.CreationalContextImpl.removeDependents(CreationalContextImpl.java:159)
org.apache.webbeans.context.creational.CreationalContextImpl.release(CreationalContextImpl.java:171)
org.apache.webbeans.component.AbstractBean.destroy(AbstractBean.java:198)
org.apache.webbeans.context.AbstractContext.destroyInstance(AbstractContext.java:200)
org.apache.webbeans.context.AbstractContext.destroy(AbstractContext.java:222)
org.apache.webbeans.context.ContextFactory.destroyRequestContext(ContextFactory.java:137)
org.apache.webbeans.lifecycle.EnterpriseLifeCycle.requestEnded(EnterpriseLifeCycle.java:139)
org.apache.webbeans.servlet.WebBeansConfigurationListener.requestDestroyed(WebBeansConfigurationListener.java:68)

==Test dependent Producer bean class for 
@disposes
@ApplicationScoped
public class HttpHeaderProducer implements Serializable {

static ILog myLog = null;   

//dependent producer method
public static @Produces @QualifierHttp HttpHeader 
generateDependentScopeHttpHeader(
@New HttpHeader header) throws Exception {
}

//disposer method
public static void dumpHttpHeader(
@Disposes @QualifierHttp HttpHeader header,
@QualifierDisposesTest(getID="3.3.x", getComments="Test 
cases around @disposes.") ILog log) {
}
}

===



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (OWB-241) Conversation scoped bean instance gets destroyed for every ELResolver.getValue

[YING WANG (JIRA)]

Conversation scoped bean instance gets destroyed for every ELResolver.getValue
--

 Key: OWB-241
 URL: https://issues.apache.org/jira/browse/OWB-241
 Project: OpenWebBeans
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.0
 Environment: windows
Reporter: YING WANG
Assignee: Gurkan Erdogdu
 Fix For: 1.0.0


1. I am testing @disposes for conversation scoped bean and found my disposes 
method get invoked whenever WebBeansELResolver.getValue() invoked. Shouldn't 
the ELContextStore only stores @dependent bean objects? (After guarded the 
store.addDepenent() block with @dependent scope test, the problem seems 
resolved.)

2. There seems a typo in ELContextStore.destroy(), shouldn't 
  o.destroy(o, (CreationalContext)store.getCreational());
to be
  o.destroy(store.getObject(), 
(CreationalContext)store.getCreational());
thanks in advance...

Ying

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.