I have very simple scenario where class A registers instances for types.
A.register(T1.class, new H1());
A.register(T2.class, new H2());
this is fairly simple configuration when done by hand but guice injection doesn't work when I create instances outside the guice framework.
I try to figure out how to create and configure A with all instance with custom annotation using guice.
I have found something like this Scan the classpath for classes with custom annotation but it is not using guice.
thanks
so I guess code.google.com/p/google-guice/wiki/Multibindings is the only option so far that works, but it is not as nice as I would expect since you need to connect everything by hand.
Related
Is there are any way to instantiate an object of UploadedFile without using Mockito?
I've been searching but I only have found examples using Mockito. I'm trying to do Junits and I would like to avoid using it.
Thanks!
It is an interface, so if you don't want to use Mockito (or a similar mocking tool) just create your own class and implement the interface explicitly. There are not that many methods, so it is straightforward.
EDIT: or just use the public constructor in DefaultUploadedFile and go with that implementation.
I know there two ways to use the "Mock" and the "TestSubject" annotations with JUnit. The first one - is to specify the EasyMockLoader class object for the RunWith annotation for the class that contains fields marked by these annotations. The second one - is to mark the EasyMockRule field with the "Rule" annotation. How to use the "Mock" and the "TestSubject" annotations with TestNG ?
TestNG is not directly supported. But you can inject mocks using the annotations quite easily by doing
EasyMockSupport.injectMocks(this);
(from your test class)
As I known, EasyMock doesn't support TestNG out of the box but PowerMock does.
Maybe using PowerMock + EasyMock + TestNG will work like a charm.
Otherwise, about #Mock, you'll have to manage it by yourself (looking for fields, creating mock and injecting them) with a configuration method (a #BeforeX method) or an appropriate listener.
Another solution could be to use the Guice integration and making mocks in a Guice module.
Same solution for #TestSubject: configuration methods or listeners.
I am developping J2EE application with appfuse that have default settings with mySQL
<!-- Database settings -->
<dbunit.dataTypeFactoryName>org.dbunit.ext.mysql.MySqlDataTypeFactory</dbunit.dataTypeFactoryName>
<dbunit.operation.type>CLEAN_INSERT</dbunit.operation.type>
<hibernate.dialect>org.hibernate.dialect.MySQL5InnoDBDialect</hibernate.dialect>
<jdbc.groupId>mysql</jdbc.groupId>
<jdbc.artifactId>mysql-connector-java</jdbc.artifactId>
<jdbc.version>5.1.27</jdbc.version>
<jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>
<jdbc.url>jdbc:mysql://localhost/${db.name}?createDatabaseIfNotExist=true&useUnicode=true&characterEncoding=utf-8&autoReconnect=true</jdbc.url>
<jdbc.username>root</jdbc.username>
<jdbc.password></jdbc.password>
<jdbc.validationQuery>SELECT 1 + 1</jdbc.validationQuery>
But i need to connect my application with external database (SQL QERVER)to retreive some data.
I need help to configure maven to use two different database (mysql +sql server)
maven will help you out with loading of the driver jar files. You would be creating two data source / session factory to achieve this.
I think this can be achieved quite easily in a brief guideline as follows:
Create a second "dataSource" bean definition in applicationContext-resources.xml with MSSQL specific values such as driver class, url etc. Give it a different bean id, "dataSourceMSSQL" perhaps. Bind them up to different properties file if you don't want to hard coded property values. For simplicity you can just hard coded it (not recommended). If you chose otherwise, you need to create another properties file to store mssql connection properties, perhaps jdbc-mssql.properties and add it into propertyConfigurer list. This also require you to make changes to your pom file to include custom settings under <!-- Database settings --> section. This can be a bit complicated.
Create another "sessionFactory" bean definition in applicationContext-dao.xml with MSSQL specific values such as hibernate dialect etc. and binds it to "dataSourceMSSQL" as dataSource property ref. Give it a different bean id perhaps, "sessionFactoryMSSQL".
Wire your DAOs which require the new sessionFactory i.e.:
#Autowired private SessionFactory sessionFactoryMSSQL;
Hope that will work for you.
I'm trying to write a test that needs both Robolectric 2.2 and PowerMock, as the code under test depends on some Android libraries and third party libraries with final classes that I need to mock.
Given that I'm forced to use the Robolectric test runner through:
#RunWith(RobolectricTestRunner.class)
...I cannot use the PowerMock test runner, so I'm trying to go with the PowerMock java agent alternative, without luck so far.
I have setup everything according to this guide but I'm facing a collision problem between classes required by the javaagent library and by robolectric through its dependency with asm-1.4. Both depend on
org.objectweb.asm.ClassVisitor
, but javaagent-1.5.1 ships with its own version where ClassVisitor is an interface while asm-1.4 version for the same namespace is an abstract class, with the corresponding error at runtime:
java.lang.IncompatibleClassChangeError: class org.objectweb.asm.tree.ClassNode has interface org.objectweb.asm.ClassVisitor as super class
I have even tried to modify the javaagent library jar to entirely remove the org.objectew.asm classes in there, but that doesn't work as ClassNotFoundException happens afterwards due to some other classes needed in the org.objectweb.asm package that only ship in the javaagent library jar, and not in the asm one.
Any ideas? According to examples out there the agent seems to work fine with, at least, the Spring test runner.
I had the same problem and while I didn't solve this problem as such, I wanted to share my approach, which removes the need for PowerMock (which is always a good thing in my view): I wanted to mock a call to
Fragment fooFragment = new FooFragment();
So what I did was addanother level of indirection. I created a FragmentProvider class:
public FragmentFactory fragmentFactory = new FragmentFactory();
[...]
Fragment fooFragment = fragmentFactory.getFooFragment();
After i did this, I could just mock out the factory with standard Mockito, like this:
FragmentFactory mockFactory = mock(FragmentFactory.class);
activity.fragmentFactory = mockFactory;
when(mockFactory.getFooFragment()).thenReturn(mockFooFragment);
I am fond of using decorator chains instead of inheritance, and as long as my services have Singleton or Transient lifestyles (and their dependencies are scoped in the same manner) this works perfectly. I've started to use the TypedFactoryFacility to generate factories for services which require some sort of input which can not be resolved through the ioc container. My headache starts when something deep in the decorator chain requires a factory and Windsor refuses to pass inline dependencies down the inheritance chain. As I understand this is by design, but I don't agree that this breaks encapsulation when you are using a factory which explicitly states what you need to produce the output (I think Windsor should pass inline dependencies to components which are factory resolvable, but I'm guessing its not that straight forward. Anyway, at the end of the day I end up exposing my decorator chain like this:
public ISessionInputOutput Create(Session session)
{
IServerInput baseInput = _inputFactory.GetBaseInput(session.CommunicationSocketStream);
IServerInput threadSafeInput = _inputFactory.GetThreadSafeInput(baseInput);
IServerOutput output = _outputFactory.Create(session.CommunicationSocketStream);
ISessionInputOutput baseIO = _sessionIOFactory.GetBaseIO(baseInput, output);
ISessionInputOutput commandHandlerIO = _sessionIOFactory.GetCommandHandlerIO(baseIO, session);
ISessionInputOutput errorHandlingIO = _sessionIOFactory.GetErrorHandlingIO(commandHandlerIO, session);
_releaseInfo.Add(errorHandlingIO, new CreatedIOInformation(baseInput, threadSafeInput, output, baseIO, commandHandlerIO));
return errorHandlingIO;
}
In the example I am using 3 factory proxies, and manually combine the output to produce the decorator chain.
I can't simply use ServiceOverrides as I usually do to introduce new services. This doesn't feel right and I am hoping that someone can suggest a better solution what I've used above.
I've also tried to solve this by using child containers, but this introduces a bit more ioc details into the stack than I like.
If you really feel you need to enable passing down the dependencies you can enable that by overriding RebuildContextForParameter method in DefaultDependencyResolver and passing true for propagateInlineDependencies.
Be aware that this is a double-edged sword. You can also filter this out and enable this behavior only when you're resolving one of the few services for which you need this, and stick to the default behavior for all other.