January 2007 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Issues with passivation of nested SFSBs

by bstansberry＠jboss.com

I'm seeing some issues related to caching and passivation of nested SFSBs (i.e. one SFSB holds a ref to another, i.e. through an @EJB annotation). I'd like to get some input as to what the proper behavior is. What I'm seeing is: If the nested bean declares an @Remote interface, when the parent bean is being constructed for the nested bean an instance of StatefulBeanContext ends up being cached. This works fine. If the nested bean does not declare an @Remote interface, when the parent bean is being constructed, for the nested bean an instance of ProxiedStatefulBeanContext ends up being cached. This leads to problems. The problem occurs if the parent bean is later removed. This does not result in a call to remove the child bean from the cache. (I don't know if that's a problem or not; Chapter 11.7 of Bill Burke's book says it should be removed, but I couldn't find a discussion of that in the spec.) A replicated ProxiedStatefulBeanContext is useless if its parent is not in the cache. The replication clears the transient reference to the parent bean. If the context is later used, ProxiedStatefulBeanContext.getDelegate() will attempt to look up the parent, which will result in a NoSuchEjbException. The problem occurs when the background passivation thread decides to passivate the orphaned ProxiedStatefulBeanContext and calls prePassivate(). You get this: | javax.ejb.NoSuchEJBException: Could not find Stateful bean: a1g1m-b11vx1-exf6itu4-1-exf6mcqp-1v | at org.jboss.ejb3.cache.tree.StatefulTreeCache.get(StatefulTreeCache.java:148) | at org.jboss.ejb3.stateful.StatefulBeanContextReference.getBeanContext(StatefulBeanContextReference.java:72) | at org.jboss.ejb3.stateful.ProxiedStatefulBeanContext.getDelegate(ProxiedStatefulBeanContext.java:70) | at org.jboss.ejb3.stateful.ProxiedStatefulBeanContext.getContainer(ProxiedStatefulBeanContext.java:213) | at org.jboss.ejb3.stateful.StatefulBeanContext.prePassivate(StatefulBeanContext.java:178) | at org.jboss.ejb3.cache.tree.StatefulTreeCache$ClusteredStatefulCacheListener.nodePassivated(StatefulTreeCache.java:376) | at org.jboss.cache.notifications.Notifier.notifyNodePassivated(Notifier.java:423) | ... Id a1g1m-b11vx1-exf6itu4-1-exf6mcqp-1v belongs to the parent bean. Some solutions I can see are: 1) If the child bean is meant to be removed along with the parent, fix whatever's preventing that from happening. 2) Have the StatefulCache impls not cache instances of ProxiedStatefulBeanContext. I don't understand the usage of this class well enough to know whether that's a valid solution or not. I doubt it. 3) Have the StatefulCache impls catch NoSuchEjbException when they call prePassivate(). Check if the context type is ProxiedStatefulBeanContext; if it is, suppress the exception and remove the useless context from the cache. That's ugly but limited in scope. Any comments/suggestions are most appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007065#4007065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007065

17 years, 5 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: testsuite's log4j configuration leads to large reports

by scott.stark＠jboss.org

I was thinking of a custom xml formatter that produced the current TEST-testname.xml along with a TEST-summary-testname.xml that would not contain any stderr/out output to feed into the summary. It may also be easier to just write a simple summary java program and bypas the use of xsl for the simple xml/txt summaries. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007060#4007060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007060

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by weston.price＠jboss.com

+1 Well said. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007058#4007058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007058

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by scott.stark＠jboss.org

Yes, its the plethora of legacy dtds, as well as features like the wildcard issue. We should be looking first to get support for these in the jaxb project as extensions, and then worry about what can be standarized. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007057#4007057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007057

17 years, 5 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: testsuite's log4j configuration leads to large reports

by jaroslaw.kijanowski

Which formatter do you mean? JUnit? there are just three - xml, brief and plain... or a custom one. We need for every test the DEBUG messages - this lead to bigger TEST-testname.xml files - this leads to a huge (unparseable by XSLT) TESTS-Testsuites.xml file. What do you think about this: Let's generate TEST-testname.xml files like before, with all the DEBUG messages Let's parse 817 TEST-testname.xml files (the whole testsuite) to 817 small TEST-testname_short_version.xml files, just for the purpose to create this two summaries. Now we could generate two TESTS-Testsuites.xml files, the big one for the html report (which does not nead a XSL Transformation) and the small one for these summaries where XSLT is involved. Pros: We can leave DEBUG messages in the html report Cons: - we need a lot of more space ~ 200MB per testsuite - it could take a while (how long? no idea...) to parse 817 files to 817 smaller files View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007056#4007056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007056

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by weston.price＠jboss.com

That's fine, and I many ways I agree with you. However, my next question would be how many legacy use cases do we really have, and more importantly, are there enough cases to develop an entire in-house, non-standard binding framework to handle 2%, 5%? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007055#4007055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007055

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by scott.stark＠jboss.org

"weston.price(a)jboss.com" wrote : anonymous wrote : | | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. | | | | There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not. | | The spec is not the issue though. Its clearly under defined for our legacy usecases. I'm more interested in implementation first, spec second. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007053#4007053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007053

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Registering a bean as an aspect in the bootstrap

by scott.stark＠jboss.org

It should be possible because the MainDeployer is just a bean in the bootstrap process. The classes should all be in the same class loader space, and we should be able to know the aspects that will be applied before any bean class is loaded (unless that is a limitation of the current bean introspection implementation). Adrian thought this should be possible when I asked him about it this morning. I'm going to create a simpler testcase in the mc project to describe and validate the usecase I'm after. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007052#4007052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007052

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by weston.price＠jboss.com

anonymous wrote : | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. | There are a lot of specs that I think we should be involved in (ie JDBC etc) and this is one of them. Time constraints notwithstanding, I think it's important to get our voice/participation. I hate the NIH syndrome and I think we fall prey to it more often than not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007051#4007051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007051

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JAXBDeployer

by scott.stark＠jboss.org

"jason.greene(a)jboss.com" wrote : | Either way the mapping of namespace to classes has to be known before unmarshalling, the difference is that you can lazy load classes with JBossXB. If lazy discovery is important, we should get involved with the spec and get it added. | anonymous wrote : | | The more immeadiate question is whether getting involved with jaxb to get jbossxb features into it is worth while. | | | | "jason.greene(a)jboss.com" wrote : | | | The issue with a mapping like this is that if there is any similarity between the types that could be present on a wildcard, then using schema subtyping is more appropriate. | | | | | I don't see how that resolves the problem. That just introduces a common base schema type for the interface, but it still has a wildcard because the implementation details are outside of the contract. This is a common issue with a plugin architecture. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4007049#4007049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4007049

17 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2007