[jboss-dev-forums] [Design of EJB 3.0] - EJBTHREE-1114 - Cache passivation test and generics again
There were a number of problems in this area.
1) The changes for the Pool/Cache registry broke the test
2) There was no transaction manager available
3) The use of generics in the new Pool/Cache registry was/is wrong/stupid
1) I modified the MockDeployment so the test can actually run.
This looks like a stupid api to me. There should be an EJB3Subsystem class
that selfs bootstraps and is configurable and delegated to by the EJB3Deployer.
Core EJB3 apis shouldn't be directly dependent on the deployment api, it should
be the other way around.
2) I hacked this to use the DummyTransactionManager provided by JBoss Cache
I also had to add jboss clustering into the test classpath.
This obviously needs fixing. We should be providing mock test objects
like the DummyTransactionManager in a shared project.
3) This is confused use of generics again.
There is no need for this to be generic.
| public interface Ejb3CacheFactory<T extends StatefulCache>
| {
| T createCache();
| }
|
| public class NoPassivationCacheFactory implements
Ejb3CacheFactory<StatefulCache>
| {
| public StatefulCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
I could understand it if subclasses actually took advantage
of the generic parameter (even though it is unlikely to be used).
| public class NoPassivationCacheFactory implements
Ejb3CacheFactory<NoPassivationCache>
| {
| public NoPassivationCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
It unnecessary anyway. It works without generics because of Covariant return types
| public interface Ejb3CacheFactory
| {
| StatefulCache createCache();
| }
|
| public class NoPassivationCacheFactory implements Ejb3CacheFactory
| {
| public NoPassivationCache createCache()
| {
| return new NoPassivationCache();
| }
| }
|
The same goes for the registry. The part that should have been
using generics wasn't defined properly. The collections.
Meaning it was unusable without casting (removal of casting is the whole
point of generics :-)
Anyway, I didn't fix this properly in case the interfaces are intended
to be extended where generics would make sense.
Instead there are some horrible constructions that are pointless
and pretty much unreadable. :-)
If there is no real use for the generics, then the whole thing can be simplified to
make this work:
| - HashMap<String, Class<? extends PoolFactory<? extends Pool>>>
poolFactories = new HashMap<String, Class<? extends PoolFactory<? extends
Pool>>>();
| + HashMap<String, Class<? extends PoolFactory>> poolFactories = new
HashMap<String, Class<? extends PoolFactory>>();
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104967#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...