[jira] Commented: (OWB-385) implement passivation of managed beans in ServletContextListener
[
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893092#action_12893092
]
Mark Struberg commented on OWB-385:
---
which paragraph in the spec defines this behaviour?
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.
Re: is usage of BaseEjbBean.iface safe?
On Wed, Jul 28, 2010 at 1:40 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: Good catch Eric! Not mean that current logic is wrong. Bean API types are local interfaces of the EJB bean . We check all injection fields at deployment time for validation. If there is no validation error, using of EJB local interfaces are correct. What is the problem that you think about? My concern is that at runtime, each time we perform injection various threads are poking around at BaseEjbBean.iface when really all they need to is use the iface on the stack to create their proxies/instances. This is because there is not actually one iface per BaseEjbBean (EJB class), just one per injection point. -- Eric Covener cove...@gmail.com
[jira] Updated: (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 updated OWB-430: - Attachment: OWB-430.patch 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 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] Created: (OWB-431) Generic Type Inheritance not resolved correctly
Generic Type Inheritance not resolved correctly
---
Key: OWB-431
URL: https://issues.apache.org/jira/browse/OWB-431
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: 1.0.0-alpha-1
Environment: standard OWB configuration
Reporter: Bill Wigger
Assignee: Gurkan Erdogdu
Priority: Minor
Fix For: 1.0.0-alpha-2
WebBean is defined as:
@Named
public class MethodTypeProduces1T extends Bc {
@Produces @Dependent @Named(ProMethodParameterized3) ArrayListT
methodPT3() {
and injected as:
@Named
@Dependent
public class ProMethodTestGroup3A {
public @Inject @Dependent @Named(ProMethodParameterized3)
ArrayListDc pt3;
with BC extending DC as follows:
public class Bc extends Dc implements Fi {
gives this error:
Jul 28, 2010 9:26:51 AM org.apache.webbeans.config.BeansDeployer deploy
SEVERE:
Throwable occurred: javax.enterprise.inject.UnsatisfiedResolutionException: Api
type [java.util.ArrayList] is not found with the qualifiers
[...@javax.inject.named(value=ProMethodParameterized3)] for injection into
Field Injection Point, field name : pt3, Bean Owner :
[Name:proMethodTestGroup3A,WebBeans Type:MANAGED,API
Types:[com.ibm.jcdi.test.ProMethodTestGroup3A,java.lang.Object],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]
at
org.apache.webbeans.container.ResolutionUtil.checkResolvedBeans(ResolutionUtil.java:121)
at
org.apache.webbeans.container.InjectionResolver.checkInjectionPoints(InjectionResolver.java:185)
at
org.apache.webbeans.container.BeanManagerImpl.validate(BeanManagerImpl.java:1025)
injection should be checked/resolved here in
org.apache.webbeans.util.ClassUtil, but this method returns false
public static boolean checkRequiredTypeIsClassAndBeanTypeIsVariable(Type
beanTypeArg, Type requiredTypeArg)
{
Class? clazzRequiredType = (Class?)requiredTypeArg;
TypeVariable? tvBeanTypeArg = (TypeVariable?)beanTypeArg;
Type tvBound = tvBeanTypeArg.getBounds()[0];
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzTvBound != Object.class)
{
if(!clazzTvBound.isAssignableFrom(clazzRequiredType))
{
return false;
}
}
}
return true;
}
But since clazzTvBound is Bc and classRequiredType is Dc
Bc.isAssignableFrom(Dc) returns false, so the ! is true, and the function
returns false.
fix seems to simply go back to the old code in this routine, this code was
changeed on 4/28, and
I can't see why is was changed.
But the check needs to verify that the required class can be assigned from the
given bean class, as follows:
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzRequiredType.isAssignableFrom(clazzTvBound))
{
return true;
}
}
return false;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OWB-431) Generic Type Inheritance not resolved correctly
[
https://issues.apache.org/jira/browse/OWB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Wigger updated OWB-431:
Attachment: ClassUtilPatch.txt
fix for problem reported (backed in the old code as of 4/21)
Generic Type Inheritance not resolved correctly
---
Key: OWB-431
URL: https://issues.apache.org/jira/browse/OWB-431
Project: OpenWebBeans
Issue Type: Bug
Components: Injection and Lookup
Affects Versions: 1.0.0-alpha-1
Environment: standard OWB configuration
Reporter: Bill Wigger
Assignee: Gurkan Erdogdu
Priority: Minor
Fix For: 1.0.0-alpha-2
Attachments: ClassUtilPatch.txt
Original Estimate: 2h
Remaining Estimate: 2h
WebBean is defined as:
@Named
public class MethodTypeProduces1T extends Bc {
@Produces @Dependent @Named(ProMethodParameterized3) ArrayListT
methodPT3() {
and injected as:
@Named
@Dependent
public class ProMethodTestGroup3A {
public @Inject @Dependent @Named(ProMethodParameterized3)
ArrayListDc pt3;
with BC extending DC as follows:
public class Bc extends Dc implements Fi {
gives this error:
Jul 28, 2010 9:26:51 AM org.apache.webbeans.config.BeansDeployer deploy
SEVERE:
Throwable occurred: javax.enterprise.inject.UnsatisfiedResolutionException:
Api type [java.util.ArrayList] is not found with the qualifiers
[...@javax.inject.named(value=ProMethodParameterized3)] for injection into
Field Injection Point, field name : pt3, Bean Owner :
[Name:proMethodTestGroup3A,WebBeans Type:MANAGED,API
Types:[com.ibm.jcdi.test.ProMethodTestGroup3A,java.lang.Object],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default,javax.inject.Named]]
at
org.apache.webbeans.container.ResolutionUtil.checkResolvedBeans(ResolutionUtil.java:121)
at
org.apache.webbeans.container.InjectionResolver.checkInjectionPoints(InjectionResolver.java:185)
at
org.apache.webbeans.container.BeanManagerImpl.validate(BeanManagerImpl.java:1025)
injection should be checked/resolved here in
org.apache.webbeans.util.ClassUtil, but this method returns false
public static boolean checkRequiredTypeIsClassAndBeanTypeIsVariable(Type
beanTypeArg, Type requiredTypeArg)
{
Class? clazzRequiredType = (Class?)requiredTypeArg;
TypeVariable? tvBeanTypeArg = (TypeVariable?)beanTypeArg;
Type tvBound = tvBeanTypeArg.getBounds()[0];
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzTvBound != Object.class)
{
if(!clazzTvBound.isAssignableFrom(clazzRequiredType))
{
return false;
}
}
}
return true;
}
But since clazzTvBound is Bc and classRequiredType is Dc
Bc.isAssignableFrom(Dc) returns false, so the ! is true, and the function
returns false.
fix seems to simply go back to the old code in this routine, this code was
changeed on 4/28, and
I can't see why is was changed.
But the check needs to verify that the required class can be assigned from
the given bean class, as follows:
if(tvBound instanceof Class)
{
Class? clazzTvBound = (Class?)tvBound;
if(clazzRequiredType.isAssignableFrom(clazzTvBound))
{
return true;
}
}
return false;
--
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
[
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893192#action_12893192
]
Mark Struberg commented on OWB-385:
---
I honestly do not yet see the problem you like to solve ;)
What do you like to achieve by adding your solution?
We need to tweak our SessionContext and ConversationContext of course, but
that's a completely different story.
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
[
https://issues.apache.org/jira/browse/OWB-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893218#action_12893218
]
Mark Struberg commented on OWB-385:
---
ok I c. I think we have to put a lot of work into real cluster support. I'd
prefer to store our beans in the Session and let the container perform session
distribution instead of doing this ourselfs. Because swapping beans only
partially might be hard to do right.
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.
Re: is usage of BaseEjbBean.iface safe?
On Wed, Jul 28, 2010 at 7:55 AM, Eric Covener cove...@gmail.com wrote: On Wed, Jul 28, 2010 at 1:40 AM, Gurkan Erdogdu gurkanerdo...@yahoo.com wrote: Good catch Eric! Not mean that current logic is wrong. Bean API types are local interfaces of the EJB bean . We check all injection fields at deployment time for validation. If there is no validation error, using of EJB local interfaces are correct. What is the problem that you think about? My concern is that at runtime, each time we perform injection various threads are poking around at BaseEjbBean.iface when really all they need to is use the iface on the stack to create their proxies/instances. This is because there is not actually one iface per BaseEjbBean (EJB class), just one per injection point. Although now I'm not sure if we can properly know the injected iface when it's time to get the instance, since we are funneled through the Contextual.getInstance() interface. But stashing away the injected iface in the BaseEjbBean in between proxy creation and obtaining the instance does not seem threadsafe. -- Eric Covener cove...@gmail.com
