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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: org.jboss.test.cts.test.MDBUnitTestCase

by sergeypk

I investigated it today with Clebert's help. This aspect throws the exception: public Object handleCreateTextMessage(Invocation invocation) throws Throwable | { | JBossTextMessage jbm = new JBossTextMessage(0); | | MethodInvocation mi = (MethodInvocation)invocation; | | if (mi.getArguments() != null) | { | jbm.setText((String)mi.getArguments()[0]); | } | | return new TextMessageProxy(jbm); | } | Apparently mi.getArguments() does not return null anymore but a zero-element array. I posted a question on the AOP design forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031174#4031174 Sergey View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031175#4031175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031175

17 years, 3 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - MethodInvocation.getArguments return value for 0 arguments

by sergeypk

Hi, I'm trying to debug this problem: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104450&postdays=.... The exception is thrown from this aspect: public Object handleCreateTextMessage(Invocation invocation) throws Throwable | { | JBossTextMessage jbm = new JBossTextMessage(0); | | MethodInvocation mi = (MethodInvocation)invocation; | | if (mi.getArguments() != null) | { | jbm.setText((String)mi.getArguments()[0]); | } | | return new TextMessageProxy(jbm); | } | What should MethodInvocation.getArguments() return when there are no arguments? Can it ever return null? Do all AOP versions behave the same way or has this changed? Thanks, Sergey View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031174#4031174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031174

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: trunk testsuite status

by scott.stark＠jboss.org

"kabir.khan(a)jboss.com" wrote : I fixed some leaks in aop 2 this morning related to the use of PER_INSTANCE scoped aspects, which I see messaging is using. I've added a new aop snapshot containing this fix to the repository. This *should* be fine to use with the 1.2.0.SP.snapshot.aop2beta. Unless I'm totally off the mark there are no changes in the woven code created by aop alpha3 and the current snapshot. This is beyond the 2.0.0.alpha4 and in the current snapshot? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031162#4031162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031162

17 years, 3 months

1
0
0 / 0

[Other JBoss Development Design] - Re: failing org.jboss.test.util.test.ThreadPoolRunnableUnitT

by scott.stark＠jboss.org

The source is clearly different, with the brew version clearly missing two changes. This is a source tree older than 1.3.4 to be sure: | [starksm@succubus oswego-concurrent]$ diff -w 1.3.4/lib/src/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.java 1.3.4-brew/src/concurrent/PooledExecutor.java | 30,31d29 | < 30aug2003 dl check for new tasks when timing out | < 18feb2004 dl replace dead thread if no others left | 190,193c188 | < * <dd> Wait until a thread becomes available. This | < * policy should, in general, not be used if the minimum number of | < * of threads is zero, in which case a thread may never become | < * available. | --- | > * <dd> Wait until a thread becomes available. | 298c293 | < * <li> Same as (2) except clients abort if both the buffer is full and | --- | > * <li> Same as (2) except clients block if both the buffer is full and | 304c299 | < * pool.abortWhenBlocked(); | --- | > * pool.waitWhenBlocked(); | 699,709d693 | < | < // Create a replacement if needed | < if (poolSize_ == 0 || poolSize_ < minimumPoolSize_) { | < try { | < Runnable r = (Runnable)(handOff_.poll(0)); | < if (r != null && !shutdown_) // just consume task if shut down | < addThread(r); | < } catch(InterruptedException ie) { | < return; | < } | < } | 794,797d777 | < synchronized(PooledExecutor.this) { | < if (shutdown_) | < return true; | < } | 805,806c785 | < * is available, unless the pool has been shut down, in which case | < * the action is discarded. | --- | > * is available. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031157#4031157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031157

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Fork with one path for every element of a collection

by tom.baeyens＠jboss.com

good input. i want to review the jpdl language sometime. mainly the fork/join options can do with quite some rethinking. referencing a collection is a good this. also you should be able to configure a variable name in which the item is injected for that particular child token. thanks. regards, tom. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031153#4031153 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031153

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: trunk testsuite status

by kabir.khan＠jboss.com

AOP 2.0 uses a different weaving model "Generated Advisor". You can select the old one by passing in the old instrumentor into aopc, which at least should fix the memory leaks. | <aopc optimized="${optimized}" compilerclasspathref="aop.task.classpath"> | .... | <sysproperty key="jboss.aop.instrumentor" value="org.jboss.aop.instrument.ClassicInstrumentor"/> | .... | </aopc> | However, as I mentioned elsewhere compatibilty of woven classes across releases completely slipped my mind until the cache guys mentioned it so YMMV. I'll take a look though View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031147#4031147 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031147

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: trunk testsuite status

by clebert.suconic＠jboss.com

this should be compatible... I think there is no problem on upgrading the dependency. BTW: Is there a way of woven format being fixed between AOP 1.x and AOP 2.0? (at least aop classes compiled using 1.X should run fine on AOP 2.0 IMO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031144#4031144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031144

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Fork with one path for every element of a collection

by jeffdelong

You should probably post this to the user forum, as it is not a jBPM design issue per se. However what you want to do is easy to do with an action at a node that has code as follows where you get forkCount from the size of your collection, e.g., | Node fork = rootToken.getNode(); | | if (forkCount > 0) { | // create a child token for every fork | for (int 0 = 1; i < forkCount; i++) { | | List<Transition> transitions = fork.getLeavingTransitions(); | Iterator iter = transitions.iterator(); | // need to iterate through the leaving transitions | // although we only have one | while (iter.hasNext()) { | Transition leavingTransition = (Transition) iter.next(); | String childTokenName = leavingTransition.getName(); | Token childToken = new Token(rootToken, childTokenName); | ci.setVariable("x", x, childToken); | ExecutionContext childExecutionContext = new ExecutionContext( | childToken); | fork.leave(childExecutionContext, childTokenName); | } | } | } View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031133#4031133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031133

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Fork with one path for every element of a collection

by camunda

Hi! Today I faced the problem for the second time: We need a fork which starts a sub token for every item of a collection (but all have the same process flow). This is currently not possible with jbpm. So I plan to enhance the fork for that. My plan was, to configure a "fork-collection", where I can configure the name of a process variable, which must be a array or collection. And then, the fork automatically forks at that point and create a subtoken for every item and (thats the point, where I don't know how to realize that), every token has to know the exact item, he is working on. Also the join must know, how much tokens must arrive, bevor he fires... what do you think of this idea in general? Or maybe, anybody has already implemented something like that? Or his own idea in his mind? Thanks and best regards Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031117#4031117 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031117

17 years, 3 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: FirstAvailable load balance policy loses target in seria

by bstansberry＠jboss.com

For the nested SFSB case, this is less of an issue than I was thinking. Most likely the nested SFSB was available on the original node. In that case the call will have been routed locally, bypassing the LB policy. Hence no target will have been selected and there's no loss from not replicating it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031110#4031110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031110

17 years, 3 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 March 2007