March 2009 - jboss-user - Jboss List Archives

[JBoss Tools (users)] - Re: H10 plugins left when upgrade to H11

by bdlink

You are saying that updates only add? This means that all of the old versions of modules will hang around? Sorry, I did not understand that, and it seems to me that the old modules hanging around would create a lot of trouble. Please clarify that this is what you mean. My point is that an update should update, replacing what went before, not leaving it around. If the update to H10 is H11, should not the H10 plugin directories disappear? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215886#4215886 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215886

15 years, 10 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: on child insert parent, child collection updated in DB b

by dukehoops

"1) Do you *really* need to cache this collection? " No, for a short while we could probably live w/o that. However, there are several other collections that we do need to cache (that's pretty much the point of the project) and thus far I don't see why these failures won't show up there as well. Perhaps I will do that now, and wait and see if someone else chimes in with a take in the meantime. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215883#4215883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215883

15 years, 10 months

1
0
0 / 0

[JBoss AOP] - Re: Using AOP to mock out dependecies for unit-test

by stale.pedersen＠jboss.org

hi again. the problem is within the generated code and not in your pointcutdef. the PersistenceHelper constructor is "wrapped" in aop code when we instrument it, and that method will only accept an object of type PersistenceHelper. - not the interface. thats why it is throwing a classcastexception since it get a MockPersistenceHelper and not a PersistenceHelper. atm there is no way around this, ill discuss with the team if this is something we should change, and ill let you know what we decide. a solution for your problem would be to put the constructor in a method and just intercept that method. something like:public class AOPUnitTestManagerBean { | | private IPersistenceHelper helper; | | public AOPUnitTestManagerBean() { | helper = init(); | } | | private IPersistenceHelper init() { | return new PersistenceHelper(null); | } | | public void createObject(Object o) { | helper.create(o); | } | } View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215881#4215881 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215881

15 years, 10 months

1
0
0 / 0

[JBoss jBPM] - Re: org.hibernate.StaleObjectStateException: jbpm and esb

by sshetty

So is the message harmless and can be ignored ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215880#4215880 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215880

15 years, 10 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: on child insert parent, child collection updated in DB b

by dukehoops

Turning up userCount under REPEATABLE_READ and PESSIMISTIC locking yielded the same failure. So, looks like there are 2 distinct problems: 1) One we've been debugging all along: cache left in incorrect state when one thread wants to remove node while another wants to putForExternalRead (not clear whether the problem is that latter wins or former fails on invocation of RemoveNodeCommand) 2) Under REPEATABLE_READ + MVCC: CacheInvocationDelegate.removeNode(Fqn) returns false and fails to remove() node in question. This happens w/o any concurrency (single thread) Thought latter seems easier to debug, I can (prefer to) live w/o REPEATABLE_READ, so still problem #1 is the one to solve for me ;- View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215879#4215879 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215879

15 years, 10 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: on child insert parent, child collection updated in DB b

by bstansberry＠jboss.com

There's are the core JBC devs who are likely following this thread. I'll be going to meet with some other JBoss clustering devs, so we won't be dropping out of sight. Since you are nearing milestones, and there's no way any bug related to this is going to be fixed in a released version any time soon, some big picture thinking seems called for. :) 1) Do you *really* need to cache this collection? 2) You said PESSIMISTIC & REPEATABLE_READ passes. Is that just on the later problem you posted today, or does it resolve the earlier issue? I expect not -- but if it does, is PESSIMISTIC an option. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215876#4215876 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215876

15 years, 10 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: on child insert parent, child collection updated in DB b

by dukehoops

OK will do: look at the test suite. Good idea to try PESSIMISTIC locking. Results are: PESSIMISTIC & REPEATABLE_READ == pass MVCC & REPEATABLE_READ == fail(-fast ;-) I've debugged the failure down to: -on commit Hibernate calls CollectionAction.evict() (as you mentioned it should) -downstream, CacheInvocationDelegate.removeNode(collection Fqn) calls invoke.invoke *which returns false*. I assume that means that for whatever reason invocation of RemoveNodeCommand fails. Is there someone who may be able to help me track this down in your absence? We're nearing some milestone dates here ;- thanks -nikita View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215868#4215868 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215868

15 years, 10 months

1
0
0 / 0

[JBoss Portal] - Re: Partial Refresh with Multiple Submit Buttons

by fribeiro1

Thanks, Wesley. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215867#4215867 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215867

15 years, 10 months

1
0
0 / 0

[JBoss Messaging] - Re: jms communications in the same jvm in the client side

by clebert.suconic＠jboss.com

JBM 2 will be provided as a standalone, and as part of JBAS. You will be able to run JBM2 embedded in your clientVM also. You just need to instantiate a couple of POJOs. There are examples for both scenarios already on trunk, and that will be part of the documentation. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215866#4215866 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215866

15 years, 10 months

1
0
0 / 0

[JBoss AOP] - Re: Method Advised class on getInterceptorChainReadWriteLock

by kabir.khan＠jboss.com

"Mike03" wrote : Cool, glad that patch worked out. | | Do you have any thoughts on the CCE we're getting with the ClassicInstrumentor and optimize=true? It seems like this is caused by generated code since were talking about an Item$ItemAdvisor but it wasn't apparent in the src decompilation of Item.class with JAD. | | How do you guys approach debugging generated bytecode? | | thanks for your help, | Mike Am about to fly back to Europe, so I can't look now. There isn't really a way to debug generated bytecode apart from adding System.out.printlns when adding it in javassist View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4215864#4215864 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4215864

15 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user March 2009