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

[Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

by kabir.khan＠jboss.com

With the new classloaders, how do I add a URL to the classloader? i.e. something similar to the old: | private URL createURLAndAddToLoader(ClassLoader cl, File tempdir) throws IOException | { | URL tmpURL = tempdir.toURL(); | URL tmpCP = new URL(tmpURL, "?dynamic=true"); | | RepositoryClassLoader ucl = (RepositoryClassLoader) cl; | | // We may be undeploying. | if (ucl.getLoaderRepository() != null) | { | ucl.addURL(tmpCP); | } | | return tmpCP; | } | | Thinking about it, this probably looks somewhat dangerous, but I still think I need to be able to do something similar... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090802#4090802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090802

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by ALRubinger

I will implement as detailed in the previous post tomrorrow. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090799#4090799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090799

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by bdecoste

OK, after a lengthy discussion with Burke, Carlo, and Andrew here is the decision - we are going to remove the impls of EJBObject/EJBLocalObject by default. If a 2.1 view is required, the Remote/Local interfaces will need to explicitly extend EJBObject/EJBLocalObject. Then the proxy will implement those interfaces. - This removes the restriction on remove() and other EJBObject methods - This still provides availability of a full 2.1 view. Minimal inconvenience for the developer as they already have to provide a home interface that extends EJBHome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090797#4090797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090797

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - NestedBeanUnitTestCase failure with buddy replication enable

by bstansberry＠jboss.com

Carlo, Re the Branch_4_2 failure. This is a can of worms. Worm 1) The test bean tracks when @PrePassivate and @PostActivate are called by incrementing counters; test checks for expected values as replication/passivation occur. Problem: if @Remote bean is accessed on node0 and then passivated, counter is incremented in @PrePassivate. But the passivation does not trigger replication; updated counter does not get replicated. So, if the call to check the passivation count gets executed on node1, the counter is incorrect and we get assertion failure. This is the fundamental cause of the intermittent failures in hudson. Solution: make sure the calls all happen on the same node. Question: since an @PrePassivate call could affect non-transient bean state, should we replicate the bean state after the @PrePassivate but before the actual passivation? Note this is only an issue if the bean is configured to disable the @PrePassivate call before replication; in the default case we don't call @PrePassivate before passivation since we already called it on the last request before replication. This is more a question for the new impl in trunk; don't think it's doable in Branch_4_2. I vote -0; seems like a real edge case. Worm 2) With buddy replication enabled, when data is replicated, JBC stores it on the remote nodes in a separate "backup" area of the cache tree. The JBC passivation code does not work properly in this area: http://jira.jboss.com/jira/browse/JBCACHE-1190 http://jira.jboss.com/jira/browse/JBCACHE-1192 Not fixable for 4.2.2 unless the webservice change screws everything up so bad that it gets delayed a long time. *Must* be fixed for EAP 4.2.0.CP02. Impact on 4.2.2: a) Buddy replication isn't the default and isn't even mentioned in the cache config; people using it will have to go out of their way to set it up. b) If they do use buddy replication, JBCACHE-1190 means the backup copies of SFSBs will never get passivated from the cache to disk. c) By default, SFSBs have a remove timeout of 0; container never removes them. This combined with b) == memory leak. d) Workaround to this is for me to change the std cache config so it will evict things from the "backup" region based on a global set of rules. JBCACHE-1192 means that if beans are evicted that could cause problems. So, my change would configure the eviction to only occur if a node is idle for a long time (say 30 mins). If a bean is inactive longer than that, and the client makes another request, AND that request fails over, then they'll get NoSuchEJBException. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090792#4090792 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090792

16 years, 8 months

1
0
0 / 0

[Design of JBossXB] - NonNullLinkedHashSet

by scott.stark＠jboss.org

In the metadata project there is use of NonNullLinkedHashSet that is causing parse problems. In the jbossxb tests these uses have been commented out. What is the issue with this type? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090783#4090783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090783

16 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Eviction and buddy backup regions

by bstansberry＠jboss.com

Unfortunately, there's another major problem with eviction and buddy replication. If a node is only available via a cache loader, data gravitation fails. http://jira.jboss.com/jira/browse/JBCACHE-1192 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090782#4090782 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090782

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by wolfc

If a bean use the EJB 2.1 view it can't have a remove method with another signature, so no problem there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090774#4090774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090774

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by wolfc

"gavin.king(a)jboss.com" wrote : "bill.burke(a)jboss.com" wrote : I know the intention of the specification. We can challenge any TCK test based on knowledge of this intention. IIRC, the spec says *nothing* about requiring an EJB 3.0 reference to be castable or narrowable to EJBObject. This is just something *JBoss* threw in. | | Correct, the spec does not require this. In fact, it says the exact opposite in section 3.4. | Exactly and because we threw this in we get the remove signature problem. How about we take out the explicit binding of EJBObject in the proxy factories. If one of the interfaces extends EJBObject it'll be picked up again. The home interface will be bound to .../home anyway (or bound together if requested), which is always a EJB 2.1 home interface, so no clash there. Only the EJB 2.1 home should return proxies which implement EJBObject. So .../remote and .../local should all be EJB 3 bindings. Which leaves getInvokedBusinessInterface. I really would like to see it return the invoked business interface. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090770#4090770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090770

16 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Maven ESB plugin

by Kevin.Conner＠jboss.com

"jplenhart" wrote : is this the correct plugin? It is the correct plugin but you are using the wrong repository. Use the repository from my previous post. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090766#4090766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090766

16 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-786

by bdecoste

The suggestion to only have the proxy implement EJBObject if the Remote interface extends it is the only one that makes any sense. As I've said, if they want EJB2.1 clients they already have to create a home interface so it's not an inconvenience. And we can work through whatever TCK problems that may arise. I second the motion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090765#4090765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090765

16 years, 8 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 October 2007