Develop Reference

How to make ActivityOptions like it's lifetime dynamic in the workflow

Since my activity workload could be diffrent dramatically we can not use a fixed scheduleToCloseTimeoutSeconds
In the workerImpl's constructor I new the stubs for our activities which are going to be used in the workflowmethods. but the problem is that the adviced method of registering the workflow is by type:
registerWorkflowImplementationTypes
which only accepts a class. so there is no way to pass in the options like lifetime to the workflow which could be used to make the acitivityOptions dynamic.
So is what I am trying to achieve doing an antipattern to the Cadense?
If not, what is the correct way of doing it? probably workflow factory methods should be used, but the docs indicate those are to be used for unit test and mocking mostly and looks like using the registerWorkflowImplementationTypes is the prefered method.

The Cadence workflow implementation code must be deterministic. One way to break determinism is to directly rely on a configuration that can change during a workflow execution.
The standard way to solve this problem is to pass the configuration parameters to a workflow method as an argument or load them using an activity. Usually a local activity which is more efficient is used for this purpose.

Java test the UI using Mockito

I am writing some unit tests for an UI implementation. The problem that I came across is that I can't add a certain component to a container.
A quick example:
I have declared a JComboBox myComboBox.
The problem is when I call myComboBox.getParent() I get a null value.
This causes further problems and my tests fail.
I have to specify that I'm using Mockito for testing and that the combo box was declared with the #Mock annotation before. My assumption is that because I use mocked objects I get this error.
So the question is: Does anyone have any ideas how to add my mocked component to a parent container, so that it won't be null? Or should I change the mocking framework and use JMock?

Testing the UI is no easy job. As the Documentation states, all components must be accessed on the Event Dispatching Thread.
Frameworks like assertj may be a help.

Calling Mockito.when multiple times on same object?

When trying to use Mockito with Spring, by creating the Mock object via a bean declaration...
<bean id="accountMapper" class="org.mockito.Mockito" factory-method="mock">
<constructor-arg value="org.example.persistence.mybatis.mappers.AccountMapper" />
</bean>
...I found some strange behavior when calling Mockito.when multiple times without reseting the Mock object, for example:
Mockito.when(this.accountMapper.createBadGrammarException()).thenThrow(new BadSqlGrammarException("Bla", null, new SQLException()));
As soon as this code (the "Mockito.when") is called multiple time during the test (on the same mock), the tests fails with an error (BadSqlGrammerException even if this exception was what was actually expected - I do get a failure if I don't throw the exception, and throwing it manually works fine). Is this expected behavior? Mockito seems to suggest creating a new mock every time, which would mean creating the DAO for each method...?
What exactly happens when I call the Mockito.when method two times? How should the mock react? Replace the behavior? Ignore it? Unfortunately most searches only yield results for how to return different results for multiple calls to the method itself, but not what is to be expected for multiple calls to Mockito.when...
I'm simply trying to understand Mockito and best practices here, because going with something just because it SEEMS to works seems to be a bad idea...

One of the problems with Mockito.when is that the argument you pass to it is the expression that you're trying to stub. So when you use Mockito.when twice for the same method call, the second time you use it, you'll actually get the behaviour that you stubbed the first time.
I actually recommend NOT using Mockito.when. There are many traps that you can fall into when you use it - quite a few cases when you need some other syntax instead. The "safer" alternative syntax is the "do" family of Mockito methods.
doReturn(value).when(mock).method(arguments ...);
doThrow(exception).when(mock).method(arguments ...);
doAnswer(answer).when(mock).method(arguments ...);
So in your case, you want
doThrow(new BadSqlGrammarException(??, ??, ??)).when(accountMapper).createBadGrammarException();
If you are starting out with Mockito, then I recommend that you learn to use the "do" family. They're the only way to mock void methods, and the Mockito documentation specifically mentions that. But they can be used whenever Mockito.when can be used. So if you use the "do" family, you'll end up with more consistency in your tests, and less of a learning curve.
For more information about the cases when you must use the "do" family, see my answer on Forming Mockito "grammars"

The simple answer is:
when you write Mockito.when(object.fooMethod()).then() then fooMethod() is actually called.
Another point is that we can't observe it first time, because it called on mocked object. But when we write when for the second time then we have some behavior for fooMethod() (we set it previously, in your case it Exception).
To check this better you can spy object:
Bar spyBar = Mockito.spy(Bar.class)
when(spyBar.fooMethod()).then()...
and fooMethod() will be actually called.

How to re-initialize my bean

I have a bean in my applicationContext-test.xml that I use for mocking an external search engine. This way, when I run tests, any time my application code refers to this search engine, I know that I am using my mock engine instead of the real one.
A problem I am facing is that I want this engine to behave differently in different scenarios. For example, when I call getDocuments(), I usually want it to return documents. But sometimes I want it to throw an exception to make sure that my application code is handling the exception appropriately.
I can achieve this by referencing the bean in my test code and changing some stubs, but then I have to change the stubs back to what they were so that my other tests will also pass. This seems like bad practice for many reasons, so I'm seeking alternatives.
One alternative I considered was to reinitialize the bean completely. The bean is initialized from the applicationContext-test.xml with a static factory method. What I want to do is:
Reference the bean from my test code to change some of its stubs
Run the test using these new stubs
At the end of this test, reinitialize the bean using the static factory method specified in applicationContext-test.xml
I tried something like this:
ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(
new String[] { "applicationContext-test.xml" });
Factory factory = appContext.getBean(Factory.class);
factory = EngineMocks.createMockEngineFactory();
But this does not do the trick. Any tests that are run after this will still fail. It seems that my new factory variable contains the Factory that I want and behaves accordingly, but when the bean is referenced elsewhere, getDocuments() still throws the exception that was stubbed in previously. Clearly, my re-initialization only affected the local variable and not the bean itself.
Can someone tell me how I can accomplish my goal?
Update
While I appreciate suggestions as to how to write better tests and better mocks, my goal is to reinitialize a bean. I believe there is value in learning how to do this whether it fits my use case or not (I believe it does fit my use case, but I'm having a hard time convincing some of my critics here).
The only answers that will get any up votes or green ticks from me are those which suggest how I can reinitialize my bean.

You should define the cases when you want a result and the cases when you want an exception. They should be differentiated by input parameters to the method. Otherwise it is not a good test. So, for a given set of parameters the output should be predictable.

How about injecting different implementations of the search engine? Just create more beans representing the different mocks of the search engine.
one test class is initialized with one mock and another test class with another mock; this, of course, means you'll have more test classes for a certain class that you are testing (not that good/clean)
or...
inject more mocks (of the search engine) in 1 testing class. some testing methods (from that testing class) use one mock, other testing methods use another mock

Instead of:
factory = EngineMocks.createMockEngineFactory();
do:
factory.callMethodThatChangesTheStateOfThisObjectSuchThatItIsSuitableForYourTest(withOptionalParameters);
Also, if you are using Spring Integration Testing, make sure to annotate your method with #DirtiesContext so it won't affect the next test.

In Java, given an object, is it possible to override one of the methods?

I have an object of class A. I want to override one of the methods of that class. Can this be done?
More specifically, I have an object that is being injected into a field. I need to override one of the methods, before I can use it.
I am trying to see if Reflection could help solve the problem. Note that the method that I am trying override does not dependent on private variables of that class.

Look into Dynamic Proxy classes.

Yes.
Overriding means writing a new class, compiling it, changing the injection to use the new class, and packaging it with the rest of your app. Of course it can be done, but I don't see why you'd want reflection.
If you want this to be a dynamic thing, you're talking about aspect-oriented programming.

Assuming you are being given the object and so cannot subclass it: You can write a proxy. Forward on all the methods as is with the exception of the one you want to override. Of course no other reference to that original object will use the proxy. In particular if the object itself internally calls methods on itself then that will not use the "overridden" method.
Alternatively you could rewrite the code that calls the method, or modifies the implementing class, using AOP-style hacks.
Probably you want to have a careful think about your design.

CGLIB should be able to help you to achieve what you're trying to do. Check out Enhancer class.