[Design of JBoss jBPM] - Regarding Swimlanes
by jagadeeshrao
Hi,
I am working with Swimlanes.
But, I am assigning actors as static values. Please refer below code. I want to send users at runtime.
**** ProcessDefinition.xml ****
swimlane name="Clerk" ---- I am assigning Actors like this
swimlane name="Manager"
assignment expression="user(xxx)"
swimlane
swimlane name="CheckPending"
assignment expression="user(yyy)"
swimlane
*******************
My requirement is,
I have different Groups. In those Groups, I have two categoies of users. For example Manager and Clerk.
Clerk should complete a taks and sends to Manager for approval.Manager should approve that task.
In this case , I may have number of Clerks and Managers. Depends on their login, My processdefinition should consider their loginID as ActorID. Please guide me. How to send ActorID dynamically.
Thanks in advance for your help.
Jagadeesh
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975074#3975074
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975074
18 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-565 - Race condition on QueueManagementTest
by clebert.suconic@jboss.com
This thread is to discuss the racing condition between getMessageCount and Delivery Thread.
Just for convenience I have copied the JIRA description which has some relevant information for this discussion.
anonymous wrote :
| QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
|
| PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder - firstPagingOrder
|
| deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
|
| While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
|
| To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
|
| I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975072#3975072
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975072
18 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests
by rachmatowicz@jboss.com
I have had a look at the existing framework for incorporating Joram tests into the testsuite. As it is a candidate approach for the integration of generic JMS test cases into the testuite, i'd like to summarise how it works and what I feel are its advantages and disadvantages.
The framework involves defining several sets of classes. The class hierarchy looks like this:
--------------------------------------------------------------------------------------------------------------
TestCase
AbstractTestCase
AbstractTestCaseWithSetup TestSetup
* -----------------------> AbstractTestSetup
* --------------> AbstractTestDelegate
JoramTestDelegate Admin
GenericAdmin AbstractAdmin
JoramTestCase JBossASJMSAdmin
JBossMQJoramUnitTestCase JBossMQAdmin
----------------------------------------------------------------------------------------------------------------
Each column represents an inheritance hierarchy. The classes to the right based on Admin are a separate hierarchy. An asterisk and dotted arrow is intended to represent a member object, pointing to its type in the hierarchy (i.e. AbstractTestSetup holds an instance of JoramTestDelegate)
How is it used? (llosely speaking)
1. You implement a subclass of JoramTestCase (e.g. JBossMQJoramUnitTestCase) which implements the method getDelegate().
This method specifies the name of the Admin implementation you want to use .
2. You implement a JMS provider-specific class implemnting the Admin interface as a subclass of JBossASJMSAdmin (e.g. JBossMQAdmin)
3. You write your generic JMS tests using JBossMQJoramUnitTestCase as your baseclass, and include code snippet similar to
Admin admin = AdminFactory.getAdmin() ;
admin.createQueueConnection(TEST_QUEUE) ;
to create JMS destinations and connections.
How does it work?
1. The Joram test cases are hardwired to use an AdminFactory to load the class GenericAdmin as the Admin implementation.
This class holds a member object which is initialised at run time and to which all JMS admin functions are delegated.
2. Whether the JMS tests to be executed are individual tests or a test suite, the AbstractTestSetup class gets called
and is reponsible for ensuring that the correct implementation of JBossASAdmin gets initialised in GenericAdmin.
3. The JMS test cases don't need to do anything special other than use the code snippet above.
This approach is used and works well for incorporating the Joram tests into the testsuite.
Problems with this approach:
1. JoramTestCase does not subclass from JBossTestCase, and so all calls to methods defined in JBossTestCase already present in
the existing test cases will have to be recoded. JBossASJMSAdmin does incorporate an instance of JBossTestServices within
it, but it does not provide an interface to all of the functions available in JBossTestCase.
2. In order for AbstractTestSetup to be called when executing a test suite, the test suite needs to be wrapped in an
instance of AbstractTestCase. Forgetting to do this will result in the Admin class not being correctly initialised.
3. It takes time to find out how the class hierarchy works (for example, processing of test cases follows a different
procesing path than for test suites), and this makes debugging and maintaining more complex.
All in all, I am in favour of using a simpler approach, based on the simplified scheme described above, where test cases
continue to sublass from JBossTestCase, and the only changes to test cases required are (i) the loading of the Admin class
based on AdminFactory and specifying the Admin implementation via the property jms.provider.admin.class, (ii) replacing
JMS specific calls to create destinations with calls to Admin (iii) making all desintaion names JMS provider neutral.
This seems to me to be a faster approach and one which will work. If I have missed some obvious advantage of the more
complex scheme, or am misrepresenting it, please point it out. I plan to begin converting one or two JBossMQ tests to the generic form based on
the simple scheme over the next few days to see that everything works in practice.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975040#3975040
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975040
18 years, 3 months