[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-tabpanel&focusedCommentId=12898074#action_12898074
]
Joe Bergmark commented on OWB-435:
--
I agree that #1 sounds like a bug. I'll try and take a look at it
#2 is probably just the way it has to work. You can't know when the dependent
Decorators are built up what method is going to be called. Even if you could,
you don't know if another Decorator in the stack might have changed the method
to one that later Decorator could have been involved with.
> 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?
[
https://issues.apache.org/jira/browse/OWB-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898041#action_12898041
]
Eric Covener commented on OWB-435:
--
#1 seems like very wrong behavior
> 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?
[
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.
Re: Failover Service
I suspect a lot of servers proactively propagate the session information across servers in case a failover occurs. Once the session itself has "failed over" then they will stay on that server, but the data might have been moved over in lots of little chunks before then. Sincerely, Joe On Thu, Aug 12, 2010 at 2:02 PM, Mark Struberg wrote: > hmm, how your cluster environment looks like, but mine definitely only allows > 1server at a time to handle a session! > > So after the WHOLE session got moved to a different node (moving only parts of > the session will almost always break the system) it must _not_ be served by > this > VM anymore. You will always end up with inconsistent data otherwise! > > LieGrue, > strub > > > > - Original Message >> From: YING WANG >> To: dev@openwebbeans.apache.org >> Sent: Thu, August 12, 2010 6:28:24 PM >> Subject: Re: Failover Service >> >> My original patch does use WebBeanConfigurationLister, but that requires 2 >> attributes to be set on a sessionContext, one is WebBeanConfigurationLister >> itself which will receive HttpSessionActivationListener callbacks, the >> problem is that it could not hold any session specific data for >> serialization. The other is the FailoverBagWrapper/FailoverBag which holds >> serializable data for the session. >> >> For failover, the container I use, it supports time-based failover >> (serialize a session to another JVM every X seconds) or request based >> failover (serialize a session when every request is done). So I need at >> least FailoverBagWrapper/FailoverBag attribute being set on the >> sessionContext to be ready for serialization at any time. The >> sessionWillPassivate() is NOT invoked for the failover case since the >> current session will continue handling requests on the >> current JVM. SessionWillPassivate only be invoked when I gracefully shut >> down a server. In the end, I make another change to move >> HttpSessionActivationListener to FailoverBagWrapper, only use one attribute >> on the sessionContext and WebBeanConfigurationLister's >> HttpSessionActivationListener is not used. >> >> I could revert it back since both work for me. >> >> BTW, BeanManager, Interceptor, Decorator, resources beans are not working >> yet. I will fix these later.. >> >> From: Gurkan Erdogdu >> To: dev@openwebbeans.apache.org >> Date: 08/12/2010 11:11 AM >> Subject: Re: Failover Service >> >> >> >> +1, >> >> what I was trying to say :) >> >> >> >> From: Mark Struberg >> To: dev@openwebbeans.apache.org >> Sent: Thu, August 12, 2010 6:08:25 PM >> Subject: Re: Failover Service >> >> What about moving this function to the already registerd >> WebBeansConfiguarionListener? >> >> LieGrue, >> strub >> >> >> >> - Original Message >> > From: Gurkan Erdogdu >> > To: dev@openwebbeans.apache.org >> > Sent: Thu, August 12, 2010 5:01:37 PM >> > Subject: Failover Service >> > >> > Hello Ying, >> > >> > How does failover service work ? FailoverBagWrapper implements >> > HttpSessionActivationListener, I think that to use failover service, we >> add >> > listener to web.xml ? >> > >> > >> > Is it possible to update code to use WebBeansConfigurationListener for >> > sessionWillPassivate and sessionDidActivate methods instead of >> > FailoverBagWrapper? >> > >> > thanks >> > >> > --Gurkan >> > >> > >> > >> > > > >
[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-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.
Re: Failover Service
hmm, how your cluster environment looks like, but mine definitely only allows 1server at a time to handle a session! So after the WHOLE session got moved to a different node (moving only parts of the session will almost always break the system) it must _not_ be served by this VM anymore. You will always end up with inconsistent data otherwise! LieGrue, strub - Original Message > From: YING WANG > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 6:28:24 PM > Subject: Re: Failover Service > > My original patch does use WebBeanConfigurationLister, but that requires 2 > attributes to be set on a sessionContext, one is WebBeanConfigurationLister > itself which will receive HttpSessionActivationListener callbacks, the > problem is that it could not hold any session specific data for > serialization. The other is the FailoverBagWrapper/FailoverBag which holds > serializable data for the session. > > For failover, the container I use, it supports time-based failover > (serialize a session to another JVM every X seconds) or request based > failover (serialize a session when every request is done). So I need at > least FailoverBagWrapper/FailoverBag attribute being set on the > sessionContext to be ready for serialization at any time. The > sessionWillPassivate() is NOT invoked for the failover case since the > current session will continue handling requests on the > current JVM. SessionWillPassivate only be invoked when I gracefully shut > down a server. In the end, I make another change to move > HttpSessionActivationListener to FailoverBagWrapper, only use one attribute > on the sessionContext and WebBeanConfigurationLister's > HttpSessionActivationListener is not used. > > I could revert it back since both work for me. > > BTW, BeanManager, Interceptor, Decorator, resources beans are not working > yet. I will fix these later.. > > From: Gurkan Erdogdu > To: dev@openwebbeans.apache.org > Date: 08/12/2010 11:11 AM > Subject: Re: Failover Service > > > > +1, > > what I was trying to say :) > > > > From: Mark Struberg > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 6:08:25 PM > Subject: Re: Failover Service > > What about moving this function to the already registerd > WebBeansConfiguarionListener? > > LieGrue, > strub > > > > - Original Message > > From: Gurkan Erdogdu > > To: dev@openwebbeans.apache.org > > Sent: Thu, August 12, 2010 5:01:37 PM > > Subject: Failover Service > > > > Hello Ying, > > > > How does failover service work ? FailoverBagWrapper implements > > HttpSessionActivationListener, I think that to use failover service, we > add > > listener to web.xml ? > > > > > > Is it possible to update code to use WebBeansConfigurationListener for > > sessionWillPassivate and sessionDidActivate methods instead of > > FailoverBagWrapper? > > > > thanks > > > > --Gurkan > > > > > > >
Re: Failover Service
My original patch does use WebBeanConfigurationLister, but that requires 2 attributes to be set on a sessionContext, one is WebBeanConfigurationLister itself which will receive HttpSessionActivationListener callbacks, the problem is that it could not hold any session specific data for serialization. The other is the FailoverBagWrapper/FailoverBag which holds serializable data for the session. For failover, the container I use, it supports time-based failover (serialize a session to another JVM every X seconds) or request based failover (serialize a session when every request is done). So I need at least FailoverBagWrapper/FailoverBag attribute being set on the sessionContext to be ready for serialization at any time. The sessionWillPassivate() is NOT invoked for the failover case since the current session will continue handling requests on the current JVM. SessionWillPassivate only be invoked when I gracefully shut down a server. In the end, I make another change to move HttpSessionActivationListener to FailoverBagWrapper, only use one attribute on the sessionContext and WebBeanConfigurationLister's HttpSessionActivationListener is not used. I could revert it back since both work for me. BTW, BeanManager, Interceptor, Decorator, resources beans are not working yet. I will fix these later.. From: Gurkan Erdogdu To: dev@openwebbeans.apache.org Date: 08/12/2010 11:11 AM Subject: Re: Failover Service +1, what I was trying to say :) From: Mark Struberg To: dev@openwebbeans.apache.org Sent: Thu, August 12, 2010 6:08:25 PM Subject: Re: Failover Service What about moving this function to the already registerd WebBeansConfiguarionListener? LieGrue, strub - Original Message > From: Gurkan Erdogdu > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 5:01:37 PM > Subject: Failover Service > > Hello Ying, > > How does failover service work ? FailoverBagWrapper implements > HttpSessionActivationListener, I think that to use failover service, we add > listener to web.xml ? > > > Is it possible to update code to use WebBeansConfigurationListener for > sessionWillPassivate and sessionDidActivate methods instead of > FailoverBagWrapper? > > thanks > > --Gurkan > > >
Re: ELContextStore Question
Hi! Good catch, clearing it in stopRequestContext should be enough. LieGrue, strub - Original Message > From: Eric Covener > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 6:13:49 PM > Subject: Re: ELContextStore Question > > slightly off-topic, but Mark I was wondering if you could explain why > we need to call destroyELContextStore from both the > WebBeansConfigurationListener and from the end of the RequestContext? > Is there some path that would only hit one of these callers? >
Re: ELContextStore Question
slightly off-topic, but Mark I was wondering if you could explain why we need to call destroyELContextStore from both the WebBeansConfigurationListener and from the end of the RequestContext? Is there some path that would only hit one of these callers?
Re: Failover Service
+1, what I was trying to say :) From: Mark Struberg To: dev@openwebbeans.apache.org Sent: Thu, August 12, 2010 6:08:25 PM Subject: Re: Failover Service What about moving this function to the already registerd WebBeansConfiguarionListener? LieGrue, strub - Original Message > From: Gurkan Erdogdu > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 5:01:37 PM > Subject: Failover Service > > Hello Ying, > > How does failover service work ? FailoverBagWrapper implements > HttpSessionActivationListener, I think that to use failover service, we add > listener to web.xml ? > > > Is it possible to update code to use WebBeansConfigurationListener for > sessionWillPassivate and sessionDidActivate methods instead of > FailoverBagWrapper? > > thanks > > --Gurkan > > >
Re: Failover Service
What about moving this function to the already registerd WebBeansConfiguarionListener? LieGrue, strub - Original Message > From: Gurkan Erdogdu > To: dev@openwebbeans.apache.org > Sent: Thu, August 12, 2010 5:01:37 PM > Subject: Failover Service > > Hello Ying, > > How does failover service work ? FailoverBagWrapper implements > HttpSessionActivationListener, I think that to use failover service, we add > listener to web.xml ? > > > Is it possible to update code to use WebBeansConfigurationListener for > sessionWillPassivate and sessionDidActivate methods instead of > FailoverBagWrapper? > > thanks > > --Gurkan > > >
Failover Service
Hello Ying, How does failover service work ? FailoverBagWrapper implements HttpSessionActivationListener, I think that to use failover service, we add listener to web.xml ? Is it possible to update code to use WebBeansConfigurationListener for sessionWillPassivate and sessionDidActivate methods instead of FailoverBagWrapper? thanks --Gurkan
Re: svn commit: r984612 - in /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context: AbstractContext.java creational/BeanInstanceBag.java
Thanks Gurkan,
looks even better now ;)
This was in fact the most pressing gut feeling which I needed to check for
before we can release 1.0.
I hope that all the random errors I got occasionally under heavy load finally
vanished now!
LieGrue,
strub
- Original Message
> From: Gurkan Erdogdu
> To: dev@openwebbeans.apache.org
> Sent: Thu, August 12, 2010 8:53:32 AM
> Subject: Re: svn commit: r984612 - in
>/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context:
>AbstractContext.java creational/BeanInstanceBag.java
>
> Hello Mark
>
>
> It seems that your observation is correct! Instead of using synchronized,I
>have
>
> changed with Java 5 style locking
>
> Thanks;
>
> --Gurkan
>
>
>
> From: Mark Struberg
> To: dev@openwebbeans.apache.org
> Sent: Thu, August 12, 2010 1:55:52 AM
> Subject: Re: svn commit: r984612 - in
> /openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context:
> AbstractContext.java creational/BeanInstanceBag.java
>
> Hi folks!
>
> since this is pretty heavy stuff, I'd be happy if someone could review my
> changes.
>
> txs and LieGrue,
> strub
>
>
>
>
> - Original Message
> > From: "strub...@apache.org"
> > To: comm...@openwebbeans.apache.org
> > Sent: Thu, August 12, 2010 12:51:26 AM
> > Subject: svn commit: r984612 - in
> >/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context:
> >AbstractContext.java creational/BeanInstanceBag.java
> >
> > Author: struberg
> > Date: Wed Aug 11 22:51:26 2010
> > New Revision: 984612
> >
> > URL: http://svn.apache.org/viewvc?rev=984612&view=rev
> > Log:
> > OWB-437 improve synchronization block for creating new contextual
>instances
> >
> > by moving it to the ContextualBeanBag. This way only the beanbag will get
> > locked and not the whole container anymore
> >
> > Modified:
> >
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/AbstractContext.java
>a
> >
> >
> >
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/creational/BeanInstanceBag.java
>a
> >
> >
> >
> > Modified:
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/AbstractContext.java
>a
> >
> >
> > URL: :
>>http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/AbstractContext.java?rev=984612&r1=984611&r2=984612&view=diff
>f
> >
> >
> >
>==
> > ; ---
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/AbstractContext.java
>a
> >
> > a (original)
> > +++
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/AbstractContext.java
>a
> >
> > Wed Aug 11 22:51:26 2010
> > @@ -195,7 +195,7 @@ public abstract class AbstractContext im
> > * {...@inheritdoc}
> >*/
> > @SuppressWarnings("unchecked")
> > - protected synchronized T getInstance(Contextual contextual,
> >CreationalContext creationalContext)
> > + protected T getInstance(Contextual contextual,
> >CreationalContext creationalContext)
> > {
> > T instance = null;
> >
> > @@ -205,9 +205,11 @@ public abstract class AbstractContext im
> >{
> >createContextualBag(contextual, creationalContext);
> >}
> > -
> > +
> > + bag = (BeanInstanceBag)componentInstanceMap.get(contextual);
> > +
> > //Look for instance
> > - instance =
> >(T)componentInstanceMap.get(contextual).getBeanInstance();
> >
> > +instance = bag.getBeanInstance();
> > if (instance != null)
> > {
> >return instance;
> > @@ -225,16 +227,8 @@ public abstract class AbstractContext im
> >//No instance
> >if(instance == null)
> >{
> > - instance = contextual.create(creationalContext);
> > - }
> > -
> > - //If succesfull creation
> > - if (instance != null)
> > - {
> > - bag =
> >(BeanInstanceBag)this.componentInstanceMap.get(contextual);
> > - bag.setBeanInstance(instance);
> > + instance = bag.create(contextual);
> > }
> > -
> > }
> > }
> >
> >
> > Modified:
>>openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/creational/BeanInstanceBag.java
>a
> >
> >
> > URL:
>>http://svn.apache.org/viewvc/openwebbeans/trunk/webbeans-impl/src/main/java/org/apache/webbeans/context/creational/BeanInstanceBag.java?rev=984612&r1=984611&r2=984612&view=diff
>f
> >
> >
> >
>
