Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/
Hi Eric, Actually OWB returns proxy to client that implements clients preference interface when using getReference of BeanManager. This proxy internally uses EJB proxy instance that implements all of local interfaces. Thanks, --Gurkan From: Eric Covener cove...@gmail.com To: dev@openwebbeans.apache.org Sent: Sun, August 15, 2010 11:43:39 PM Subject: Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/src/main/java/org/apache/webbeans/ejb/ webbeans-op On Sun, Aug 15, 2010 at 4:25 PM, gerdo...@apache.org wrote: Author: gerdogdu Date: Sun Aug 15 20:25:31 2010 New Revision: 985746 URL: http://svn.apache.org/viewvc?rev=985746view=rev Log: [OWB-439] EjbPlugin session bean proxy creation thread safe problem I had a little difficulty following, especially as this went into the OpenEJB API. Does this basically make each ENTERPRISE bean return instances with all of the local interfaces as types?
Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/
This proxy internally uses EJB proxy instance that implements all of local interfaces. This may be internally handled by the OpenEJB. Look org.apache.openejb.core.ivm.EjbHomeProxyHandler class in container/openejb-core project. From: Gurkan Erdogdu gurkanerdo...@yahoo.com To: dev@openwebbeans.apache.org Sent: Mon, August 16, 2010 8:59:39 AM Subject: Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/src/main/java/org/apache/webbeans/ejb/ webbeans-op Hi Eric, Actually OWB returns proxy to client that implements clients preference interface when using getReference of BeanManager. This proxy internally uses EJB proxy instance that implements all of local interfaces. Thanks, --Gurkan From: Eric Covener cove...@gmail.com To: dev@openwebbeans.apache.org Sent: Sun, August 15, 2010 11:43:39 PM Subject: Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/src/main/java/org/apache/webbeans/ejb/ webbeans-op On Sun, Aug 15, 2010 at 4:25 PM, gerdo...@apache.org wrote: Author: gerdogdu Date: Sun Aug 15 20:25:31 2010 New Revision: 985746 URL: http://svn.apache.org/viewvc?rev=985746view=rev Log: [OWB-439] EjbPlugin session bean proxy creation thread safe problem I had a little difficulty following, especially as this went into the OpenEJB API. Does this basically make each ENTERPRISE bean return instances with all of the local interfaces as types?
Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/
On Mon, Aug 16, 2010 at 2:06 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: This proxy internally uses EJB proxy instance that implements all of local interfaces. This may be internally handled by the OpenEJB. Look org.apache.openejb.core.ivm.EjbHomeProxyHandler class in container/openejb-core project. FYI I've confirmed that the container I'm working with really needs the local interface when there's more than 1 local interface on the EJB class, so I will try to introduce a safe mechanism to pass the injected iface down.
[jira] Resolved: (OWB-430) improve performance of WebBeansPhaseListener
[ https://issues.apache.org/jira/browse/OWB-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved OWB-430. -- Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed improve performance of WebBeansPhaseListener Key: OWB-430 URL: https://issues.apache.org/jira/browse/OWB-430 Project: OpenWebBeans Issue Type: Improvement Components: Java EE Integration Affects Versions: 1.0.0-alpha-1 Reporter: Gerhard Petracek Assignee: Gurkan Erdogdu Priority: Minor Fix For: 1.0.0-alpha-2 Attachments: OWB-430.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-428) implementation of equals and hashCode for AbstractOwbBean
[ https://issues.apache.org/jira/browse/OWB-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek updated OWB-428: - Attachment: OWB-428.patch implementation of equals and hashCode for AbstractOwbBean - Key: OWB-428 URL: https://issues.apache.org/jira/browse/OWB-428 Project: OpenWebBeans Issue Type: Task Components: Core Affects Versions: 1.0.0-alpha-1 Reporter: Gerhard Petracek Assignee: Gurkan Erdogdu Fix For: 1.0.0-alpha-2 Attachments: OWB-428.patch, OWB-428.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r985746 - in /openwebbeans/trunk: webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/component/ webbeans-ejb/src/main/java/org/apache/webbeans/ejb/common/util/ webbeans-openejb/
On Mon, Aug 16, 2010 at 11:20 AM, Eric Covener cove...@gmail.com wrote: On Mon, Aug 16, 2010 at 2:06 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: This proxy internally uses EJB proxy instance that implements all of local interfaces. This may be internally handled by the OpenEJB. Look org.apache.openejb.core.ivm.EjbHomeProxyHandler class in container/openejb-core project. FYI I've confirmed that the container I'm working with really needs the local interface when there's more than 1 local interface on the EJB class, so I will try to introduce a safe mechanism to pass the injected iface down. Realizing now that this is a bigger problem in actually retrieving the ejb instances from the context -- they're not interchangeable in the case that the container does not return EJBs capable of all local interfaces. -- Eric Covener cove...@gmail.com
[jira] Commented: (OWB-435) What is the expected result for following 2 decorators?
[
https://issues.apache.org/jira/browse/OWB-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899050#action_12899050
]
Joe Bergmark commented on OWB-435:
--
Had a chance to dig into #1 today and there does appear to be a bug here. At
least in my testing, the call to
ownerCreationalContext.getDependentDecorator(decorator); always returns null,
so we end up creating a new Decorator instance each time another method is
called on the longer lived class. I'll go ahead and open a JIRA issue for this
and try to determine why that is the case.
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() + );
}
}
decorators
classcom.jcdi.test.UserDecorator1/class
classcom.jcdi.test.UserDecorator2/class
/decorators
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OWB-440) WebBeansDecoratorConfig.getDecoratorStack always returns new Decorators
[ https://issues.apache.org/jira/browse/OWB-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899082#action_12899082 ] Joe Bergmark commented on OWB-440: -- Solving this seems to be pretty straight forward. CreationalContextImpl's getDependentDecorators() was previously always creating an empty list and iterating over that list. Changing this to pass the instance and looking up the dependent creational contexts using by object instance allows us to find the dependent decorators. This mimics the behavior the interceptor version of this method. However, this change appears to break the MultipleDecoratorStackTest unit test, so I'm going to hold off until I can figure out if that test itself is broken, or if the DelegateHandler or surrounding code made some bad assumptions about a clean decorator stack each time which may no longer be true. WebBeansDecoratorConfig.getDecoratorStack always returns new Decorators --- Key: OWB-440 URL: https://issues.apache.org/jira/browse/OWB-440 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-1 Reporter: Joe Bergmark Assignee: Joe Bergmark WebBeansDecoratorConfig.getDecoratorStack's call to ownerCreationalContext.getDependentDecorator(decorator) always returns null, even if the owning bean is called multiple times within its lifecycle. Because of this, you always get a new instance of the Decorators for each method call when you would expect Dependant scoped instances to live as long as their parent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCusS] openwebbeans.configuration new
Hi! I was on vacation over the weekend and had an idea about how to improve our configuration mechanism. I hacked the idea while flying back from Cologne and now all is working again. The change is actually not really big, I just like to get rid of our openwebbeans-*.properties and replace them with the following mechanism: There are still multiple property files for the same configuration, thus still allowing 'overriding' a configuration. But instead of manually looking for defined 'extensions' I just define a 'configuration.ordinal' inside the property thus I define webbeans-impl/ openwebbeans.properties with 'configuration.ordinal=10' webbeans-web/ openwebbeans.properties with 'configuration.ordinal=11' webbeans-jsf/ openwebbeans.properties with 'configuration.ordinal=12' If a properties file doesn't define 'configuration.ordinal' then a value of 100 is assumed. The algorithm is easy: .) load all properties you can find with the name .) sort them via configuration.ordinal in ascending order .) overload them as we do already, but instead of some defined names we now just use the sorted list of properties. WDYT? It's all ready to get checked in :) LieGrue, strub
[jira] Resolved: (OWB-440) WebBeansDecoratorConfig.getDecoratorStack always returns new Decorators
[ https://issues.apache.org/jira/browse/OWB-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bergmark resolved OWB-440. -- Fix Version/s: 1.0.0-alpha-2 Resolution: Fixed Fixed the last remaining problem from the unit test. When we found the existing decorator in the creational context we weren't updating the delegate so the old one would mistakenly get reused and we would lose our position in the decorator stack. WebBeansDecoratorConfig.getDecoratorStack always returns new Decorators --- Key: OWB-440 URL: https://issues.apache.org/jira/browse/OWB-440 Project: OpenWebBeans Issue Type: Bug Components: Interceptor and Decorators Affects Versions: 1.0.0-alpha-1 Reporter: Joe Bergmark Assignee: Joe Bergmark Fix For: 1.0.0-alpha-2 WebBeansDecoratorConfig.getDecoratorStack's call to ownerCreationalContext.getDependentDecorator(decorator) always returns null, even if the owning bean is called multiple times within its lifecycle. Because of this, you always get a new instance of the Decorators for each method call when you would expect Dependant scoped instances to live as long as their parent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
